4 ms·
It should be table stakes for any SWEs working on backend, but it's not. The DB and the code directly interacting with it are way more important than anything y
by frollogaston 4mo ago
It should be table stakes for any SWEs working on backend, but it's not. The DB and the code directly interacting with it are way more important than anything you're going to write on top. I keep ending up in situations where I'm the only SWE in the room who really knows SQL, let alone proper schema design, and I have to speak up or else they're going to build an abomination.
- Cthulhu_ 4mo agoBut 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 agoYou 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.