这应该很简单。但我该如何设计这个呢？
我有2种业务单位；部门和部门。业务单位必须是其中之一，但不能同时是两者。 所以这很容易。有一个 BusinessUnit 表和一个包含部门和部门的 BusinessUnitType 查找表。 然而，只有分区才能包含团队。每个部门都有一对多的球队。部门没有团队。 那么我应该在这里做什么呢？也许我应该在 BusinessUnitType 表上有一个名为 hasTeam 的标志？ 这是组织这些数据的最佳方式吗？ 我不确定这个特殊的设计是否有名字。
I have 2 kinds of business units; division and department. A business units has to be one or the other, but cannot be both.
So this is easy enough. Have a BusinessUnit table and a BusinessUnitType lookup table containing division and department.
However only divisions can contain teams. For each division there are one to many teams. Departments do not have teams.
So what should I be doing here? Maybe I should have a flag on the BusinessUnitType table called hasTeam?
Is that the best way to organise this data?
I am not sure if this particular design has a name.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的案例看起来像是一代规格设计模式的一个实例。 Gen-spec 是“泛化专业化”的缩写（参见定义）。了解继承的程序员很熟悉 gen-spec 模式。但是在关系模式中实现 gen-spec 模式可能有点棘手，数据库设计教程经常跳过这个主题。
这个话题之前已经出现过。 （查看示例讨论）。
幸运的是，网络上有一些很好的文章专门解释了这个主题（参见示例文章） 。和谷歌搜索（查看示例搜索）将产生更多文章。
Your case looks like an instance of the gen-spec design pattern. Gen-spec is short for “generalization specialization” (see definition ). The gen-spec pattern is familiar to programmers who understand inheritance. But implementing the gen-spec pattern in a relational schema can be a little tricky, and database design tutorials often skip over this topic.
This topic has come up before. (See sample discussion).
Fortunately, there are some good articles on the web that explain just this subject (see sample article). And a Google search (see sample search) will yield lots more articles.
如果没有更广泛的背景（例如，您正在使用什么技术，这是否是一个新项目，您是否对实施有任何其他限制等），回答这个问题有点困难。
但一般来说我会说：
如果这是一个新项目，并且您不受技术限制，我建议使用 OR/M（我个人使用 nHibernate）。您可以轻松配置它以满足您的需求，而无需担心底层数据库。
否则-看来你最初的想法是个好主意。根据您使用的数据库，如果您愿意，您可能可以创建一个约束来强制执行该逻辑（我个人不建议这样做，因为它将您的业务逻辑带入您不属于的数据库中）。< br>
希望这会有所帮助。
It's a bit difficult to answer without a broader context (for example- what technologies you're using, whether this is a new project, whether you have any other constraints on implementation etc.).
but generally speaking I would say:
If this is a new project, and you are not technology-constrainted, I'd recommend using an OR/M (I personally use nHibernate). You can easily configure it to fit your needs without worrying about the underlying DB.
otherwise- it seems that your original thought is a good idea. Depending on the DB you're using, you can probably create a constraint to enforce that logic, if you like (I personally would not recommend that, since it brings your business logic into your DB, where it doesn't belong).
Hope this helps.