4 ms·
> Similarly using Person.PersonID instead of Person.ID gives consistency in diagrams and foreign key naming. I assume you mean you just use PersonID as the for
by sbov 9y ago
> Similarly using Person.PersonID instead of Person.ID gives consistency in diagrams and foreign key naming.
I assume you mean you just use PersonID as the foreign key. This oftentimes introduces ambiguity into what the relationship actually is. I prefer names that describe the actual relationship (e.g. author, owner, approver, etc) rather than letting other people guess what it is.
- zo1 9y agoI think he's referring to using "[Table]ID" as the primary key on [Table]? So now you have to join with the Person table on Person.PersonID from your local column PersonID. I much prefer the other way around: Table.ID with foreign keys being "TableID".
- slobotron 9y agoI find "[Table]ID" to be bit more readable in joins. I.e. SELECT * FROM table1 INNER JOIN table2 USING (table1_id); vs SELECT * FROM table1 INNER JOIN table2 ON (table2.table1_id = table1.id);
- always_good 9y agoI usually want to reserve the noun like "author" as the embedded record after a join. That way "author_id" is always the key and then "author" is the json_agg joined object that embeds the whole record. Otherwise you're actually introducing ambiguity imo.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]