[flagged]
Against SQL (2021)
21–30 of 81 posts
Re: Against SQL (2021)
#22In 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 al…
I hold a very unpopular opinion of GraphQL. I think it’s a great internal querying API. Every web backend project I’ve worked on tries to implement an API for querying data and it’s usually either fast and inflexible or flexible but slow. GraphQL allows to strike a balance, flexible and reasonably fast, with ways to optimise further.
Question is: do you need that flexibility if you have the backend for frontend? Can you design such a flexible api which makes it possible to iterate faster? If not, you just pay, in the best case, a constant overhead, or worst case, exponential overhead for each request! If you need to spend time optimizing because you have monitoring for slow queries or downtime caused by never terminating queries than most likely you’ve already eaten implementation speed advantage - if it exists at all in the first place.
Re: Against SQL (2021)
#23This 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.
Re: Against SQL (2021)
#24Feels 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
Re: Against SQL (2021)
#25This 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 JD…
The way I've heard this phrased is, for potential customers to justify switching to your solution, it can't be 10% better, it needs to be 10x better.
(And on top of that they need to clearly perceive the value of Strange New Thing, and clearly perceive the relative lack of value of the thing they have been emotionally invested in for decades...)
Re: Against SQL (2021)
#26Question 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.
I use Postgres JSON functions to return nested results. The database itself contains no JSON; just a well-normalised data model. However, the queries return nested JSON in the format required by the application, e.g. for rendering an HTML template or returning JSON to the client in a single round trip. Check out the old dogs can sort of learn new tricks in this great article: https://www.scattered-thoughts.net/writing/sql-needed-struct...
Re: Against SQL (2021)
#27I 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.
Re: Against SQL (2021)
#28Feels 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
[deleted]
Re: Against SQL (2021)
#29Take a drink every time you see a comment that didn't even open the article ;)
Re: Against SQL (2021)
#30Thing is it's good enough and extremely widely used. Given that there is close to 0 chance an alternative will take off.