I've come to love SQL databases, and even writing raw SQL.
All the modern SQL databases are unbelievably powerful.
We Can Do Better Than SQL
91–100 of 466 posts
Re: We Can Do Better Than SQL
#92I shall name it...NoSQL.
Re: We Can Do Better Than SQL
#93Am I the only full stack dev that likes SQL?
SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.
Re: We Can Do Better Than SQL
#94Earlier quoted context omitted.
Not disagreeing with your point (if purist language nerds had their way over practicality, we'd all be writing Haskell and Prolog) but most of your nice-to-haves strike me as properties of the database engine, not SQL itself. Predictable performance - this will always be not only implementation-dependent but data-dependent as well. In order to know whether a join will be efficient or not, you need to know things like…
> Predictable performance - this will always be not only implementation-dependent but data-dependent as well This immediately jumped out at me from the parent comment. It would be entirely possible to implement a query language where you specify a plan for your query. But then you’d immediately lose the “better than SQL” competition, because your complexity and maintainability problems would skyrocket. I’ve had to de…
I wish that I could upvote your comment more than once, because this rings so true.
There certainly are (rare) situations, where you need to provide hints in one form or another, but it's really a bloody nightmare to maintain and may completely bork, when you - say - upgrade to a new version of the database engine.
I work with relational databases since the early 90s and can give you a no-bullshit money back guarantee that you (not you personally, obviously) are not smarter than the optimizer.
Usually there are weird data patterns involved if you absolutely must provide hints. But basically:
Don't do it!
Re: We Can Do Better Than SQL
#95One word of caution to those trying to improve on SQL - for the many users of SQL, technology is a secondary aspect of their jobs. Hence any replacement runs into the issue that many of its core users do not have the bandwidth to spend significant effort on learning another querying language. I will cheer everyone who tries to displace SQL, because I do think it needs to be displaced but would also want to caution su…
> I will cheer everyone who tries to displace SQL
Why? What are better alternatives, really?
Re: We Can Do Better Than SQL
#96Am I the only full stack dev that likes SQL? SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.
No, I'm with you and prefer SQL for many tasks.
SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale".
SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue.
Databases generally depend on normalization, but normalization comes with interesting scaling problems and how do you replicate normalized schemas. Thus denormalization became a thing, and then the emergence of NoSQL and document stores started to infect everywhere. The JOIN was a killer too, and then the discipline required to do sharding made it annoying to manage, so easier to manage solutions became a thing.
I'm looking at databases in a different light these days with more appreciation, but now the hot new thing is GraphQL makes things... interesting. I don't view GraphQL as a server-side solution, but a client solution to overcome the limits of HTTP/1.1. However GraphQL clients are exceptionally complicated, and I'm not sure they are worth it. The only problem is that to overcome them requires engineers "to know how to do things", but that is a hostile stance. People want to go fast and make progress, and GraphQL enables that.
Re: We Can Do Better Than SQL
#97The author seems to have overlooked the lindy effect behind SQL. SQL, like other ubiquitous technologies like Javascript and Excel hits the sweet spot of “satisficing” the user needs. Few things have the longevity of SQL in programming, and the fact that it’s battle-tested will always be a significant advantage over any new player.
Re: We Can Do Better Than SQL
#98I do not really agree with the two cons the authors listed.
Null handling isn't intuitive in the beginning, but it makes it harder to let missing data go unnoticed.
The expression / table thing can be solved like we solved it in OctoSQL[0], and I think others have solved it in a similar way. Whenever you have more than a single scalar value in expression position, just create a tuple, or tuple of tuples out of it, which does act like a single value.
Re: We Can Do Better Than SQL
#99One word of caution to those trying to improve on SQL - for the many users of SQL, technology is a secondary aspect of their jobs. Hence any replacement runs into the issue that many of its core users do not have the bandwidth to spend significant effort on learning another querying language. I will cheer everyone who tries to displace SQL, because I do think it needs to be displaced but would also want to caution su…
I often think that a great way to displace SQL would be to create a language that compiles to SQL similar to how TypeScript compiles to Javascript.
You mean like an ORM?
Re: We Can Do Better Than SQL
#100Am I the only full stack dev that likes SQL? SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.
The work I do lately tends to be missing an sql layer and yes, I miss it a lot. I loved organizing my data at that layer and having such powerful ways to query it. It felt like I could eternally find ways to optimize it, and I really enjoyed learning year after year.
Lately I use nosql for very light data and otherwise our API outputs heavily cached and extremely simple data. Adding a database as a middleman wouldn’t make sense. Still fun, but I miss Postgres!