6 ms·
This is good intiative. We need to simplify pedagogy. On a related note, I always found the syntax of SQL to be great. Someone told me that simplicity of SQL m
by dm8 8y ago
This is good intiative. We need to simplify pedagogy.
On a related note, I always found the syntax of SQL to be great. Someone told me that simplicity of SQL made relational databases even more popular. It is one of the best designed language where even someone new to the field won't feel intimidated. I'm surprised designers of SQL haven't won the Turing Award yet.
- wvenable 8y agoI teach SQL to financial people and, for the most part, it isn't too bad. When I get to joins, I teach a subset of SQL where all joins are done through INNER JOIN / LEFT JOIN syntax and that helps a lot. Joins are the part that everyone has trouble with.
- setr 8y agoTbh I usually see teachers worried about joins but its the group by/having clauses that I always watched people struggle with (at least, writing it). Ofc that might just be the emphasis on joins makes group by the next lowest hanging fruit
- deleted 8y ago[deleted]
- ranit 8y agoWhat do your abbreviations mean?
- grzm 8y agotbh = to be honest, ofc = of course Urban Dictionary (https://www.urbandictionary.com https://www.urbandictionary.com) or even just typing something like "what does tbh mean?" into your preferred search engine will often help you find likely interpretations of unknown abbreviations, in my experience.
- justinator 8y ago> or even just typing something like "what does tbh mean?" into your preferred search engine will often help you find likely interpretations I mean, that's what they did.
- Exuma 8y agoCan you explain when to really use a lateral join?
- garyclarke27 8y agoIn Postgresql, Lateral Joins enable function chaining for set returning functions. ie you can feed the results of earlier srf function to the arguments of following function. This gets around one of Postgresql most glaring omissions - table valued parameters. Is incredibly useful once you get used to them.
- andreareina 8y agoI might be misunderstanding your point, but Postgresql functions can take (and return) tables: CREATE FUNCTION fullname(person) RETURNS TEXT AS $$ SELECT $1.firstname || ' ' || $1.lastname $$ LANGUAGE SQL Could you go into a more detail wrt using lateral joins with set returning functions? I'm used to using them as a way to "extend" the row with later terms depending on prior terms as you say, but I'm not comprehending the srf case so well (or tbh the results that pop up when I search for "posrgresql set returning function").
- netcraft 8y agoIn my experience it’s relatively rare that you need them. I think of them as the for-each of joins. It evaluates row by row, not a single time. Another analogy would be a correlated subquery.
- asavinov 8y ago> Joins are the part that everyone has trouble with. There is significant problem-solution mismatch in joins and some other SQL constructs which are therefore semantically quite controversial in many use cases: https://github.com/asavinov/bistro#why-column-orientation https://github.com/asavinov/bistro#why-column-orientation
- HeavyStorm 8y agoThe syntax isn't the problem though. Join relational operation is though on itself.
- lixtra 8y agoI write a lot of sql and it is generally a nice language. But for my taste the language is to close to English and therefore redundant and inconsistent in an annoying way. Example: Select x from tbl ... Delete from tbl ... Update tbl set x=... Why change the word order?
- garyclarke27 8y agoYes,I also suggest standards committee allow the option of putting FROM clause first - this would make it easier for beginners to grok what’s going on and enable better tooling such as auto-complete.
- hyperpallium 8y agoSince there weren't any commercial relational databases available pre-SQL, this is quite true. Codd wrote a couple of query languages before, but they apparently weren't usable by mere mortals. SQL is over 40 years old, and still dominates. The most recent contenders had to position themselves in terms of SQL (NoSQL).
- codeisawesome 8y agoAlso interesting how even NoSQL (non relational) Data stores are embracing SQL or some subset or flavouring of it.
- pjmlp 8y agoOn PC the alternatives were xBase, FoxPro, Paradox and Access, so it was a no brainer that SQL eventually took over.
- m_st 8y agoI agree except one thing: SELECT cols FROM table. This should really be FROM table SELECT cols as every modern SQL editor will then be able to show you a list of available columns. See LINQ. There they had the opportunity to fix it and it works just great.
- jrockway 8y agoI mean, it works either way. Once you type the column names, it can guess the table name easily. I use DataGrip at work and it can complete the column names without knowing the table name, so it ends up not being a problem.
- dragonwriter 8y ago> Once you type the column names, it can guess the table name easily. If the query is simple enough that a natural join would work and you aren't doing FROM clause aliasing (which can be useful to make reusable queries self-documenting), sure. For more complex queries and obviously any time table or column aliasing are used, that becomes somewhere between less likely and logically impossible.
- sqldba 8y agoIt’s also how azure query language works.
- techno_modus 8y agoI personally think first about the loop/iterator organization (FROM in SQL) and only after that what I am going to do with its elements. However, SELECT a1,a2,... FROM Table AS t WHERE Condition is syntactically equivalent to Python list comprehension: [(t.a1,t.a2,...) for t in Table if Condition] Here the use of attributes (SELECT) is also written before the iterator. SELECT is also analogous to normal loops: foreach t in Table if not Condition: continue # Use t.a1, t.a2 etc. Here we first provide the loop specification while the usage of elements is written only in the body.
- lozzo 8y agoI concur. I always start with select * from table because I cannot possibly remember all the right column names