数据库表设计问题
我有三个表（定义如下）。我的问题是每个“foo”行可以有多个“bar”行。所以我需要一个“fooToBar”表。这是正确的设计吗？这种情况的名称或设计模式是什么？有没有比“fooToBar”表更好的表名称？非常感谢。
foo
fooID
名称
栏
条码
名称
fooToBar
fooID
条码
I have three tables (definitions below). My question is there can be multiple "bar" rows per "foo" row. So I need a "fooToBar" table. Is this the right design? What is the name or design pattern of for this type of situation? is there a better name for the table than "fooToBar" table? Thank you very much.
foo
fooID
name
bar
barID
name
fooToBar
fooID
barID
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您命名的设计适用于 n:m 关系。如果 foo 和 bar 彼此独立，并且每个 foo 可以与多个 bar 相关 - 并且每个 bar 可以与多个 foo 相关，那么这就是要采用的方法。
如果每个 bar 只能与一个 foo 相关，那么您就处于 1:n 关系中，只需将 fooID 列添加到 bar 表中即可。
我想说，如果您在整个数据库中保留命名约定，那么这个名称就没有问题（但要纠正大小写）。
The design you name is for n:m relationships. If foo and bar are independent of each other and each foo can be related to several bars - and also each bar can be related to several foos, then this is the approach to go.
If each bar can only be related to one foo, you're in 1:n relationships and could just add a fooID column to the bar table.
I'd say if you keep the naming convention in your whole database, then there's no problem with this name (but correct the capitalization).
如果一个 foo 可以有多个 bar，但反之则不然，那么你就拥有了所谓的 foo 和 bar 之间的一对多关系。要建立这样的关系模型，您需要在 bar 中添加一个名为
fooId的列。不需要 fooToBar 表。但是，如果单个 foo 可以有多个 bar ，并且单个 可以有多个 foo栏那么你就有了多对多关系 在 foo 和 bar 之间，这需要第三个连接表 (fooToBar)。
关于命名约定，我通常使用正确的大小写（而不是驼峰大小写），并为每个数据库对象添加一个前缀，用于标识该对象所属的应用程序。另外，我通常命名多对多连接表，以便它们包含其他两个表的名称。例如，如果我正在构建 Stackoverflow，我可能会在每个数据库对象前加上 so 前缀，这意味着多对多示例中的表将被命名为：
我认为什么比命名的细节是您选择一个约定并遵守它。
快乐编程！
If there can be multiple bars for a single foo, but not the other way around, then you have what is called a one-to-many relationship between foo and bar. To model such a relationship you would add a column named
fooIdin bar. There would be no need for a fooToBar table.However, if there can both be multiple bars for a single foo and multiple foos for a single bar then you have a many-to-many relationship between foo and bar, which necessitates a third join table (fooToBar).
Regarding naming convention, I usually use proper casing (not camel casing), and affix each database object with a prefix that identifies the application the object belongs to. Also, I usually name my many-to-many join tables so that they incorporate the names of the other two tables. For example, if I was building Stackoverflow, I might prefix each database object with so, meaning my tables in the many-to-many example would be named:
I think what is more important than the naming minutia is that you choose a convention and stick with it.
Happy Programming!
如果 foo bar 关系是可选的，即如果您想要允许没有对应 Foo 行的 Bar 行，则需要 FooToBar 表。否则，您可以将 foo 属性作为外键放入 bar 中。
You need the FooToBar table if the foo bar relationship is optional, i.e. if you want to allow Bar rows that have no corresponding Foo row. Otherwise you could just put the foo attribute as a foreign key in bar.