3 ms·
My advice is: don't write complicated SQL. The best thing I learned about SQL is that it can do an awful lot of clever stuff but that the vast majority of the
by dust-jacket 4mo ago
My advice is: don't write complicated SQL.
The best thing I learned about SQL is that it can do an awful lot of clever stuff but that the vast majority of the time you really don't need it. Learn the basics. Shrug the rest off.
- mrhottakes 4mo agoThis is the correct way. Much like any other kind of code, if you find yourself doing something "clever" it's time to think about whether you're really going down the right path.
- sgarland 4mo agoWhat do you consider to be clever SQL?
- 9rx 4mo agoYou don't have to get very clever. Once you get beyond inner join it starts to stick out like a sore thumb that SQL isn't relational and that you should have chosen a relational engine instead. SQL shines when you have an ORM and need a reliable backing store, though. Tradeoffs, as always.
- sgarland 4mo agoThe only true relational database engine I’m aware of is Rel [0], which is a learning tool at best, not a production-capable DBMS. I understand that SQL is pseudo-relational, but it’s as good as you’re going to get if you want something you can use for actual workloads. 0: https://reldb.org https://reldb.org
- 9rx 4mo agoPostgres was relational for the first decade of its life, until the infamous '95 release when it sold its soul to the devil. You could dig up on old version, perhaps. But, yes, the tradeoff for real-world use was already mentioned. The relational model is superior as complexity grows (although arguably the deductive model is even better), but the tablational model is superior for simple line-of-business stuff, so pick your poison. Like with all things engineering, there is never one perfect solution that satisfies everything. If, like the earlier comment suggested, you keep your SQL simple then you'll be fine.