<story><title>SQL Keys in Depth</title><url>https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html</url></story><parent_chain></parent_chain><comment><author>manigandham</author><text>After a decade of large systems relying on RDBMs, we now use 64-bit integers for all primary keys with a global Hi&amp;#x2F;Lo id generation system (app reserves a range of numbers on startup to assign to records automatically).&lt;p&gt;This means plenty of ID space, maintains rough numeric ordering, allows ID creation without a roundtrip for every insert, is easily portable across different databases, and produces unique IDs for every row in the database which greatly simplifies everything from caching to replication.</text></comment>
<story><title>SQL Keys in Depth</title><url>https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html</url></story><parent_chain></parent_chain><comment><author>simonw</author><text>&amp;quot;For instance, a database of hobbyist club members could include uniqueness on the two columns first_name, last_name of members. Duplicates are likely unintentional at this scale, and if necessary the constraint can be dropped. Until an actual conflict happens the key is a reasonable precaution.&amp;quot;&lt;p&gt;Absolutely do not do this.&lt;p&gt;People have names that are duplicates. A situation where someone is unable to join a club because their name clashes with an existing member is not OK.&lt;p&gt;Expecting a club administrator to be able to drop a uniqueness key from their database in order to resolve this situation is not a reasonable solution!</text></comment>