4 ms·

Sounds like a lot of referential integrity violations.

• mexicocitinluez 10mo ago
  Why would generating a PK ahead of time cause referential integrity violations? Super curious to find out.
  • sgarland 10mo ago
    The implication is that you need to know the PK ahead of time so that you can insert it into other tables which reference it as an FK without waiting for it to be returned, which further implies that you don’t have FK constraints, because the DB would disallow this. Tbf in Postgres, you can declare FKs to be deferrable, so their existence is checked at transaction commit, rather than at insertion time. If you don’t have the DB enforcing referential integrity, you need to be extremely careful in your application logic; IME, this inevitably fails. At some point, someone writes bad code, and you get data anomalies.
    • mexicocitinluez 10mo ago
      > Tbf in Postgres, you can declare FKs to be deferrable, so their existence is checked at transaction commit, rather than at insertion time.h further implies that you don’t have FK constraints, because the DB would disallow this. I'm using EF core which hooks up these relationships and allows me to persist them in a single transaction using MSSQL server. > If you don’t have the DB enforcing referential integrity I'm building an electronic medical system. I'm well aware of the benefits of referential integrity.