6 ms·

But for a lot of people, the focus there is in the "write on top" layer, because they enjoy it more (I suspect). Constraints etc are tested there. But this is

But for a lot of people, the focus there is in the "write on top" layer, because they enjoy it more (I suspect). Constraints etc are tested there. But this is caused by another shift (I didn't experience this firsthand so bear with me); early databases often had multiple clients, nowadays it's often a 1:1 relationship with one application owning the DB. Which makes putting in constraints in SQL feel clunky. The biggest casualty of that is probably stored procedures.

noisy_boy 4mo ago
> The biggest casualty of that is probably stored procedures. Not much can beat stored procs when it is dealing with multi-step heave volume stuff. But I don't miss not having to do hacks for logging and debugging compared to the flexibility offered by non-db side. For pretty much everything else, the poor ability to log and debug makes them a headache to manage. I
frollogaston 4mo ago
You can make a decent DB with minimal constraints or stored procs, meant for regular code to use. The abominations I'm talking about are like, they use an ORM, they use meaningful fields as PKs that end up being non-unique later, or they reinvent the type system by making some tables with a json field that can mean completely different things based on some enum column.