数据库表布局
在设置 MySQL 数据库时，假设我有一个名为：
- Coupe
- Sedan
- Mini-van
- Truck 的
产品表 (tblCar)和一个（1980 年代）配件列表：
- Moon top
- Chrome Wheels
- Window Tint
和一个选项列表：
- 油漆颜色
- 轿
- 轿车可以从任何配件中进行选择，
- 但不提供蓝光
现在，让我们设置一些基本规则：
- 跑车可以从任何配件或选项中进行选择
- 选项
- 小型货车有车窗贴膜作为配件，并且可以从所有选项中进行选择
- 卡车只有镀铬轮毂、色调配件和油漆选项
我需要tblCar设置，这一点很清楚。但是，如何管理 tblAccessories 和 tblOptions 表格而不复制行项目本身。假设我只想要配件和选项的描述信息，而不是价格，因为这些信息对于所安装的汽车来说肯定会有所不同。
这是否是 tblAccessoriesHelper 的情况，它包含以下值的列表carID 和 accessoryID 两者应该在哪里相遇或者有更好的方法吗？
In setting up a MySQL database, consider that I have a table of products (tblCar) named:
- Coupe
- Sedan
- Mini-van
- Truck
And a list of (1980's) accessories:
- Moon roof
- Chrome wheels
- Window Tint
And a list of of options:
- paint color
- interior finish
- interior color
- Blu-Ray player in-dash
Now, let's setup some ground rules:
- Coupe can choose from any accessory or option
- Sedan can choose from any accessory but provides no Blu-Ray option
- Mini-van has window tint as an accessory and can choose from all options
- Truck only has chrome wheels, tint accessories and only paint options
I need a tblCar setup, that much is clear. But how do I manage a table of tblAccessories and tblOptions without duplicating the line items themselves. Let's pretend that I only want description information for accessories and options and not prices as those would surely be different for the car they were installed in.
Would this be a case for tblAccessoriesHelper that holds a list of values of carID and accessoryID where the two should meet or this there a better method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您将拥有将两者连接在一起的联结表。
如果您使用“tbl”命名表，则还有另一种命名约定，该约定使用前缀“jct”。我会命名这些表
（使用单数形式命名表，但“选项”是特殊的，因为“选项”可能是某些 DBMS 中的保留/特殊词）
You would have junction tables, that join the two together
There is another naming convention that uses the prefix "jct" if you are naming tables using "tbl". I would have named the tables
(name tables using the singular form, but "options" is special, because "option" could be a reserved/special word in some DBMS)