• @[email protected]
    link
    fedilink
    05 months ago

    I don’t think that holds true in all scenarios. You need to use a key that has some guarantees. In many systems you will use data you don’t control, like email addresses, IBANs, ISBNs, passport IDs and many more. You have zero control over those keys, but because each comes with certain guarantees, they might be suitable as a foreign key in your context.

    • @[email protected]
      link
      fedilink
      05 months ago

      Even in this scenario it’s feasible for standards to change. ISBN-15 becomes a thing and suddenly you have books that never get an ISBN-13 so your primary key constraints cause an error for trying to insert a null. Granted, you can see a lot of these changes coming but again, they come on a schedule you don’t control.

    • Eager Eagle
      link
      fedilink
      English
      0
      edit-2
      5 months ago

      These things can just be unique fields. I think the takeaway here is exactly to not use these unique fields as database keys if you have the option / if it’s up to you.

    • @[email protected]
      link
      fedilink
      English
      05 months ago

      People regularly change email addresses. Listing that as an example is a particularly bad example in my opinion.

        • @[email protected]
          link
          fedilink
          English
          05 months ago

          Ignoring secondary email addresses, what was my primary [onlineaccount] E-Mail address has changed four times.

        • @[email protected]
          link
          fedilink
          05 months ago

          Well, I use the same self hosted Email address since the late 80‘s

          Personal anecdotes are rarely pose a valid argument (unless you are designing a database specifically for users who use the same email address since the late 80’s).