It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Databases are machines for organizing information. If you're treating them as dumb storage you might as well put your stuff in a pile of CSVs. Especially if you're trying to manage constraints outside the place where they matter most! Database constraints are law; application logic constraints are advice.
To your specific points:
What are you really going to do differently in client code if a save fails because of a unique constraint violation as opposed to a foreign key issue? The save has failed either way, and for most cases the specific "why" is only important for debugging.
Perfectly true; however, it's less a pain in the ass than having years' worth of inconsistent data because you're not enforcing referential integrity, and unless you're doing it in the database with foreign key constraints you're not enforcing referential integrity.
Thanks for sharing, Dian. Regarding point 1, I would absolutely hate to tell the user "Error: Couldn't save data" because I don't know the exact error. If the constraint was checked by the app, though, I would know the exact constraint that failed, and I can advise the user accordingly ("That username is taken").
I'm thinking it's best to enforce constraints in both places.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Yeah, you need validation on the request before it makes it to the database. What the user enters isn't always what the database stores anyway. It'd be nice if data layers could raise precise errors in a general enough format to make communicating them to the user easy in any scenario but that'd require a lot of stuff to line up just so.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Databases are machines for organizing information. If you're treating them as dumb storage you might as well put your stuff in a pile of CSVs. Especially if you're trying to manage constraints outside the place where they matter most! Database constraints are law; application logic constraints are advice.
To your specific points:
What are you really going to do differently in client code if a save fails because of a unique constraint violation as opposed to a foreign key issue? The save has failed either way, and for most cases the specific "why" is only important for debugging.
Perfectly true; however, it's less a pain in the ass than having years' worth of inconsistent data because you're not enforcing referential integrity, and unless you're doing it in the database with foreign key constraints you're not enforcing referential integrity.
Thanks for sharing, Dian. Regarding point 1, I would absolutely hate to tell the user "Error: Couldn't save data" because I don't know the exact error. If the constraint was checked by the app, though, I would know the exact constraint that failed, and I can advise the user accordingly ("That username is taken").
I'm thinking it's best to enforce constraints in both places.
Yeah, you need validation on the request before it makes it to the database. What the user enters isn't always what the database stores anyway. It'd be nice if data layers could raise precise errors in a general enough format to make communicating them to the user easy in any scenario but that'd require a lot of stuff to line up just so.