什么是“标准名称”？对于非规范化模式？
我有兴趣了解两种数据库设计模式的标准名称，或者如果您是纯粹主义者，这可能是“问题”：
您如何称呼这些情况/非规范化？ 我自己使用“镜像属性”和“轻弹外键”，但我确信没有人会理解我:)。无论如何，情况很简单：
1）我们有两个处于“父子”关系的实体，在子实体中不仅有外键属性，还有父实体的一些其他“备份”属性。可能的情况是，地址实体中不仅有 streetId，而且还有 streetName，以支持街道列表中不存在该街道的情况（或者对于遗留数据来说更常见）。
2）子实体包含“外键”，由两个字段组成：一个标识“父表”，另一个是“父表中的键值”。这意味着首先解释，过滤它，我们知道应该加入哪个表。当然，这种关系的一致性在数据库管理系统级别上并没有得到维护，但这仍然是我在实践中有时看到的一种“父子关系”。
I'm interested in to know standard names of two database design patterns, or may be "problems" if you are purists:
How you would call those situations/denormalisations?
I'm using "mirrored attributes" and "flicked foreign key" for myself but I'm sure nobody will understand me :) . Anyway situations are simple:
1) we have two entities in "parent child" relationship and in the child entity there are not only foreign key attribute but also some other "backuped" attributes of parent entity's. It could be the situation where you have not only streetId in the address entity but also streetName to support the case where the street is absent in your streets list (or what is more often for legacy data).
2) child entity contains "foreign key" that consists from two fields : one identify "parent table", other is "key value in parent table". That means intepreting first, filtering on it, we know which table should join. Of course consistency of this relationship is not maintained on dbms level, but this is still kind of "parent child relationship" that I sometimes see in practice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
1）在标准化数据库中，列应该依赖于键，整个键，并且除了键之外什么都不依赖。 （所以请帮助我 Codd。）您当然可以对某些列进行非规范化以提高效率，但是这样您的数据库中就会出现重复的数据。这些重复的数据可能会不同步。
2）如果我理解你的意思是正确的，你的“外键”的第一列标识哪个表，而第二列是定义该表中的行的实际键。我也见过这个。对于域类型表（保险组费率 1、保险组费率 2 等）来说可能没问题，但与数据表一起使用时表示一种多重继承。在没有看到具体实例的情况下，我一般来说可以使用基表和扩展基表的一个或多个附加表来重新定义多重继承。
1) In a normalized database, the columns should be dependent on the key, the whole key, and nothing but the key. (So help me Codd.) You can certainly denormalize certain columns for efficiency, but then you have duplicated data in your database. This duplicated data can get out of sync.
2) If I understand what you're saying correctly, the first column of your "foreign key" identifies which table, while the second column is the actual key that defines the row in that table. I've also seen this. It's probably ok for domain type tables (insurance group rates 1, insurance group rates 2, etc.), but indicates a sort of multiple inheritance when used with data tables. Without seeing the specific instance, I'd say in general that the multiple inheritance could be redefined with a base table and one or more additional tables that extend the base table.