Timeline for Categorizing columns in a database table
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 23, 2016 at 12:37 | comment | added | Caleth | alternatively, there is "actual business metadata" as well as "actual business data". I do agree with your main point, that non-key columns are all ABD | |
| Nov 23, 2016 at 12:36 | comment | added | Caleth | a surrogate PK doesn't enforce "unicity" in the presence of an other unique constraint. I would claim that the implicit unique constraint is what provides the uniqueness in a surrogate PK, and the underlying datum is meaningless | |
| Nov 23, 2016 at 12:30 | comment | added | Tulains Córdova | @Caleth Using that rationale, then the same could be said of surrogate PKs since they are enforcing "unicity", which is a business requirement for that table. But it is universally understood that having business meaning is something else, and almost any source says that surrogates have no business meaning and that is one of the "advantages" they have over natural keys. | |
| Nov 23, 2016 at 12:24 | comment | added | Caleth | because the purpose of a FK is enforcing "joinability" between tables. That there is a row in table Parent because table Child has a FK to Parent's PK is not meaningless | |
| Nov 23, 2016 at 12:22 | comment | added | Tulains Córdova | @Caleth Surrogates have no business meaning, FKs pointing to surrogates are also meaninless sinces they are a copy of the surrogates themselves. Also I'm not sure what you mean by "it represent the whole row". | |
| Nov 23, 2016 at 12:11 | comment | added | Caleth | I would call foreign keys "actual business data" also, as they are the expression of the relationship, even if the pointee is a surrogate key - it represents the whole row | |
| Nov 23, 2016 at 11:55 | history | answered | Tulains Córdova | CC BY-SA 3.0 |