Neither is starting with NOSQL thinking it might be better and then proceeding to spend way too many man years making it a relational database, when learning a bit of SQL would have handled it fine.
In my day job the question of SQL and its role keeps coming up. Some people want to propagate SQL all the way to clients like web browsers. Perhaps operating over some virtual/abstract data and not the real physical underlying data (that's a whole other layer of complexity). This seems like a bad idea/API in general.
I'm not too familiar with GraphQL but on the surface it seems like another bad idea. Shouldn't you always have some proper API abstraction between your components? My sense for this has been like GraphQL was invented out of the frustration of the frontend team needing to rely on backend teams for adding/changing APIs. But the answer can't be have no APIs?
All that said there might be some situations where your goal is to query raw/tabular data from the client. If that's your application then APIs that enable that can make sense. But most applications are not that.
EDIT: FWIW I do think SQL is pretty good at the job it is designed to do. Trying to replace it seems hard and with unclear value.
To use SQL effectively a certain amount of training is needed. But people are trained to read and write and do arithmatic. How to understand and write simple relational database queries is a broadly useful skill that should be widely taught in schools.
When it comes to written English, perhaps that could do with some reforms just as with SQL. Yet the way we write remains mostly unchanged.
Question for people who actually write app and SQL code: besides convenience, what is the upside of working with JSON in SQL over having your app construct and parse JSON objects, but storing the data in a database using more primitive types? My relatively inexperienced brain is telling me that it’s probably over complex to store and manipulate JSON objects at the DB level.
We use json columns to store raw data that comes from API responses or structured files. Anything from there we actually use gets copied out into its own strongly-typed column, but the json column remains as a type of logging/tracking as well as the original source of truth for database migrations if we need to pull a new column out, or track down some odd bug.
So I guess the author is trying to help a decision maker to make a decision when faced with a question of whether to use SQL or not. But in reality that question would be settled by other factors and contextual reasons rather than the arguments provided by the author.
For instance, analytics usecases favor SQL stores, as slicing and dicing is better done with row or column stores instead of document databases.
Also, Postgres is getting more popular for lot of usecases, so SQL is here to stay.
Most of these arguments against seem like personal preferences? For example, I understand it would be convenient to give special treatment to foreign key joins, but i personally find `fk_join(foo, 'bar_id', bar, 'quux_id', quux)` less easy to understand on it's own, without having to look up the underlying table structures to know which tables have which (ie is quux_id a column in foo or bar?). Not to mention I've never worked anywhere where foreign keys were consistently used, mostly for perf reasons.
This is mostly all true, but there is little incentive for RDBMS vendors to implement and maintain a second query language, in particular a shared cross-vendor one. Databases are the most long-lived and costly-to-migrate dependencies in IT systems, so keeping the SQL-based interface in parallel for a long time would be mandatory. This is compounded by the standardized SQL-centric database driver APIs like ODBC and JDBC. Despite the shortcomings of SQL, there is no real killer feature that would trigger the required concerted change across the industry.
Feels old when you see how it played out to become SQL for everything in the data ecosystem lately.
Even though SQL as flaws, maybe a lot, it has one upside which is: it's so easy to onboard people on it, in the data ecosystem (warehousing etc.) it means that we can do way much stuff faster than before and hire less technical people, which is great
I think "SQL" is fine, whatever, I'm used to working with multiple different query and programming languages and dialects. That includes the freedom to define abstractions over SQL that meet my personal needs.
Standard SQL is not helpful, though. If that (failed) experiment was ended, database implementations would have even more freedom to explore superior syntax. Prescriptive language standards are a mistake.
Specifically: the connector bits that deal w/ translating Relational Algebra IR expressed as GraphQL nodes -> SQL engine-specific code.
The author's comments about lack of standardization and portability might not get across just how nightmarishly different SQL dialects are.
I might put together a list of some of the batshit-insane bugs we've run into, even between version upgrades of the same engine.
I really think folks would raise an eyebrow if they understood just how much variance exists between implementations in what might be considered "common" functionality, and the sorts of contortions you have to do to get proper shims/polyfills/emulations.
What is the approach? Do you target a subset of sql which you compile onto or you have some runtime dynamic dispatch thing and fight for code reuse with the magic haskell tools?
For any language as large and complicated as SQL, it's easy to come up with a long list of design problems. The difficulty is designing something better, and then even more difficult than that is getting people to use it.
SQL is great. I've used it to implement knapsack optimization for Daily Fantasy Sports at scale. I use it in Big Data tools and RDBMS. It's pervasive in data tech.
Feel free to innovate and bring forth other RDBMS/Data query languages and tools, perhaps something may succeed and stick as long as SQL has.
22 comments
[ 5.1 ms ] story [ 42.0 ms ] thread* a list of things they don't like in sql
* a list of traits they think a replacement should exhibit by negating the first list
I was kind of hoping for some example of what this much better language should look like
SQL isn't for everything.
Neither is starting with NOSQL thinking it might be better and then proceeding to spend way too many man years making it a relational database, when learning a bit of SQL would have handled it fine.
I'm not too familiar with GraphQL but on the surface it seems like another bad idea. Shouldn't you always have some proper API abstraction between your components? My sense for this has been like GraphQL was invented out of the frustration of the frontend team needing to rely on backend teams for adding/changing APIs. But the answer can't be have no APIs?
All that said there might be some situations where your goal is to query raw/tabular data from the client. If that's your application then APIs that enable that can make sense. But most applications are not that.
EDIT: FWIW I do think SQL is pretty good at the job it is designed to do. Trying to replace it seems hard and with unclear value.
When it comes to written English, perhaps that could do with some reforms just as with SQL. Yet the way we write remains mostly unchanged.
For instance, analytics usecases favor SQL stores, as slicing and dicing is better done with row or column stores instead of document databases.
Also, Postgres is getting more popular for lot of usecases, so SQL is here to stay.
Even though SQL as flaws, maybe a lot, it has one upside which is: it's so easy to onboard people on it, in the data ecosystem (warehousing etc.) it means that we can do way much stuff faster than before and hire less technical people, which is great
Standard SQL is not helpful, though. If that (failed) experiment was ended, database implementations would have even more freedom to explore superior syntax. Prescriptive language standards are a mistake.
...Or is that the joke?
Specifically: the connector bits that deal w/ translating Relational Algebra IR expressed as GraphQL nodes -> SQL engine-specific code.
The author's comments about lack of standardization and portability might not get across just how nightmarishly different SQL dialects are.
I might put together a list of some of the batshit-insane bugs we've run into, even between version upgrades of the same engine.
I really think folks would raise an eyebrow if they understood just how much variance exists between implementations in what might be considered "common" functionality, and the sorts of contortions you have to do to get proper shims/polyfills/emulations.
Feel free to innovate and bring forth other RDBMS/Data query languages and tools, perhaps something may succeed and stick as long as SQL has.
Cheers