Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'll be up-front about my preference for natural keys - use them where possible, as they'll make your life of database administration a lot easier. I established a standard in our company that all tables have the following columns:</p> <ul> <li>Row ID (GUID)</li> <li>Creator (string; has a default of the current user's name (<code>SUSER_SNAME()</code> in T-SQL))</li> <li>Created (DateTime)</li> <li>Timestamp</li> </ul> <p>Row ID has a unique key on it per table, and in any case is auto-generated per row (and permissions prevent anyone editing it), and is reasonably guaranteed to be unique across all tables and databases. If any ORM systems need a single ID key, this is the one to use.</p> <p>Meanwhile, the actual PK is, if possible, a natural key. My internal rules are something like:</p> <ul> <li>People - use surrogate key, e.g. INT. If it's internal, the Active Directory user GUID is an acceptable choice</li> <li>Lookup tables (e.g. StatusCodes) - use a short CHAR code; it's easier to remember than INTs, and in many cases the paper forms and users will also use it for brevity (e.g. Status = "E" for "Expired", "A" for "Approved", "NADIS" for "No Asbestos Detected In Sample")</li> <li>Linking tables - combination of FKs (e.g. <code>EventId, AttendeeId</code>)</li> </ul> <p>So ideally you end up with a natural, human-readable and memorable PK, and an ORM-friendly one-ID-per-table GUID.</p> <p>Caveat: the databases I maintain tend to the 100,000s of records rather than millions or billions, so if you have experience of larger systems which contraindicates my advice, feel free to ignore me!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload