ERD 让我困惑的一件事是，他们是否对如何从技术上实施他们的关系做出了规定。
在下图中，我不确定该图是否需要在数据库级别或应用程序级别实现这些关系。
是制定任何技术处方还是简单地定义关系并让我来决定如何实施？
在构建基于 ERD 的东西之前，我是否需要从 ERD 的创建者那里获得更多信息？
One of the things that confuses me about ERDs is whether they make any prescriptions about how their relationships should be implemented technologically.
In the diagram below I'm not sure if the diagram requires these relationships to be implemented at the database level or at the application level.
Is it making any technological prescriptions or simply defining the relationship and leaving it up to me to decide how to implement it?
Would I need to have more information from the creator of the ERD before building something that is based upon it?
发布评论
评论（5）
看来你把问题本末倒置了。
答案当然是：不，没有什么会强迫您在数据库中创建关系。 但你为什么不这样做呢？
这就是为什么数据库被称为关系数据库 - 因为它为您提供了解决这个问题的解决方案，该解决方案易于使用，与工具和持久层很好地集成，并且它对应用程序开发人员的影响是众所周知的。
如果不在数据库级别实现关系，那将是疯狂的。
It seems that you are turning the problem upside down.
The answer is of course: no, there is nothing that will force you to create relationships in the database. But why would you not do that?
That's why the database is called relational database - because it offers you a solution for this very question that is readily available, well integrated with tools and persistence layers, and it's consequences for application developers are well understood.
It would be crazy not to implement relationships at the database level.
ERD 并不是您所说的“技术处方”，而只是逻辑关系的表示。
如何在数据库或应用程序中实现它取决于您。
但数据库是执行这些关系的适当位置。
An ERD is not a "technological prescription" as you put it but simply a representation of logical relationships.
How you implement it - in the database or the application - is up to you.
But the database is the appropriate place to enforce these relationships.
ERD 图是一个显示实体关系及其基数的逻辑图，尽管它可以同时解释为表关系图或类图，但它不是它们，您仍然需要其他图。
顺便说一句，据我所知，在数据库模型中强制建立关系以维护数据库一致性总是好的。
An ERD diagram is a logical diagram that shows entity relationships and their cardinality although it can interpreted as a table relationship diagram or a class diagram at the same time yet it is neither of them and you will still need the other diagrams.
BTW,as far as I know it is always good to have enforced relationships in your database model to maintain database consistency.
我想说的是，在验证放入数据库的数据时，应尽可能冗余。
在应用程序端进行检查，以确保唯一性/数据类型有效性一切正常。 并构建数据库以拥有所需的所有关系。
不要只是让数据库/应用程序假设一切都是正确的。
这可能会为您节省几个小时来修复孤立记录和一致性问题。
I would say be as redundant as possible when it comes to validating data being put into your database.
Do checks on the app side to ensure that Uniquness/data type validity is all alright. And structure the database to have all the relationships it needs.
Don't just let the database/application assume that everything is correct.
This may save you several hours of fixing orphaned records and consistancy issues.
“它是否制定了任何技术处方......”
它看起来不像代码。 也许我错过了一些东西。
“或者只是定义关系并让我来决定如何实施它？”
这取决于您的客户。
如果他们认为图表与代码同构，那么您必须从约定或上下文中理解缺失的部分。
如果他们认为图表与代码不同构，那么您将不得不决定如何实现它。
"Is it making any technological prescriptions ..."
It doesn't look like code. Perhaps I'm missing something.
"or simply defining the relationship and leaving it up to me to decide how to implement it?"
That depends on your customer.
If they think the diagram is isomorphic to code, then you'll have to understand the missing pieces from convention or context.
If they don't think the diagram is isomorphic to code, then you'll have to decide how to implement it.