Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Use a join table for multi-valued external ids
Don't store a potentially-multiple external id as a single unique scalar column.
Bad example
| 1 | export const externalIdentities = pgTable("external_identities", { |
| 2 | id: serial("id").primaryKey(), |
| 3 | personId: integer("person_id").notNull(), |
| 4 | // assumes one external id per person |
| 5 | drpAuthorId: integer("drp_author_id").unique(), |
| 6 | }); |
Explanation (EN)
A unique scalar column assumes a 1:1 relationship. When the real world allows one entity to own several external ids (a person with two CMS accounts, an old and a new one), the schema simply cannot record the second id — a later import either overwrites the first or is rejected by the unique constraint.
Objašnjenje (HR)
Jedinstveni skalarni stupac pretpostavlja odnos 1:1. Kad stvarni svijet dopušta da jedan entitet ima više vanjskih id-eva (osoba s dva CMS računa, starim i novim), shema jednostavno ne može zapisati drugi id — kasniji uvoz ili prepiše prvi ili ga unique constraint odbije.
Good example
| 1 | export const externalDrpAuthorIds = pgTable("external_drp_author_ids", { |
| 2 | id: serial("id").primaryKey(), |
| 3 | personId: integer("person_id").notNull(), |
| 4 | drpAuthorId: integer("drp_author_id").notNull().unique(), |
| 5 | }); |
| 6 | // one row per (person, external id) — a person can own any number of rows |
Explanation (EN)
Modeling the relationship as its own table keyed by the external id lets a person own any number of them, while the external id itself still stays unique across all persons.
Objašnjenje (HR)
Modeliranjem odnosa kao zasebne tablice ključane vanjskim id-em, jedna osoba može imati bilo koji broj njih, dok sam vanjski id i dalje ostaje jedinstven preko svih osoba.
Notes (EN)
If a hard schema migration is too costly right now, at minimum flag the scalar column as a known limitation in a comment and track the follow-up — don't let it look like a deliberate design choice.
Bilješke (HR)
Ako je tvrda migracija sheme trenutno preskupa, barem u komentaru označi skalarni stupac kao poznato ograničenje i zapiši follow-up zadatak — nemoj da izgleda kao namjerna odluka dizajna.