Resolved Digital Menu Display System Database Design (EntityFramework Core)

[starmomou]

I would like to develop a digital display menu system which doesn't include any ordering feature. Currently I get stuck in handling entity relationship between menu list and menu item. Should I use a mapping table for them? or I can simply handle menu items inside menu list instead of creating an entity for menu item. I hope I have clarified my questions. Thanks!!!

Requirement:

There are several restaurants using the same menu system.


Each restaurant has several menu lists(meals, snacks and drinks etc.)


Each menu list contains different menu items with price (burger, fries and Coke...)

 

[jmcilhinney]

This thread was marked Resolved before it was even approved, so I'm not sure whether that is an error or it actually has been resolved. As there's no actual resolution provided, I'll add my 2 cents, in case it might help the OP or others.

Based on the information provided, it sounds to me like there should be a MenuList entity, with at least MenuListId and Name properties. There should also be a MenuItem entity with MenuItemId, Name and Price properties. If each MenuItem can only be included in one MenuList then MenuItem should also have a MenuListId property that maps to a foreign key. If a MenuItem can be included in more than one MenuList then you would need another entity, e.g. MenuListItem, that had MenuListId and MenuItemId properties that map to foreign keys. You might make that combination of properties the key or you might add a MenuListItemId column as key and add a unique index to the other two columns. In my office, we do the latter.

 

[Skydiver]

Interesting... I thought that the point of using the modern Entity Framework Core, particularly with the push for Code First, was that developers didn't have to think about database schemas anymore. Just create your actual object oriented entities, and the system would take care of creating the appropriate relational schema to support that object oriented point of view. Or is this just more marketing hype from Microsoft? Does Entity Framework still require the developer to think in terms of relational schemas, but it just happens to be expressed as POCOs instead of SQL table and key creation statements?