4 ms·
This resonated strongly with me. Almost all of the heavy DB interaction projects I've done in the last couple of years - be it in Python, Go or Java, the SQL la
by manish_gill 8y ago
This resonated strongly with me. Almost all of the heavy DB interaction projects I've done in the last couple of years - be it in Python, Go or Java, the SQL layer has almost always been raw queries going to the DB. Makes things so much easier.
I don't miss SQLAlchemy where I would trawl through documentation to figure out how to do X or Y.
As for SQL standardization, +1 to that. Learning a new pseudo-SQL is only fine if there are additional features on top of the DB, but I've encountered databases where the SQL support was present in the name only and extremely limited, with people making do with UDFs in order to achieve basic things.
- dahdum 8y agoI’ve had the same experience, and as soon as the interaction became very complex (multi table, multi row updates) we just moved it all into stored procedures.
- Udik 8y agoNever understood what's the thing with stored procedures. You soon find that an indeterminate amount of your business logic is written in stored procedures, and in an opaque language that is fit for manipulating data, not for implementing business logic; not to mention the annoyance of running updates on the database, which works ina fundamentally different way from deployable code.
- zzzeek 8y agowhat it usually means is, "we gave the DBA the job to do and now we don't deal with it at all"