Timeline for SQL Database schema for Catering/Menu management
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 24, 2020 at 22:42 | comment | added | Steve |
It doesn't really strike me as an inheritance situation, but yes there's no harm in using menu_elements to store all the various kinds of elements. However the detailed design is an exercise for you.
|
|
| Apr 24, 2020 at 20:08 | comment | added | narciero |
@Steve thanks! that all sounds good, for the menu_elements table, do you recommend I use Single Table Inheritance for attributes specific to each type of element?
|
|
| Apr 24, 2020 at 0:06 | comment | added | Steve | Another tip, naming should be something along the lines of one table being "menu_elements", the other being "menu_structure". I'm not exactly sure how the pricing structure works, nor exactly how the menu selection process works, but this basic database structure should provide a reasonable skeleton which can be tweaked - e.g. if the items are individually priced, but the price depends on whether they are ordered a la carte or as part of a set menu/course, then you'd put the pricing information in the structure table, not in the elements table. | |
| Apr 23, 2020 at 23:59 | comment | added | Steve | I don't have a coded example offhand, but it's really not complicated. A basic approach applied to your case is to have a table with names, types, and prices for all menu elements (e.g. all individual food items, plus courses and set menus), and a second table which expresses the structural links of those elements (i.e. at minimum, a parent id column and a child id column). You need two tables because the elements will I assume be many-to-many (courses can contain multiple different food items, and any given food item could be found in multiple defined courses/set menus). | |
| Apr 23, 2020 at 23:31 | comment | added | narciero | @Steve do you have an example you could point me to? Does a recursive BOM model typically use STI to model each type of "part"? thanks! | |
| Apr 23, 2020 at 17:34 | comment | added | Steve | A typical approach is to have a recursive structure, and incorporate some distinction between basic parts (which cannot be linked to other parts), and assemblies of such parts (which can be linked either to parts, or to other assemblies). | |
| Apr 23, 2020 at 17:23 | comment | added | narciero | @Steve thanks, I think BOM could be a good fit for composing the Menu out of courses + items, I'm not quite sure how to model that though since I'd wanna make sure a MenuItem isn't a parent of a MenuCourse | |
| Apr 22, 2020 at 6:00 | answer | added | Doc Brown | timeline score: 1 | |
| Apr 21, 2020 at 19:53 | comment | added | Steve | The first thing to note about this is that it's possible for someone who doesn't work in a restaurant, to design a menu system that is far more complex (and possibly still more restrictive) than a customer will tolerate. Secondly, I think what you're dealing with here is essentially a "bill of materials" problem. | |
| Apr 21, 2020 at 17:59 | review | First posts | |||
| May 5, 2020 at 17:56 | |||||
| Apr 21, 2020 at 17:53 | history | asked | narciero | CC BY-SA 4.0 |