TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Against SQL

499 点作者 deafcalculus将近 4 年前

58 条评论

slx26将近 4 年前
I think the problem of this essay is that it&#x27;s overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that &quot;SQL will get the job done in the end&quot;, or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when the essay kinda explains it main point pretty well:<p>&gt;&gt; The core message [...] is that there is potentially a huge amount of value to be unlocked by replacing SQL<p>To me, a lot of people defends SQL saying that &quot;perfect is the enemy of good&quot; and that SQL simply works. Not the favourite of anyone, but everyone kinda accepts it.<p>And yeah, it&#x27;s true. People use SQL because it&#x27;s good enough, and trying to reinvent the wheel would take more work (individually speaking) than just dealing with SQL as it is right now. For large organizations where the effort could be justified, all your engineers already know SQL anyway, so it&#x27;s not so great either.<p>But for something so relevant as relational databases, perfect is not the enemy of good. <i>We do deserve better</i>. We generally agree that SQL has many pitfalls, it&#x27;s not great for any kind of user (for non-technical users, a visual programming language would work well here, more like what Airtable does, closing the bridge between spreadsheet and hardcore database, and for technical users, it does feel unwieldy and quirky). We should be more open to at least <i>consider</i> critiques and proposals for better. We might find out that people, from time to time, are making some good points.
评论 #27792233 未加载
评论 #27792118 未加载
评论 #27792297 未加载
评论 #27793175 未加载
评论 #27792211 未加载
评论 #27792002 未加载
评论 #27794973 未加载
评论 #27792016 未加载
评论 #27792719 未加载
评论 #27793538 未加载
评论 #27808165 未加载
danbruc将近 4 年前
I wonder how much of the limitation are necessary in order for the query optimizer to have any chance at finding a good execution plan. As you add more and more abstractions and more and more general computations in the middle of your queries, it will probably become harder and harder for the query optimizer to understand what you are actually trying to do and figure out how to do it efficiently. Are you not running the risk that the database will have to blindly scan through entire tables calling your user defined functions as black boxes on each row?<p>I would also guess that we could have a better SQL but I do not think it could and should look anything like a general purpose programming language because otherwise you might get in the way of efficient query execution. Maybe some kind of declarative data flow description with sufficient facilities to name and reuse bits and pieces.<p>And maybe you actually want two languages which SQL with its procedural parts already kind of has. One limited but well optimizable language to actually access the data, one more general language to perform additional processing without having to leave the server. Maybe the real problem of SQL lies mostly in its procedural part and how it interfaces and interacts with the query part.
评论 #27792615 未加载
评论 #27792585 未加载
评论 #27792267 未加载
bob1029将近 4 年前
I feel like most frustrations with SQL boil down to fighting against a shitty schema.<p>When you are sitting in a properly normalized database, it is a lot easier to write joins and views such that you can compose higher order queries on top.<p>If you are doing any sort of self-joins or other recursive&#x2F;case madness, the SQL itself is typically not the problem. Whoever sat down with the business experts on day 1 in that conference room probably got the relational model wrong and they are ultimately to blame for your suffering.<p>If you have an opportunity to start over on a schema, don&#x27;t try to do it in the database the first few times. Build it in excel and kick it around with the stakeholders for a few weeks. Once 100% of the participants are comfortable and understand why things are structured (related) the way they are, you can then proceed with the prototype implementation.<p>Achieving 3NF or better is usually a fundamental requirement for ensuring any meaningfully-complex schema doesn&#x27;t go off the rails over time.<p>Only after you get it correct (facts&#x2F;types&#x2F;relations) should you even think about what performance issues might arise from what you just modeled. Premature optimization is how you end up screwing yourself really badly 99% of the time. Model it correctly, then consider an optimization pass if performance cannot be reconciled with basic indexing or application-level batching&#x2F;caching.
评论 #27794616 未加载
评论 #27794419 未加载
评论 #27794385 未加载
评论 #27795213 未加载
NavinF将近 4 年前
&gt;The usual response to complaints about the lack of union types in sql is that you should use an id column that joins against multiple tables, one for each possible type.<p>&gt;create table json_value(id integer);<p>&gt;create table json_bool(id integer, value bool)<p>&gt;create table json_number(id integer, value double);<p>No, the usual response is &quot;Don&#x27;t do that!&quot;<p>99% of the time you either know the data types (so each JSON object becomes a row in a table where the column names are keys) or you don&#x27;t know the data types and store the whole object as a BLOB<p>I&#x27;d be on board with adding unions to SQL, but I doubt I&#x27;d use that feature very often.
评论 #27791935 未加载
progre将近 4 年前
I do love SQL and at least where I live (MS SQL Server) it can be made to run amazingly fast if you take some care with your queries and indexes. It&#x27;s not portable though: as far as I know not a single one of the big sql vendors follows the standards 100% and more importantly, spending some time with one vendor will give you some habits that are sure to not work as well with another (cursor constructs are generally a death blow to performance in tsql but they are <i>the way to do it</i> on oracle for example). So I kind of agree with the author here.<p>But I also feel that maybe they are asking a bit much from SQL. The complaint that complex subqueries are complex... Well then don&#x27;t use them? I would use WITH constructs in that situation because I find them easier to read but that&#x27;s beside the point. I think its perfectly fine to pull out multiple result sets from simple queries and then do the complex stuff in your host language.
评论 #27791809 未加载
评论 #27791878 未加载
评论 #27791815 未加载
评论 #27795118 未加载
评论 #27791821 未加载
评论 #27791791 未加载
james_woods将近 4 年前
SQL was not made for programmers alone. It has been invented also for not so technical people so that verboseness and overhead is part of the deal.<p>&gt;<i>When Ray and I were designing Sequel in 1974, we thought that the predominant use of the language would be for ad-hoc queries by planners and other professionals whose domain of expertise was not primarily data- base management. We wanted the language to be simple enough that ordinary people could ‘‘walk up and use it’’ with a minimum of training.</i><p><a href="https:&#x2F;&#x2F;ieeexplore.ieee.org&#x2F;document&#x2F;6359709" rel="nofollow">https:&#x2F;&#x2F;ieeexplore.ieee.org&#x2F;document&#x2F;6359709</a>
评论 #27792332 未加载
评论 #27791906 未加载
评论 #27792553 未加载
erezsh将近 4 年前
I share the author&#x27;s point of view, which led me to start a new relational programming language that compiles to SQL. It&#x27;s a way to build on existing databases, like postgres or mysql, with all of their advantages, but improve on many of SQL&#x27;s limitations.<p>If that sounds interesting, you can find it here: <a href="https:&#x2F;&#x2F;github.com&#x2F;erezsh&#x2F;Preql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;erezsh&#x2F;Preql</a>
评论 #27795039 未加载
评论 #27825275 未加载
评论 #27792544 未加载
PudgePacket将近 4 年前
This is a great article and you can tell the author has deep experience with SQL from the way they speak and the other projects they&#x27;re involved in.<p>I think many of the comments here are missing the point by saying &quot;Oh you can get around that issue in that example snippet by doing X Y Z&quot;. Sure there are workaround for everything if you know the One Weird Trick with these 10 gotchas that I won&#x27;t tell you about... but that just makes the authors point.<p>We can do better. We deserve better.<p>What could things look like if you could radically alter the SQL language, replace it altogether, or even move layers from databases or applications into each other?<p>Who knows if it will be better or worse, but I&#x27;d like to find out.
latte将近 4 年前
SQL and the relational model mostly works well and it&#x27;s probably not practical to redo the enormous amount of work that was invested in SQL and its implementations and extensions.<p>As someone who frequently used SQL for analytics and less frequently for app development, I would gladly use a language that would transparently translate to SQL while adding some syntactic niceties, like Coffeescript did to JS:<p>- Join &#x2F; subquery &#x2F; CTE shortcuts for common use cases (e. g. for the FK lookups that are mentioned in the article)<p>- More flexible treatment of whitespace (e. g. allow trailing commas, allow reordering of clauses etc.)<p>And for the language to be usable, it would probably need: - First class support for some extended SQL syntax commonly used in practice (e.g. Postgres&#x27;s additions)<p>- integration with console tools (e.g. psql), common libraries (e.g. pandas, psycopg2) and schema introspection tools<p>- editor support &#x2F; syntax highlighting.<p>It would probably be good to model the syntax of that language on some DSL-friendly general purpose language (like Scala, Kotlin or Ruby).
评论 #27792790 未加载
js4ever将近 4 年前
After a little bit more than 2 decades of coding, SQL is nearly the only thing that was constant in my career.<p>It&#x27;s a skill I used every working day, I&#x27;m pretty sure I will still use it in 20 years.<p>On the other side, tt&#x27;s very unlikely that the ORM &#x27;du jour&#x27; will exist in 3 years from now.
评论 #27792697 未加载
smitty1e将近 4 年前
&gt; First, while SQL allows user-defined types, it doesn&#x27;t have any concept of a union type.<p>Isn&#x27;t a union type essentially a de-normalized field?<p>This seems like attacking arithmetic operators for their lousy character string support.<p>Weren&#x27;t XML databases (briefly) a (marketing) thing some decades back?<p>One idea might be to have everyone integrate jq[1] into their database engines. My understanding is that one can make the JSON do back flips with jq. Then we can move to complaining about queries that appear to have been written in Klingon instead of boring ol&#x27; SQueaL.<p>[1] <a href="https:&#x2F;&#x2F;stedolan.github.io&#x2F;jq&#x2F;manual&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stedolan.github.io&#x2F;jq&#x2F;manual&#x2F;</a>
评论 #27792619 未加载
评论 #27792815 未加载
评论 #27792590 未加载
SPBS将近 4 年前
SQL is a pretty warty implementation of relational databases (with non-composability being its primary sin IMO), but we&#x27;re stuck with it at this point. A new querying DSL that fixes all of SQL&#x27;s flaws is only half the story, getting enough programmers on the planet to buy into it is another half. To do that you&#x27;d need this new piece of software to at least be as fast and as battle tested as existing SQL databases. Even the new generation of massively-scalable relational databases stick with some form of SQL instead of inventing a new DSL because of the sheer momentum behind this sorry syntax.
sizzler将近 4 年前
Anybody can criticise SQL, programming languages, etc. It isn&#x27;t hard and it doesn&#x27;t make you better than the people that wrote them. When someone says &quot;this thing that has been working fine for decades needs to be completely replaced&quot; and barely mentions any alternative, I don&#x27;t think they understand the process involved in replacing things or the terrible (non) proposition they are offering.<p>Increment on SQL, write a translation layer, and see if people adopt it. Maybe 10 years from now your idea will be more popular than standard SQL. Most likely your idea sucks though and you will stay in the easy land of criticising things.<p>The front-end is infinitely more complex than SQL on the backend. I write fairly common web applications and the SQL part is maybe 10% of my time, and very easy. React is where I spend most of my time. I don&#x27;t have any problem that really needs to be solved. SQL works for me even though it isn&#x27;t perfect. Any imperfections can most likely be incrementally fixed. I use tagged templates in JavaScript to deal with parameters, composability, and reusability.<p>The fact the the author highlights GraphQL as supposedly the great alternative shows how ridiculous the proposition is. GraphQL does basically nothing. It is 10% of the functionally of SQL.
评论 #27792298 未加载
pjungwir将近 4 年前
It would be really cool if databases had an Option&lt;T&gt; type. Then you could remove all the NULLs. Although you can mark a column as NOT NULL, that restriction doesn&#x27;t &quot;travel&quot;: it isn&#x27;t present for function inputs&#x2F;outputs, subquery results, etc. Adding it to the type system gives you a lot more mileage. And then joins could be option-aware: an inner join would have outputs matching the input types, but an outer join would have Option outputs (for at least one side).<p>I&#x27;m curious how much work has been done on optimizers for Tutorial D or other D variants. It looks way nicer to use, but I wonder if it is easier to stumble into pathological cases.
评论 #27797343 未加载
评论 #27791996 未加载
评论 #27791897 未加载
tome将近 4 年前
The only way out that I can see is to design embedded domain specific languages (EDSLs) that inherit the expressiveness, composability and type safety from the host language. That&#x27;s what Opaleye and Rel8 (Postgres EDSLs for Haskell do. Haskell is particularly good for this. The query language can be just a monad and therefore users can carry all of their knowledge of monadic programming to writing database queries.<p>This approach doesn&#x27;t resolve all of the author&#x27;s complaints but it does solve many.<p>Disclaimer: I&#x27;m the author of Opaleye. Rel8 is built on Opaleye. Other relational query EDSLs are available.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;tomjaguarpaw&#x2F;haskell-opaleye&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tomjaguarpaw&#x2F;haskell-opaleye&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;circuithub&#x2F;rel8&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;circuithub&#x2F;rel8&#x2F;</a>
kthejoker2将近 4 年前
As someone from the analytics side who&#x27;s been working with SQL for 30 years (First Choice, remember that?) (but who also wrote a fair share of ORM boilerplate), I find these debates fascinating .. but also kind of trivial, in the sense that SQL has a lot of <i>other</i> pros and cons that app devs rarely consider.<p>Truly it is blind men evaluating an elephant.<p>Given SQL&#x27;s roots as a human-friendly declarative interface, the only thing I see completely replacing it in the near future is a Copilot-style neural implant where you just think of the results you want.
ngrilly将近 4 年前
A more pragmatic view in that article: <a href="https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;some-opinionated-sql-takes&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;some-opinionated-sql-takes&#x2F;</a>
评论 #27792549 未加载
rawoke083600将近 4 年前
I&#x27;ve been thinking about this problem a lot, CRUDs, GraphQL,ORMs, Models etc. Mostly in the &quot;CRUD-Like&quot; environment. I have been thinking about a &quot;client side SQL impl&quot;.<p>In most CRUD&#x27;s we currently have on the backend layers and layers of software with ORMS, frameworks etc, and it all boils down to &quot;Writing&#x2F;Generating the correct(good-enough) SQL&quot;<p>We now have added stuff like GraphQL, which if you squint hard enough (ok very hard) can be seen as being a SQL alternative(Language to get the actual data).<p>Maybe SQL + &quot;GraphQL-Like&quot; Layers should &quot;evolve&quot; into ONE common &quot;data scripting language&quot; ?<p>Maybe we have something like &quot;ClientSide-SQL&quot; - which can be a subset of ServerSide-SQL ?<p>We need the &quot;TypeScript&quot; of &quot;data-querying&quot; which can be run on the server,client, moon and my device, where one can also only define any &quot;Types&quot; ONCE.<p>Anywhoo - I think there is still a lot to be done, researched and discovered in this section of CS :)
评论 #27794825 未加载
twodave将近 4 年前
We have a general rule on our team that complex SQL is a code smell. In our project complex queries are usually an indication of a poor design.<p>Anything SQL that can be made simpler via dynamic generation (which is safe as long as you use proper parameters for user inputs) is favored over creating logical branches in queries. Anything that can be processed further quickly in memory in the app (mapping operations, string ops, ordering&#x2F;filtering predictably small data sets, etc.) we tend to offload from SQL into something more suitable.<p>And we tend to solve a class of problem in our data layer and reuse those generalized patterns heavily. This makes our codebase predictable even when dealing with unfamiliar subject matter.<p>Of course there are always places where some complex query is necessary (especially when building reports), but if it’s status quo then you’re doing something wrong—-it’s only a matter of time until you end up with a performance nightmare on your hands.
评论 #27798638 未加载
评论 #27794580 未加载
thinkr42将近 4 年前
Though verbose and somewhat strange at times, one thing I love about SQL is that the query statements read like a set definition from set theory. That declarative nature is pretty powerful IMO, sure there are hiccups but it is a different way of thinking.
评论 #27792991 未加载
评论 #27793043 未加载
benjiweber将近 4 年前
&gt; By far the most common case for joins is following foreign keys. SQL has no special syntax for this<p>You can use NATURAL JOIN<p>select * from foo natural join bar<p>Works as long as the keys are named the same. However, a lot of people have a habit of naming keys differently in the two tables.
评论 #27792428 未加载
评论 #27791882 未加载
评论 #27792292 未加载
croes将近 4 年前
&gt;what if we want to return the salary too?<p>&gt;the only solution is to change half of the lines in the query<p>How about adding a second subquery for the salary.
评论 #27791729 未加载
评论 #27791681 未加载
Izkata将近 4 年前
The GROUP BY section is odd:<p>&gt; You can use as to name scalar values anywhere they appear. Except in a group by.<p><pre><code> -- can&#x27;t name this value &gt; select x2 from foo group by x+1 as x2; ERROR: syntax error at or near &quot;as&quot; LINE 1: select x2 from foo group by x+1 as x2; -- sprinkle some more select on it &gt; select x2 from (select x+1 as x2 from foo) group by x2; ?column? ---------- (0 rows) </code></pre> Looking at that first one I&#x27;m just kinda like &quot;well duh, there&#x27;s nothing special there&quot; - it doesn&#x27;t work with ORDER BY either, you use that to rename columns (on SELECT) or tables (on FROM and JOIN).<p>And then it goes on to show ways to work around that:<p>&gt; Rather than fix this bizaare oversight, the SQL spec allows a novel form of variable naming - you can refer to a column by using an expression which produces the same parse tree as the one that produced the column.<p>Instead of just... using the renamed column?<p><pre><code> select x+1 as x2 from foo group by x2;</code></pre>
评论 #27794776 未加载
评论 #27797359 未加载
nojvek将近 4 年前
I agree with the Author. SQL is not a great query language. Almost every decently sized app I have written I have needed some sort of a query compiler so I don’t have to deal with nuances.<p>Also agree that GraphQL is a pretty fantastic language for working with graphs. And that relational databases are essentially graphs. Hasura is neat.
fbn79将近 4 年前
Admit have not read the article but has of my personal experience I think the hostility of developers vs SQL came from lack of fundamental formation and experience in declarative programming and full constant every day immersion in imperative programming.
评论 #27792171 未加载
评论 #27792011 未加载
评论 #27792075 未加载
评论 #27791986 未加载
thayne将近 4 年前
&gt; So instead the best we can do is add json to the SQL spec and hope that all the databases implement it in a compatible way (they don&#x27;t).<p>Of course they are incompatible. That&#x27;s just par for the course when it comes to SQL.
chris_wot将近 4 年前
<i>This isn&#x27;t just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write.</i><p>20% longer to write than what alternative? And how is this being measured?<p>And.. am I missing something?<p><i>By far the most common case for joins is following foreign keys. SQL has no special syntax for this:</i><p><pre><code> select foo.id, quux.value from foo, bar, quux where foo.bar_id = bar.id and bar.quux_id = quux.id </code></pre> Why can&#x27;t this be expressed as an INNER JOIN?<p>And can&#x27;t some of these subqueries be written using a WHERE EXISTS or a windowing function?
评论 #27792121 未加载
评论 #27791783 未加载
评论 #27791760 未加载
_the_inflator将近 4 年前
I feel the pain.<p>As someone who only uses SQL a couple of times a year, I feel that SQL shares the same fate as everything in IT: invented almost 50 years ago, not with today&#x27;s world in mind, it has been blown up somewhat. Reminds me a bit of JavaScript: everything that can be done in JavaScript, will be done in JavaScript.<p>Like after C followed C++ and here Java and others there will be new DSL and techniques on top of SQL.<p>The article has its merits. Better abstractions for different use cases.
评论 #27792034 未加载
jackbravo将近 4 年前
Here in hacker news it was posted this article about the story of SQL biggest rival, QUEL, which is pretty related: <a href="https:&#x2F;&#x2F;www.holistics.io&#x2F;blog&#x2F;quel-vs-sql&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.holistics.io&#x2F;blog&#x2F;quel-vs-sql&#x2F;</a>?<p>It is not that we didn&#x27;t try to replace it, but just as other comments have said, SQL was good enough, and already has the biggest mind share.
asavinov将近 4 年前
One alternative to SQL (type of thinking) is Column-SQL [1] which is based on a new data model. This model is relies on two equal constructs: <i>sets</i> (tables) and <i>functions</i> (columns). It is opposed to the relational algebra which is based on only sets and set operations. One benefit of Column-SQL is that it does not use joins and group-by for connectivity and aggregation, respectively, which are known to be quite difficult to understand and error prone in use. Instead, many typical data processing patterns are implemented by defining new columns: <i>link columns</i> instead of join, and <i>aggregate columns</i> instead of group-by.<p>More details about &quot;Why functions and column-orientation&quot; (as opposed to sets) can be found in [2]. Shortly, problems with set-orientation and SQL are because producing sets is not what we frequently need - we need new columns and not new table. And hence applying set operations is a kind of workaround due the absence of column operations.<p>This approach is implemented in the Prosto data processing toolkit [0] and Column-SQL[1] is a syntactic way to define its operations.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;asavinov&#x2F;prosto" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;asavinov&#x2F;prosto</a> Prosto is a data processing toolkit - an alternative to map-reduce and join-groupby<p>[1] <a href="https:&#x2F;&#x2F;prosto.readthedocs.io&#x2F;en&#x2F;latest&#x2F;text&#x2F;column-sql.html" rel="nofollow">https:&#x2F;&#x2F;prosto.readthedocs.io&#x2F;en&#x2F;latest&#x2F;text&#x2F;column-sql.html</a> Column-SQL (work in progress)<p>[2] <a href="https:&#x2F;&#x2F;prosto.readthedocs.io&#x2F;en&#x2F;latest&#x2F;text&#x2F;why.html" rel="nofollow">https:&#x2F;&#x2F;prosto.readthedocs.io&#x2F;en&#x2F;latest&#x2F;text&#x2F;why.html</a> Why functions and column-orientation?
mlinksva将近 4 年前
Inspiring article (I love SQL, but it&#x27;s also frustrating). My only wish would be to see the criticisms used as a checklist to evaluate SQL improvements or new query languages.<p>EdgeQL, indirectly linked at the end of the article, looks at a glance like it might score well. EdgeDB&#x27;s blog post [1] criticizing SQL and introducing EdgeQL seems to cover the same concepts (inexpressive, incompressible, non-porous) with slightly differing language in some cases (e.g.. system cohesion for porousness).<p>Noticed after posting this comment that there&#x27;s a post today about EdgeQL. [2]<p>[1] <a href="https:&#x2F;&#x2F;www.edgedb.com&#x2F;blog&#x2F;we-can-do-better-than-sql" rel="nofollow">https:&#x2F;&#x2F;www.edgedb.com&#x2F;blog&#x2F;we-can-do-better-than-sql</a> [2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27793398" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27793398</a>
historyloop将近 4 年前
SQL isn&#x27;t immutable, it&#x27;s always evolving. I find it awkward some of the arguments in the article read like &quot;you couldn&#x27;t do that before CTE was added&quot;. But it WAS added, so?<p>If you want to fix SQL, contribute to the next version of the standard, or provide example by implementing what you want to see out there.
jmull将近 4 年前
So what?<p>Complaining about SQL is the easy part. Actually, it&#x27;s the first skill most new SQL developers truly master.<p>I&#x27;m waiting for the viable alternative. There are a lot (a LOT) of solutions that handle some cases, but inevitably you need to get into the SQL anyway because that&#x27;s the DBMS&#x27; native API (and now you also need to fight your way through the abstraction, oh and since there are a LOT of solutions a different one is used every chance someone gets, so you need to relearn how to fight through the abstraction all the time).<p>I doubt it&#x27;s going to change. There&#x27;s actually no significant reason. SQL (actually, the set of mutually incompatible SQL variants) is thoroughly entrenched and a small problem... that is, it&#x27;s rarely the dominant reason a project&#x2F;product succeeds or fails, or takes too long, or becomes unmaintainable, etc.
jandrewrogers将近 4 年前
Another subtle issue with SQL is that it tacitly assumes a great deal about the internal architecture of the database engine implementing it. SQL is designed to be easy to implement for the way SQL databases worked in the 1990s. Unfortunately, modern high-end databases today have radically different internal architectures, are capable of much greater internal expressivity as a minimum, and are designed to support data models as first-class citizens that weren&#x27;t even on the radar in the 1990s. Patching the first-class capabilities of modern database kernels into the SQL language, such as generalized recursion, can often be awkward or require non-standard syntax or behaviors that defeat easy optimization. The DDL has similar issues, particularly around its concept of what an &quot;index&quot; can look like under the hood or the myriad ways in which data can be organized.<p>I&#x27;ve used and even written SQL databases for much of my career. SQL is pretty satisfactory for what it was designed to do. I view SQL like classic inheritance-based OOP; it works well for the problem domains for which it was originally designed, but is poor for efficiently expressing problem domains that are better expressed in a composition-based or functional way. Yet it worked so well in its original domain that we try to apply it everywhere. The diversity of data models and the kinds of operations we want to do with them today is far greater than was considered when SQL crystallized into its current form.<p>The limitation of most nominal SQL replacements I&#x27;ve seen is that they commit the same sin of SQL originally: overfitting for a problem domain that the designer was most interested in. There is an appetite for a really good SQL replacement if done well, and in principle anything SQL can do could be directly translated into a new language for compatibility.
ComodoHacker将近 4 年前
&gt;By far the most common case for joins is following foreign keys. SQL has no special syntax for this<p>That&#x27;s because there can be more than one FK relationship between the same two tables. For example, if we model a binary tree, there could be references to left, right and parent nodes.
KingOfCoders将近 4 年前
We&#x27;re currently moving into a different direction, removing Spark Code to move most of the stuff into BigQuery SQL (which can use structs, one of the points of the article), because it&#x27;s easier for Data (Engineers|Analysts|Scientists) to write SQL than e.g. Scala.
评论 #27793685 未加载
LeonB将近 4 年前
I would like a typescript style transpiler tool chain for testing out new language features that are seamlessly transpiled down to existing sql.<p>Once that’s in place I don’t know which features I’d want first… but there’s a lot of them!
mcv将近 4 年前
Having worked a lot with neo4j, a graph DB, over the past two years, I must say I&#x27;m surprised how rigid and inexpressive SQL is by comparison. We started our project with a SQL database, but some queries would be 10 or more lines with multiple joins. Very hard to read. Once we switched to neo4j, the same query was a single, easily readable line.<p>SQL is very well-established, but it&#x27;s also old, and it shows its age. It&#x27;s kinda weird how easily we jump from one programming language to another, and yet we can&#x27;t seem to move on from our main relational query language.
cm2187将近 4 年前
One thing I don&#x27;t understand in SQL is why creating a tmp table is so verbose, why we can&#x27;t use type inference.<p>There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end:<p><pre><code> @t = select colA, colB from tbl select top 10 * from @t order by colB</code></pre>
评论 #27791771 未加载
评论 #27791757 未加载
评论 #27791756 未加载
AtNightWeCode将近 4 年前
Not that bad workarounds. The N + 1 problem is usually not a big issue with ORM:s but one should the check the generated code I think. Seen far worse written code. (Well, if you don&#x27;t do SELECT *...)<p>I have other issues with SQL:<p>The linear way resources are needed with the amount of data but no built in way to handle it.<p>That integer ids are way overused and basically locking every database to a specific environment.<p>The index tweaking.<p>The workarounds for write speed.<p>The fact that you can do anything in SQL and people know it.
lenkite将近 4 年前
Been coding for over a decade and written thousands of simple and complex queries and I have always thought SQL sucked but was too afraid to ever express that opinion since everyone else believes it is the best thing since sliced bread. Quite relieved that some experts feel the same way.
zug_zug将近 4 年前
I guess I don&#x27;t get it. It uses a bunch of big sounding technical terms (&quot;inexpressive&quot; &quot;non-pourous&quot;) to criticize sql, but when I actually read it this seems to be mostly miniscule details that could be added trivially to an SQL engine if there was demand. For example, joining natively on foreign key seems like a trivial convenience, I&#x27;m not sure it proves any larger point to me, many people prefer code that is more verbose and clear about what it does than magical&#x2F;implicit.<p>Another example complaint hidden behind a ominous-sounding word boils down to &quot;Using a table expression inside a scalar expression is generally not possible, unless the table expression returns only 1 column and either a) the table expression is guaranteed to return at most 1 row or b) your usage fits into one of the hard-coded patterns such as exists.&quot;<p>Uh, great I&#x27;ve never needed to do that in my career, and so if you care so much make a PR, but suggesting that SQL itself is somehow the problem is laughable. It would be orders of magnitude more effort to try to standardize the industry on a new query language than to patch table expressions. I can scarcely imagine what a productivity loss it would be to the industry of SQL standardization were dropped, it would be much worse than python 2&#x2F;3 debacle.<p>Also &quot;incompressible&quot; - Sounds like the author doesn&#x27;t use views&#x2F;materialized-views.<p>Finally the &quot;fragile&quot; example is just the author writing a bad query. The example here is performant and less fragile: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;612231&#x2F;how-can-i-select-rows-with-maxcolumn-value-partition-by-another-column-in-mys" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;612231&#x2F;how-can-i-select-...</a><p>etc.
bvrmn将近 4 年前
&gt; fk_join(foo, &#x27;bar_id&#x27;, bar, &#x27;quux_id&#x27;, quux)<p>This example has same amount of semantic entities as in SQL. Also there is USING. Also why author needs a strict modeling over json when one can model in native types? It&#x27;s a very strange article.
评论 #27791942 未加载
Crash0v3rid3将近 4 年前
I’m always asked how I am so good at sql. I laugh given I know how crappy my sql skills are. It’s really that I just know our schema so well I can formulate a decent enough query to extract what I need.<p>Knowing your schema design is just as important as knowing sql.
JoelJacobson将近 4 年前
I suggest using the fact foreign keys are constraints with unique names, and using these names to explicitly specify what column(s) to join between the two foreign key tables.<p>In PostgreSQL [2], foreign key contraint names only need to be unique per table, which allows using the foreign table &quot;as is&quot; as the constraint name, which allows for nice short names. In other databases, the names will just need to be a little longer.<p>Given this schema:<p><pre><code> CREATE TABLE baz ( id integer NOT NULL, PRIMARY KEY (id) ); CREATE TABLE bar ( id integer NOT NULL, baz_id integer, PRIMARY KEY (id), CONSTRAINT baz FOREIGN KEY (baz_id) REFERENCES baz ); CREATE TABLE foo ( id integer NOT NULL, bar_id integer, PRIMARY KEY (id), CONSTRAINT bar FOREIGN KEY (bar_id) REFERENCES bar ); </code></pre> We could write a normal SQL query like this:<p><pre><code> SELECT bar.id AS bar_id, baz.id AS baz_id FROM foo JOIN bar ON bar.id = foo.bar_id LEFT JOIN baz ON baz.id = bar.baz_id WHERE foo.id = 123 </code></pre> I suggest adding a new binary operator, allowed anywhere where a table name is expected, taking the table alias to join from as left operand, and the name of the foreign kery contraint to follow as the right operand.<p>Perhaps &quot;-&gt;&quot; could be used for this purpose, since it&#x27;s currently not used by the SQL spec in the FROM clause.<p>This would allow rewriting the above query into this:<p><pre><code> SELECT bar.id AS bar_id, baz.id AS baz_id FROM foo JOIN foo-&gt;bar LEFT JOIN bar-&gt;baz WHERE foo.id = 123 </code></pre> Where e.g. &quot;foo-&gt;bar&quot; means:<p><pre><code> follow the foreign key constraint named &quot;bar&quot; on the table&#x2F;alias &quot;foo&quot; </code></pre> If the same join type is desired for multiple joins, another idea is to allow chaining the operator:<p><pre><code> SELECT bar.id AS bar_id, baz.id AS baz_id FROM foo LEFT JOIN foo-&gt;bar-&gt;baz WHERE foo.id = 123 </code></pre> Which would cause both joins to be left joins.<p><pre><code> SELECT bar.id AS bar_id, baz.id AS baz_id FROM foo LEFT JOIN foo-&gt;bar-&gt;baz WHERE foo.id = 123 </code></pre> [1] <a href="https:&#x2F;&#x2F;scattered-thoughts.net&#x2F;writing&#x2F;against-sql&#x2F;" rel="nofollow">https:&#x2F;&#x2F;scattered-thoughts.net&#x2F;writing&#x2F;against-sql&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;</a>
评论 #27793089 未加载
gumby将近 4 年前
SQL is a COBOL-era language — though there are 15 years between them, language theory was quite rudimentary at that time.<p>But it exists and is adequate. And, as Gabriel’s famous essay says, Worse is Better.
tritiy将近 4 年前
Was this written by a nnet? I found it so hard to read as if it author has written it in another language and then used some weird translation engine.
cletus将近 4 年前
The complexity of the SQL spec is a fair point. Inconsistencies between implementations has some merit but in practice doesn&#x27;t really matter (eg how often do you really replace your database?).<p>A lot of the rest of it reads like the author started with this conclusion and then went looking for justification.<p>Example: the author states it&#x27;s hard to return more than one column with a correlated subquery. That&#x27;s what with clauses or join with queries are for. The author later mentions with statements so is aware of them.<p>As for JSON, I honestly don&#x27;t think anybody needs that. Either return a JSON blob (generally bad idea IMHO) or you need to construct it in code.<p>The example of join verbosity has issues too. First, abbreviated syntax would need to express what kind of join to do (eg inner vs outer). Second, I find this fairly natural:<p><pre><code> SELECT ... FROM a JOIN b ON a.id = b.a_id LEFT OUTER JOIN c ON b.id = c.b_id </code></pre> The author instead used this syntax:<p><pre><code> SELECT FROM a, b, c WHERE a.id = b.a_id AND b.id = c.b_id </code></pre> The also leaves the join type unexpressed. In some SQLs you say:<p><pre><code> AND b.id = c.b_id (+) </code></pre> But that&#x27;s kind of ugly and old-fashioned. The first syntax is preferable and clear.<p>On &quot;compressability&quot;, SQL has this. They&#x27;re called views. GraphQL has a notion called fragments that SQL doesn&#x27;t. This is one of those things that sounds like a good idea but probably isn&#x27;t. It makes queries much harder to read and I&#x27;ve seen this reach the point where a fragment is so widely used changing it is expensive (eg generated code) and removing anything is impossible. Plus a lot of users end up querying things they don&#x27;t need.<p>Poor optimization and error messages of with clauses aren&#x27;t really an argument against SQL. They&#x27;re an argument against particular implementations. Extracting an anonymous query into a WITH clause should be a no-op to performance for any half-decent query optimizer&#x2F;executor.<p>Writing extensions (eg functions) should be discouraged. It&#x27;s harder to deploy and debug and the last thing you want is a badly written C function crashing your database.<p>Years ago we also had stored procedures (eg Oracle PL&#x2F;SQL) and nobody does that anymore because it&#x27;s terrible. You don&#x27;t want that.<p>There&#x27;s a lot in there about pathological corner cases that I honestly don&#x27;t really care about.<p>I do agree that ORMs are generally a disaster.<p>Lastly, it&#x27;s worth noting that SQL unless a lot of alternatives has a solid theoretical basis and that is relational algebra. SQL wasn&#x27;t created in a vacuum. SQL is just a way to express those constructs.<p>I will say that SQL got the order of clauses wrong whereas LINQ got this right. SQL should actually look more like this:<p><pre><code> FROM a WHERE a.foo = &#x27;bar&#x27; SELECT id, col1, col2 </code></pre> Honestly though, SQL just isn&#x27;t &quot;broken&quot;. That&#x27;s why it&#x27;s endured so long despite the NoSQL fad and various efforts to replace it.
patkai将近 4 年前
Am surprised that in such a long thread nobody mentions RethinkDB.
评论 #27792336 未加载
评论 #27792335 未加载
chubot将近 4 年前
Amazing critique! It has a wealth of examples -- I liked the &quot;N+1 query bugs&quot; and &quot;feral concurrency&quot; links (stuff I&#x27;ve experienced but didn&#x27;t have a name for).<p>----<p>The comparison of SQL vs. flink windowing (&quot;kernel space&quot; vs &quot;user space&quot;) reminds me of the this 2013 call to change the design of browsers feaetures:<p><a href="https:&#x2F;&#x2F;extensiblewebmanifesto.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;extensiblewebmanifesto.org&#x2F;</a><p>Basically there&#x27;s a lot of stuff implemented stuff in the C++ layer of the browser that&#x27;s impossible to emulate in JavaScript, and that&#x27;s a bad design.<p>It is indeed alarming how much syntax SQL has. It reminds me of shell, where every string manipulation function like stripping a prefix has custom syntax like ${x&#x2F;&#x2F;pat&#x2F;replace} or ${x%%prefix}. Oil (<a href="https:&#x2F;&#x2F;www.oilshell.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.oilshell.org&#x2F;</a>) will simply have functions for this, like x.sub(&#x27;pat&#x27;, &#x27;replace&#x27;).<p>----<p>I also wonder if the author has worked with dplyr and the tidyverse at all? He mentions Pandas, but IMO it&#x27;s a clunkier imitation of those ideas (and I&#x27;m saying that as a Python programmer).<p><i>Tidy data</i> was my intro to the design of dplyr: <a href="http:&#x2F;&#x2F;vita.had.co.nz&#x2F;papers&#x2F;tidy-data.html" rel="nofollow">http:&#x2F;&#x2F;vita.had.co.nz&#x2F;papers&#x2F;tidy-data.html</a><p>It&#x27;s very inspired by the relational model, but it has a few more operations like &quot;gather&quot; and &quot;spread&quot; which turn &quot;long&quot; format into &quot;wide&quot; format and vice versa.<p>It has a clean and expressive API: <a href="https:&#x2F;&#x2F;www.rstudio.com&#x2F;wp-content&#x2F;uploads&#x2F;2015&#x2F;02&#x2F;data-wrangling-cheatsheet.pdf" rel="nofollow">https:&#x2F;&#x2F;www.rstudio.com&#x2F;wp-content&#x2F;uploads&#x2F;2015&#x2F;02&#x2F;data-wran...</a><p>It composes like regular code, so you can write stuff like:<p><pre><code> bin_sizes %&gt;% select(c(host_label, path, num_bytes)) %&gt;% left_join(bytecode_size, by = c(&#x27;host_label&#x27;)) %&gt;% mutate(native_code_size = num_bytes - bytecode_size) -&gt; sizes </code></pre> Good comparison of the relational model and data frames: <i>Is a Dataframe Just a Table?</i> <a href="https:&#x2F;&#x2F;plateau-workshop.org&#x2F;assets&#x2F;papers-2019&#x2F;10.pdf" rel="nofollow">https:&#x2F;&#x2F;plateau-workshop.org&#x2F;assets&#x2F;papers-2019&#x2F;10.pdf</a><p>I link all of these in <i>What is a Data Frame? (In Python, R, and SQL)</i> <a href="https:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2018&#x2F;11&#x2F;30.html" rel="nofollow">https:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2018&#x2F;11&#x2F;30.html</a>
pjmlp将近 4 年前
&gt; Why did SQL have to add it to the language spec?<p>Most likely because there isn&#x27;t cargo for SQL, everyone has to make do with a default install offers, and most big boys databases offer FFI to Java, .NET and C.<p>&gt; This works for data modelling (although it&#x27;s still clunky because you must try joins against each of the tables at every use site rather than just ask the value which table it refers to)<p>Only if one never learned what views are for, and the various flavours they come in.<p>&gt; By far the most common case for joins is following foreign keys. SQL has no special syntax for this:<p><pre><code> select foo.id, quux.&quot;value&quot; from foo inner join bar on foo.bar_id = bar.id inner join quux on bar.quux_id = quux.id </code></pre> Really, how much time was spent learning SQL before complaining?
评论 #27791869 未加载
评论 #27792579 未加载
trapatsas将近 4 年前
There are two types of people in the world. The ones that are pro-SQL and the ones that don’t understand how SQL works
评论 #27792594 未加载
ltbarcly3将近 4 年前
Lots of the examples here are yhe author writing very poor, non idiomatic SQL and then criticizing it.<p>I could write a point by point rebuttal but I&#x27;ll just pick one point, compressibility: VIEWs.
评论 #27791847 未加载
评论 #27791732 未加载
bullen将近 4 年前
I thought they where talking about the data not being able to compress, the actual queries don&#x27;t need to be compressed.<p>But you need to separate the data and the index so you can compress the data while still searching the index, and none of the SQL databases do that because they don&#x27;t have one file per value (for obvious disk-size reasons).<p>We need to approach the database as files, even add features to our filesystems to accomodate that.<p>In my distributed HTTP&#x2F;JSON database I use ext4 type small to not run out of inodes before disk space.
评论 #27791768 未加载
historyloop将近 4 年前
Did the author forget that we had this entire &quot;NoSQL&quot; period that lasted well over a decade, where SQL was the worst thing ever, and everyone kept coming with the superior alternatives to SQL?<p>What happened?<p>What happened is many of those NoSQL products started adding SQL syntax and features to their databases, others disappears, and yet others specialized into niches where they don&#x27;t compete with SQL RDBMS at all, which remains the primary database paradigm and language.<p>So those are the facts. If someone still believes they know better, put up or shut up.
评论 #27795520 未加载
justshowpost将近 4 年前
It&#x27;s all about the background. For HLL and even basic programmers grasping SQL poses little-to-no challenges. Some are even falling in love with SQL despite some minor inconsistencies and prolix wordy verbosity and asking for writing more SQL.<p>In contrast, users of, for example, the lingo where object minus object equals NaN are terrified when suddenly exposed to type zoo like <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.5&#x2F;datatype.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.5&#x2F;datatype.html</a> (Disclaimer: a relatively randomly chosen example, neither endorsement nor preference of particular RDBMS&#x2F;dialect). And let&#x27;s keep in mind what types above form a structures and these structures getting manipulated en mass as intrinsically unordered sets (which are data types too!). That is, a leap from barely existing concept of data types to circa 30% of DDL&#x2F;DML keeps scripters out of SQL.<p>So the reason behind that endless «SQL bad» teeth gnashing turns out to be very simple.
tonymet将近 4 年前
Relational Tables &amp; SQL should be just one storage mechanism for your app.<p>What if someone told you: build an app, but only use b-trees? Then you start complaining about all the shortcomings of b-trees.<p>The point is that you have relational tables &#x2F; SQL, along with many other persistence , storage &amp; indexing mechanisms: distributed hashtables, queues, lists, etc.<p>All the apps I&#x27;ve worked on have mixed SQL with all of the other data structures with consistent or inconsistent replication among them depending on the use-case.<p>One way to manage this is a key-value online tier and a relational offline tier, with inconsistent replication online to offline.<p>SQL &amp; RDMBS are very powerful, but like any tool, limited to the designated use case. Stop trying to make it do everything.
roenxi将近 4 年前
One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn&#x27;t use<p><pre><code> function(arg, arg, arg) </code></pre> It is strange that &quot;SELECT a, b, c FROM schema.table&quot; keeps any aura of respectability. That is legitimately outdated syntax, people don&#x27;t write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and comes with downsides. It should be 2 or 3 functions, with brackets.<p>With full knowledge of SQL, the successful languages that followed it were C&#x2F;Python&#x2F;Java&#x2F;Javascript that use lots of functions and a smattering of special syntax for control structures.
评论 #27791804 未加载
评论 #27792402 未加载
评论 #27792054 未加载
评论 #27791862 未加载
评论 #27791863 未加载