Add anecdote

Author: jfheins

_posts/2024-06-03-youll-regret-using-natural-keys.html

@@ -301,4 +301,20 @@ <h2 id="comments-header">
         </div>
         <div class="comment-date">2024-06-14 13:45 UTC</div>
     </div>
+
+    <div class="comment" id="fee47871b1494293b039b67d21187e6b">
+        <div class="comment-author">Julius H <a href="#fee47871b1494293b039b67d21187e6b">#</a></div>
+        <div class="comment-content">
+            <p>I'd like to comment with an example where using a synthetic key came back to bite me. My system had posts and users with synthetic IDs. Now I wanted to track an unread state across them. Naively, I designed just another entity:</p>
+            <pre>           
+public int ID { get; set; }
+public int PostID { get; set; }
+public int UserID { get; set; }
+            </pre>
+            <p>And it worked flawlessly for years. One day, however, a user complained that he always got an exception "Sequence contains more than one element". Of course I used SingleOrDefault() in application code because I expected 0 or 1 record per user and post.
+            The quick solution was deleting the spurious table row. As a permanant solution I removed the ID field (and column) so the unread state had its natural key as primary key (both columns). So if it happens again in the future, the app will error on insertin rather than querying.</p>
+            <p>Since my application is in control of the IDs and it's just a very simple join table I think it was the best solution. If the future requirements hold different kinds of unread state, I can always add the key again.</p>
+        </div>
+        <div class="comment-date">2024-07-22 14:40 UTC</div>
+    </div>
 </div>