I would think daily, or end of week would be best, but ...zplits wrote:Which one do you think will be a better idea sir? If it's about one database entry for each month then, the manager won't be able to create their reports daily? Regarding the capture the from and to date, what do you think would be a better idea? because the CEO will be able to see their submitted reports, and will try to compare the previous months into the upcoming months.
... this implies that in order for the data to be able to tell the CEO what items are selling, you are going to have to enter data this is already broken down. I mean ... let's say your menu has item A, B and C. If you submit a report saying "24 A sold, 400 B sold, 350 C sold", well that will tell you about your products. If you submit a report saying "774 items sold" ... well .... that tells you a lot less doesn't it?zplits wrote:Help the CEO decide what food will be served next month, what are the ups and downs of his company, what he needs to do in order to improve his businesses.
But to be able to report on a specific menu item, the database model has to understand each menu item as an entity, and that entity will need to be kept up to date in order to be useful.
This is a consideration I cant really answer. It depends on the requirements of the system you are designing really. When the CEO logs in, should they see an up to date overview, or data that is a month old. If the data is submitted monthly, what happens if the data is submitted late?zplits wrote:Which one do you think will be a better idea sir? If it's about one database entry for each month then, the manager won't be able to create their reports daily? Regarding the capture the from and to date, what do you think would be a better idea? because the CEO will be able to see their submitted reports, and will try to compare the previous months into the upcoming months.
zplits wrote: If you can help me make it work with the simple methods, then why do we need complex ones.
Well .. the method that you'll use will be the method that achieves your goals. A medium complexity will give you a menu item breakdown for your CEO to view, regardless of how often it is submitted, but if you want to include financial and ingredient information, then that ups your complexity. Also, youhave to decide on these scale issues now, before you get too far along, otherwise the project will scale itself up.
I mean, let's say that we track menu item sales, reported daily. Well, seeing as we already know how many items are sold, if we enter a production cost and a sale cost to each item, we can easily see how much we spent and how much we earned without any additional information being entered by the manager. Ok, but now, if we can do that, then we could also attach a list of ingredients needed to produce each item, including the quantity needed per item. Then we could see how much of each ingredient we needed last month, again without requiring any extra information from the manager report.
But each step complicates your database model, because it needs to be able to express all these elements of each item.
So you need to KNOW ... right now ... what data you are trying to carry. If you just want a bulk financial report (income / expense) per month, then your database will be very simple. If you want to track menu items with costs and ingredient lists, then you start moving up into much more complex database setups.
Bottom line ... no-one can really tell you what the 'best' approach is unless you know 'what' it is you need to store.
Have a think about it, maybe discuss the requirements and so on at your end, and when you can clearly define what it is you need to store, then we might be able to give more specific advice about what database design will fit best.
Cheers.