表具有相同的属性但不同的关系不好的做法？ [英] Are tables with the same attributes but different relationships bad practice?

问题描述

有两个具有相同属性但具有不同含义和关系的表格是不是很糟糕？

table1 的属性= table2 的属性。

然而 table1 与 table3
和
table2有关系与 table4 有关系。

这被认为是坏习惯吗？或者应该将 table1 和 table2 整理成一个表格

尽管如果将它整合到一个表中，则不会遵循 table1 也将与 table4 ？

解决方案

可以让具有相同属性的表。只要找到足够的意思/ predicates来记录你的应用程序状态。

基表有一个含义或谓词（表达式）在DBA中给出的 - （named-）空白语句。语句的空格的名称是表的列。填写空白的行将对世界做一个真正的命题进入表格。填写空白以排除关于世界的虚假命题的行被排除。即，一个表包含满足其声明的行。您不能将基表设置为某个值，而不了解其语句，观察世界并将适当的行放入表中。你不能从基地台知道世界，除非知道它的声明，而把当前行的命题当成是真实的，而不是行为的命题是虚假的。只需要声明使用数据库。

只要适当地声明关系/ FK。 ER中的R用于关系意味着关联（实体）。然而，许多自定义的ER方法和产品使用外键（FK）的关系。来自一个关联集/表中某些角色/列的FK在另一个关联集/表中的某些角色/列仅表示源中的这些角色/列的每个实体/子域必须作为关键字出现在目标的相应角色/列中。如果是这样，请声明关系/ FK。

约束表达式对应于一个命题，即一个关于世界的永远的真实陈述，同时一个关于基准表。

（From 这个答案。请参阅这个答案 re attributes / headings，这个 re predicates和这一个关系/ FKs / links。）

Is it bad to have two tables with the same attributes but with different meanings and relationships?

I.e. table1's attributes = table2's attributes.

However table1 has a relationship with table3 and table2 has a relationship with table4.

Is this considered bad practice? Or should table1 and table2 be collated into one table?

Although if it were to be collated into one table wouldn't it follow that table1 would also have a relationship with table4?

解决方案

It is ok to have tables with the same attributes. Just find sufficient meanings/predicates to record your application state.

A base table has a "meaning" or "predicate (expression)" that is a fill-in-the-(named-)blanks statement given by the DBA. The names of the blanks of the statement are the columns of the table. Rows that fill in the blanks to make a true proposition about the world go in the table. Rows that fill in the blanks to make a false proposition about the world are left out. Ie a table holds the rows that satisfy its statement. You cannot set a base table to a certain value without knowing its statement, observing the world and putting the appropriate rows into the table. You cannot know about the world from base tables except by knowing its statement and taking present-row propositions to be true and absent-row propositions to be false. Ie you need its statement to use the database.

And just declare the relationships/FKs as appropriate. The R in ER is for relationship meaning association (among entities). However many self-styled "ER" methods and products use "relationship" for foreign key (FK) instead. A FK from some roles/columns in one association set/table to some in another just means that every entity/subrow for those roles/columns in the source must appear in the corresponding roles/columns of the target as a key. When that is so, declare the relationship/FK.

A constraint expression just corresponds to a proposition aka always-true statement about the world and simultaneusly to one about base tables.

(From this answer. See this answer re attributes/headings, this one re predicates and this one re relationships/FKs/links.)

这篇关于表具有相同的属性但不同的关系不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！