数据库设计。每个表都应该与关系链接吗
我只是想为餐厅创建一个简单的预订系统。我现在有5张桌子。
会员---->预订<--- 独家夜间
菜单---> 上面的菜
显示了他们之间的关系。因此，一位顾客可以进行多次预订，并且许多预订都是针对一晚的独家预订。
不过，我还有另外两张桌子和底部的菜单和菜肴，其中一张菜单有很多菜肴。
虽然会员和非会员可以查看菜单，但我不确定他们如何通过外键加入，或者根本不加入。
所以我的问题是，拥有两个这样的未链接到数据库其余部分的表是否错误/不鼓励？
感谢您的帮助。
I am just trying to create a simple booking system for a restaurant. I have 5 tables at the moment.
Member ---> Reservation <--- Exclusive Night
Menu ---> Dish
Above shows their relationship with each other. So a customer can make many reservations and many reservations are for one exclusive night.
However i have those other two tables and the bottom Menu and dish, with one menu having many dishes.
Although members and non members can view menus i am not sure how they could be joined by a foreign key, or joined at all.
So my question is, is it wrong/discouraged to have two tables like that which are not linked to the rest of the database?
Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将数据与关联联系起来意味着约束数据具有与关联一致的值。
如果您必须表示成员和菜单之间的关联（如果您可以使用应用程序上下文特定的单词来表达它，并且需要为了您的应用程序逻辑的目的来表示它），那么您将设计这个关联，然后用向表中添加一列（例如菜单表中成员的外键）并添加约束以确保 FK 中的数据符合 PK 中的数据，如果需要，您将添加 REFERENTIAL INTEGRITY。
这是您的选择，您不必必须。
在数据库设计中，您应该首先问自己是否需要。
Linking data with associations means to constraint data to have values in accord with association.
If you have to represent an associaion between a member and a menu (if you can express it with application context specific words and need to represent it for the purposes of your application logic), so you will design this association and then reduce this association with adding a column to a table (e.g the foreign key for the members in the menu table) and add a constranint to ensure that data in the FK conforms to data in the PK and if you want it you will add REFERENTIAL INTEGRITY.
It's your choice, you don't have to.
In database design you should ask yourself firstly if you need to.
就看你了。它们被称为约束，因为您限制了可能的输入。
因此，例如，如果
Menus 是 MenuId、MenuName、DishId，Dishes 是 DishId、DishName，则完全有理由说菜单上的所有菜肴都必须存在于菜肴表中，因此您可以在菜单上添加外键约束。
之后，诸如将菜单加入到菜肴中
，打印一份鸡蛋炒饭而不是 42 份，
查找所有在菠菜床上有厨师特制屋顶兔子的菜单。
所有从未出现在菜单上的菜肴。
都是你可能想要的东西，但你不吃的是菜单上“你”一无所知的菜。
关系是机制，制约是原因。
It's up you. They are called constraints because you are limiting the possible inputs.
So for instance if
Menus was MenuId, MenuName,DishId and Dishes was DishId, DishName, it's perfect reasonal to say that all dishes on a menu must exist in the dishes table, so you'd put a Foreignkey constraint on menus.
After that things like joining Menus to dishes
To print one out with Egg fried rice instead of 42
Find all the menus which have the cook's special roof rabit on a bed of spinach on.
All dishes that never appear on a menu.
are all things you might want, but what you are sating you don't is a dish on a menu 'you' know nothing about.
Relationships is the mechanism, contraints is the reason.