数据库已标准化,但生成的复合键包含 20 列
问题是存在如此巨大的关系,以至于在规范化之后它们有大约 20 个主键(复合键),它们实际上是外键。
必须将它们声明为主键以唯一标识关系。这是正确的吗?
The problem is there are relationships which are so huge that after normalizing they have like a 20 primary keys (composite keys) which are really foreign keys.
These have to be declared as primary keys to identify the relationship uniquely. Is this correct?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果你说你有“外键确实是外键,但需要声明为主键”,那么你实际上表明你缺乏进行数据库设计的能力、技能和权限。
外键和“主”键是完全不同的概念,即使对数据库设计领域有一定了解的人也不可能将它们相互混淆。
也许你可以再尝试解释一下你的意思。
If you say that you have "foreign keys that really are foreign keys but that need to be declared as primary keys", then you actually indicate that you lack the competence and the skill and the authority to be doing database design.
Foreign keys and "primary" keys are quite distinct concepts, which are quite impossible to confuse with one another by anyone who is even just remotely knowledgeable in the field of database design.
Maybe you could give it a second try to explain what it actually is that you mean.
首先,永远不要使用复合键。它们是一种糟糕的技术。它们很慢,并且当它们发生变化时维护起来是一场噩梦。
如果您需要两个或多个字段的唯一性,则不需要主键,而是需要唯一索引。将表的 PK 设为代理键(最好是 int)。
如果您尝试创建具有一对一关系的表,可以使用父表的 PK 作为子表的 PK,并在表之间设置 PK_FK 关系;然而,需要 20 个单独的一对一表是不寻常的。
First, do not use composite keys ever. They are a bad technique. They are slow and are a nightmare to maintain when they change.
If you need uniqueness over two or more fields, you do not need a primary key, you need a unique index. Make the PK of the table a surrogate key (preferably int).
If you are trying to create tables with a one-to-one relationship, it is acceptable to use the PK of the parent table as the PK of the Child table and set a PK_FK relationship between the tables; however it would be unusual to need 20 separate one-to-one tables.
听起来你的数据库很大并且有很多关系;为了简化主键情况,您可以做的一件事是将单个列定义为每个表的主键,并使用自动递增的 int 或 guid 数据类型。这样您就可以确保唯一性,并且外键至少独立于主键。
It sounds like your database is huge and has a lot of relationships; one thing you can do to simplify the primary key situation is to define a single column as the primary key for each table, and use an automatically incremented int or guid datatype. That way you can ensure uniqueness and your foreign keys are at least independent of your primary key.
我无法可视化包含 20 个与一张表有关系的表的设计。
如果不看你的数据设计,我就无法判断,但听起来你设计的是分层数据库,而不是关系数据库。
I'm having trouble visualizing a design with 20 tables that have a relationship to one table.
I can't tell without looking at your data design, but it sounds like you designed a hierarchical database, rather than a relational database.