6 ms·
When you look at SQL from a logical/set-based perspective, it is by no means unintuitive. Basically, all you do is join all the tables you need and then filter
by taffer 6y ago
When you look at SQL from a logical/set-based perspective, it is by no means unintuitive. Basically, all you do is join all the tables you need and then filter out everything you don't need and maybe do an aggregation here and there.
- alexbanks 6y agoAnd with CSS, basically all you do is tell the browser how things look.
- paulryanrogers 6y agoConceptually yes. The devil is in the details: tables, flexbox, grid, div-soup, inconsistent naming, etc.
- alexbanks 6y agoSure. Conceptually is fine. But I'm pointing out how ridiculous it is to water down CSS/SQL to "Basically just _____". Nothing is hard by that logic.
- 411111111111111 6y agoSQL can do a lot more though. Triggers, functions, procedures, access control.....
- crazygringo 6y agoHow about the following: - When to use JOIN vs a subquery? - When is a subquery actually a correlated subquery? Will this destroy your performance? Or is it a critical feature? - Should you put constraints in the JOIN or in the WHERE? Will the distinction drastically affect performance? - When do you use WHERE vs HAVING? - Is the NULL from the join because no joined row was found, or because the joined row had a NULL value itself? Etc. etc. The basic concepts are simple, but the implementation details quickly become very complex, particularly when you're ensuring high performance with indices, and making sure the query uses the indices. And all of the questions I pose above have clear answers... but the answers certainly aren't obvious from SQL basic concepts. And also, while JOIN seems like it ought to be intuitive, in real life it seems like it's like pointers in C -- some people get it pretty quickly, other people struggle forever.
- jayd16 6y agoLike everything else, write it the simple/elegant way then profile it and tweak if you have to. Once you're at the point where you have to worry about these things, tuning the SQL is still probably much less complex than writing the query in your app language or figuring out how a NOSQL db can do these joins.
- izacus 6y agoIn reality it rarely works this way - there's plenty of systems which are falling apart due to "death of thousand cuts" type issues. You run a profiler and most of the queries are slow and there's no one obvious part to optimize - because developers over the years ignored basic optimizations and there are inefficiencies everywhere. E.g., for a quick practice run, try optimizing Wordpress without making it a static page via caching - how many queries will you have to optimize and how much of a codebase rewrite will it be to make it significantly more performant?
- jatone 6y agoin reality it does work that way. the problem you describe is completely different and its more a measure of system health in its entirety of the DB. it can be easier to fix or harder depending on the precise cause. but that's a standard debugging skill which isn't strictly in the DBA skillset.
- outworlder 6y agoI had way less trouble in college with relational algebra, compared with SQL. SQL is by no means intuitive. Projection, which is what you do last, comes first in the select statement. Then there are all the join types. Relational algebra, which is what SQL is ultimately based on, is much more elegant.