I have a products model and an iTunes sales model. At the moment i'm fairly successfully reporting sales through scopes and ordered hashes. One flaw in the approach i've taken is that if there's no sales for a particular date I don't get a zero entry, just a gap for that date, which proves to be an issue when using something like Highcharts to plot the results.
I'm also soon to add new models for sales data from other sources, which will mean a rewrite to pull these figures into the product view and with my current approach I can see this being a complete headache when one report contains sales for a date but another doesn't.
I'm thinking I should instead for any given product be producing a range of dates (last 30 days for example) and then for those dates bring in the associated sales from my iTunes and other sales models. I'm just not sure how to approach this or if this is even the best approach to take.
Does anyone have experience of building something similar that can offer some guidance here please?
Thanks in advance!
It might not be the "right way" but you could always through a date lookup table in your DB and left join on it. That way you can be sure you have all the dates in the period of question present in your query results regardless of whether they have data.
Related
I'm trying to improve the schedule spreadsheet for the café I'm working at.
Our employees can be baristas, bartenders, or both. I made a table with checkboxes for that. That's the Employee list tab.
In the Schedule planning tab we specify which days in a given month we can come to work. Sometimes people can work both morning (AM) and afternoon (PM) shifts in the same day, but not always, so it needs to be specified too.
In the Finalized schedule tab our manager would split the shifts among employees manually, which is the most complicated and time-consuming part of the whole process. They would constantly switch between tabs, checking who can work which days and shifts, then juggle with what's available. Needless to say, there's plenty of room for error there and sometimes it's quite a mess.
I would like to automatize it a little bit. I know a little about spreadsheets, but can't figure out a few basic things here to even get started. I suppose my main issue is "connecting" several individual cells - to get a particular result only when their values correspond correctly.
I would be eternally thankful for tips on any of the following points.
(There's also going to be a calculator for hours worked in another tab, but I've already sorted that out.)
https://docs.google.com/spreadsheets/d/18W1ScIDT0e7A7esOwnTkvIVtWzoOkMPo6pfqkTVLn7E/edit#gid=1743092005
I imagine the tabs feeding into each other in the following manner:
Employee list tab would serve as the foundation for the rest of the sheet. The other two tabs would pull employee names out of it (to avoid typos and subsequent errors, especially in the hour calculator tab), as well as their roles.
In the Schedule planning tab, the only thing I have troubles with is automatically generating new sections for each employee. The sheet linked above is obviously faux, there's many more people working at our café and people often come and go, so it would definitely save time if a horizontal list of names from Employee list (B3:B) could be generated into (C1:1) of Schedule planning. Is that possible?
Other than that, what's crucial here is the date (B3:B) and shift (C2:C).
The last tab is the most complicated. This is what our manager sinks hours and hours into.
As you can see, for each day, there's up to six slots available - three per shift: one each for baristas and bartenders, and then one more in case an extra pair of hands would be needed on that particular day/shift. This extra slot can be filled out by anyone available regardless of their usual role.
Ideally, I would like to have a dynamic dropdown list in each slot that would pull data from the previous two tabs. The criteria are as follows:
Name is pulled from Employee list (B3:B).
Role is pulled from Employee list (B3:C). For example, John is a barista, so he should appear only in Barista and Support slots; Bill, on the other hand, can appear in any slot.
Date is pulled from Schedule planning (B3:B). For example, Patrick should only appear available in the March 1, 4, 6 and 9 slots (and also only in the Bartender slot, as that is his role).
Shift is pulled from Schedule planning (C2:C). For example, if we would need a barista to work in the morning on March 4, the dropdown list would contain only Cathy and Bill, as they both fill the role and are available for the AM shift on that day.
Additionally, if a person has already been selected from the dropdown list, they shouldn't appear in the other two dropdown lists for that shift, even if they satisfy all other criteria. For example, if Bill appears in D16 (Barista, March 8, AM shift), he's "taken" and can't work any other role at that moment. (In other words, the same person can only appear once on the same row. I'm not sure it can be done via dropdown lists, but perhaps color formatting would do.)
I understand it's quite a project I need help with, but I'm really stuck here and don't know where to begin. My hope is that for some of you it might also be a fun game figuring this out with me.
Thanks a lot to whoever can contribute to this in any capacity.
I apologize if this is not allowed or too general or vague.
I am a teacher frustrated by the fact that I cannot find a pre-made Google Sheets gradebook to do what I want. I decided to try to write one myself. Of course I not great at writing script but through trial and error and trying to decipher others code I am picking it up.
What I really want to know... is it possible to do what I envision or am I wasting my time?
I want to have a list of students in column 1 and enter an assignment title, type of assignment (there are 3 with different weights) and grade for each student in subsequent columns.. and be able to display a running cumulative grade based upon weighting - I know all of this can be done. The extra part is being able to send the student and parent an email if an individual assignment grade is lower than a 70. I am pretty sure this can be done. The part I don't know is what that would look like. For instance, would there be a run script button that needs to be added for every assignment column in the spread sheet or....
I hope this makes sense and again apologize for my noobishness..
Found this:https://www.google.com/amp/s/www.groovypost.com/howto/google-sheets-send-email-based-on-cell-value/amp/
Your goal sounds doable assuming you are sending these mails from your gmail address or your org is using enterprise gmail.
Only other concern id say to watch out for is accidentally sending the emails out over and over for the same grade event.
As a student, if i recieved a recurring daily email about the same low grade assignment a month ago i might eventually spam flag the source, invalidating all that hard work.
I am fairly new to data warehouses and I want to make sure my plan makes sense. I am using a star schema to capture insurance information for reporting purposes. The users want to see everything as-of a specific day, since ever field can change daily I am planning to have a record in the fact table join to a unique record in each dimension. I know that this will generate a lot of records but I am unable to think of another way to do it.
I appreciate any insight.
New to document-oriented database concepts and have a few high-level questions related to orders and order processing.
How does one capture an order in this world? Would an order just be a new document in an Orders collection? Would order_item relate back to a product listed in another document? Or is it assumed that order_item would be copied and inserted into the order document and thus, perhaps, difficult to report the total of product sold over time?
How does one work around lack of transactions and maintain integrity
Sorry, very new to me though eager to understand...it sounds very appealing to encapsulate all these 'things' for sale as "objects" and move them around as such between server & clients, etc...if it's indeed plausible. Just need some help conceptualizing big picture dos and don'ts.
How does one capture an order in this world? Would an order just be a new document in an Orders collection?
Yes. That's the way these databases work.
Would order_item relate back to a product listed in another document?
It could. Depends on what you're doing.
Or is it assumed that order_item would be copied and inserted into the order document
Also possible. This works well for historical analysis and data warehousing.
and thus, perhaps, difficult to report the total of product sold over time?
It's always hard to report total product sold over time.
Today, product "23SKIDOO" is a 23l, open-valved, framistat with double widgets.
Last year, before the recall, the same product was a 23l, closed-valved framistat with only a single widget.
In a previous year, the same product was actually 22.5l.
Are these the "same" product? Marketing calls them all "23SKIDOO". But there are differences.
A single Product table doesn't resolve this correctly. What folks then do is invent product lines and product families so they can introduce the "23SKIDOO-B" and "23SKIDOO-PLUS" products which are all part of the "23SKIDOO" family.
Product lines and product families and other more fanciful groupings are workarounds and hacks to magically make unrelated products report together and provide a "total product sold over time" even though the products are clearly different.
Copying the product into the order (while it seems wasteful) can preserve more historical fidelity than many of the commonly-used workarounds.
How does one work around lack of transactions and maintain integrity?
MongoDB has locks. http://www.mongodb.org/display/DOCS/How+does+concurrency+work.
It's not clear what you mean by lacking transactions.
So its always hard to answer a generic question. However, what I would encourage you to do it look at the patterns of read and write you expect your application to perform. There are trade offs for certain document designs just like there are from RDBMS schema designs.
Here's a link to a MongoDB centric schema design presentation. It may help you to understand some of these trade off and options for design.
http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design
I'm new to data warehousing. First, I want to precise than my copy of The Data Warehouse Toolkit is on it's way to my mailbox (snail mail :P). But I'm already studying all this stuff with what I find on the net.
What I don't find on the net, however, is what to do when you seems to have more than one fact in a DW. In my case (insurance), I have refunds that occur on a non regular basis. One client can have none for 3 months and then ten in the same months. On the other hands, I have "subscription fee" (not sure what is the correct english term, but you get the point), that occur every month or every three months. That seems clearly like two distinct facts to me.
Those two are kind of loosely coupled by some dimensions, like the client or the "insurance product". Now are these two different warehouse, on which I have to produce two different report and then connect the reports outside of the DW ? Or is there a way to design this to fit a single descent DW. Or should I combine these two facts in one? I would probably lose granularity on refunds then.
Some blog I read said a DW always has one fact table. Others mention the step of designing what are the fact tables with a S, but there is no clear instruction of if there is a link between them or they are just distinct components of a same DW project.
Does anyone know some references on that precise part of DW design?
I realize that I am answering an old post, but I am not satisfied with either of the answers provided. I feel that neither answered the question.
A schema can have one or more facts, but these facts are not linked by any key relationship. It is best practice not to join fact tables in a single query as you would whey querying a normalized/transactional database. Due to the nature of many to many joins, etc - the results would be incorrect if attempted.
The answer you are looking for is that you need to "drill across" which basically means that you are querying each fact table (schema) separately and merging the results. This can occur using SQl or preferably via a reporting/analytics tool that you may have which referenced the data warehouse. Instead of duplicating the answers on how to do this, I will direct everyone to two very good articles:
Three ways to drill across by Chris Adamson
and
The Soul of the Warehouse - Drilling Across by Ralph Kimball
You can have as many fact tables as you like. In your example you may have something like:
dimProduct lists several products -- subscription being one of those.
dimTransactionType would list possible transactions (purchase, refund, recurring subscription fee ...)
Now suppose you are interested in simplified subscription reporting, you could add a factSubscription like this:
Taking your questions backwards.
A data warehouse can have more than one fact table. However, you do want to minimize joins between fact tables. It's ok to duplicate fact information in different fact tables.
Of the objects you mentioned:
Refund is a fact. Timestamp is the dimension of the refund fact.
Subscription fee is a fact. Timestamp is the dimension of the subscription fee fact.
A refund can happen more than once. I'm guessing that each customer has one subscription fee. So it appears we have two fact tables so far, customer, and customer refund.
If you knew that there could only be at the most 3 refunds (as an example), then you would eliminate the customer refund fact table, and put 3 refund columns in the customer table.
You also mention insurance. A customer can have more than one policy. So we have a third fact table.
A data warehouse is usually designed using a star schema. The star schema is basically one fact table connected to one or more dimension tables. You'll probably have more than one star in a data warehouse, since we already defined 3 fact tables.