1,995 karma · joined January 17, 2014
All about SQL:
https://winand.at/ https://use-the-index-luke.com/ https://modern-sql.com/
https://use-the-index-luke.com/
You might also want to follow my other project:
And it works:
sqlite> with t(x) as (values (1), (2)) select sum(x) over (order by x) from t;
1
3The syntax used by SQL Server doesn't follow the standard. Or, in other words, the standard syntax gives an error in SQL server. However, I'll note that there is an alternative syntax in future versions of these slides.
Thanks again.
The difference is just the syntax, not the expressiveness.
Read this paper if you'd like to learn more about it: http://cs.ulb.ac.be/public/_media/teaching/infoh415/tempfeat...
I'd take ISO/IEC 9075 as an official specification: https://webstore.iec.ch/publication/59685
> and isn't as powerful as I'd always want it to be
Do you have examples? There is a lot in SQL that is not commonly known—if you let me know what you are thinking of, I might be able to show you an adequate SQL feature.
“MySQL is under new management since Oracle bought it through Sun. I must admit: it might have been the best thing that happened to SQL in the past 10 years, and I really mean SQL—not MySQL.”
There is an international SQL standard from ISO, it's just not commonly followed.
However, sometimes the standard isn't very useful in itself. For this example, FETCH FIRST x ROWS ONLY is the syntax mandated by the standard. Although some databases accept this in the meanwhile, LIMIT might have been a better choice as it is supported by more databases.
https://www.slideshare.net/MarkusWinand/modern-sql/120
Edit: ps.: Please don't use w3schools.com as a SQL reference. It's utterly outdated, prefers vendor syntax over standard and is sometimes just straight wrong.
> MySQL is very popular. According to db-engines.com, it’s the second most popular SQL database overall. More importantly: it is, by a huge margin, the most popular free SQL database.
The second sentence is linked: https://db-engines.com/en/ranking
The third sentence refers to the same source.
> 4.24.13 Known functional dependencies in the result of a <group by clause>
Not that this is about the result of a <group by clause>
edit: The matrix I have in the article is not complete. I've just picked a few examples from the standard and checked them to get an overview. I guess the fact that PostgreSQL supports some of them but MySQL more of them is well represented in the matrix.
The full text is below. I'm happy to correct, when I'm interpreting this wrong (which is perfectly possible).
Let T1 be the table that is the operand of the <group by clause>, and let R be the result of the <group by clause>. Let G be the set of columns specified by the <grouping column reference list> of the <group by clause>, after applying all syntactic transformations to eliminate ROLLUP, CUBE, and GROUPING SETS. The columns of R are the columns of G, with an additional column CI, whose value in any particular row of R somehow denotes the subset of rows of T1 that is associated with the combined value of the columns of G in that row. If every element of G is a column reference to a known not null column, then G is a BUC-set of R. If G is a subset of a BPK-set of columns of T1, then G is a BPK-set of R. G ↦ CI is a known functional dependency in R.
> I believe the main reasons are a lack of knowledge and interest among developers along with poor support for modern SQL in database products.
However, it IS getting better at the moment. Have you seen the "New SQL" systems that implement window functions? MySQL is finally adding those features and MariaDB picks other features from the standard.
There is movement.
I'll just keep on making my comparison matrices to make the differences visible. This will (hopefully) increase developers interest, which is basically a market demand. Vendors listen to market demand. evil grin
Except WITH [RECURSIVE] which is in SQLite since early 2014. Damn, I forgot to use that trivia in my MySQL bashing... ;)
Other than that, I met Richard Hipp in person some years back. He is a VERY pragmatic guy. I wrote an article about it:
https://use-the-index-luke.com/blog/2014-05/what-i-learned-a...
There is nothing against using non-standard functionality in that case. In this particular case. PostgreSQL got JSON support (~2012?) long before it was added to the standard (2016). Obviously, their JSON functions differ from the standard (as they didn't lobby their functions into the standard).
However, slowly but surely database will add the standard functionality, which makes life easier.
Having that said, the standard JSON_OBJECTAGG is more powerful as it gives you control over null handling (NULL ON NULL -vs- ABSENT ON NULL) and allows checking for duplicate keys ([(WITH|WITHOUT) UNIQUE KEYS]).
This is how standard SQL JSON_OBJECTAGG works: https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#js...
It can actually do much more:
<JSON object aggregate constructor> ::= JSON_OBJECTAGG <left paren> <JSON name and value> [ <JSON constructor null clause> ] [ <JSON key uniqueness constraint> ] [ <JSON output clause> ] <right paren>
This free technical report of ISO has some examples: http://standards.iso.org/ittf/PubliclyAvailableStandards/c06...
But there is a patch pending for this. Not sure if this gonna be included in 11.
The first feature matrix you see is about checking of functional dependencies.
For example, PostgreSQL doesn't see the functional dependency between the columns ID and MA in the result of this query.
SELECT id
, max(a) ma
FROM ...
GROUP BY id
As a consequence, this query doesn't work, because the outer query refers to MA which is not in the GROUP BY clause of the outer query: SELECT COUNT(*) cnt
, ma
FROM (SELECT id
, max(a) ma
FROM ...
GROUP BY id) x
GROUP BY id
Detecting these things makes life easier.Regardless: SQL is a statically typed language. Also the type of the result—i.e. the names and types of the columns—must be known in advance. Some databases offer extensions for "dynamic pivot".
On the other hand: it's also possible that nobody would know me without the website.
Further: I've learned so much from free online resources, why not giving something back?
I know for sure that many people buy the book because they started reading online. Also: A lot of the training I do is sold because ONE participant has read the site/book and arranges a training for the department.
TL;DR: I works fine for me.
But more importantly: the "fame" sells other services. Look here: https://winand.at/
SQL is pretty clear what null is:
> “Every [SQL] data type includes a special value, called the null value,”[0] “that is used to indicate the absence of any data value”[1]
(http://modern-sql.com/concept/null)
[0] SQL:2011-1: §4.4.2 [1] SQL:2011-1: §3.1.1.12
> “Every [SQL] data type includes a special value, called the null value,” “that is used to indicate the absence of any data value”.
(http://modern-sql.com/concept/null)
For the Boolean type, null = unknown:
> Note that the truth value unknown is indistinguishable from the null for the Boolean type. Otherwise, the Boolean type would have four logical values.
(http://modern-sql.com/concept/three-valued-logic)
Although they are very closely related, I believe the general `null` value (for any data type) and three-valued logic (null for Boolean) should be separated (that's why I have two articles).
SQL's null is a value. The difference is that processing null values does not cause exceptions in SQL.
In particular, one could argue that it is true for clustered indexes (e.g. in SQL Server or MySQL/InnoDB). In that case the table is actually in an ordered fashion and happens to be identical to the leaf-node-level of the index. However, if you argue that this level doesn't belong to the index but is just the payload, the level above the leaf nodes is as they say: it has one pointer per page.