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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

It's not you, it's SQL

61 点作者 tristanz超过 2 年前

19 条评论

commandlinefan超过 2 年前
The article presents the move from the old, doddering SQL to the newer, better NoSQL - but the hierarchical database model actually _predate_ SQL. The first databases like IBM&#x27;s IMS were hierarchical a lot like Mongo is: Codd was actually trying to address the problems with <i>that</i> model when he created the relational model.
评论 #34585599 未加载
评论 #34585572 未加载
Justsignedup超过 2 年前
My biggest issue with sql has and always will be the lack of definitions.<p>There&#x27;s no way to express data structure knowledge in sql, only relations and keys. Discoverability can be quite lacking. And every time I want to join table A to B I have to re-define everything, because SQL doesn&#x27;t store that.<p>ORMs help. They help because they encode relationships in meaningful ways. A has many Bs, so A.B works, and I don&#x27;t need to repeat this join logic every damn time. But ORMs have down sides too. Sometimes they generate queries that are really sub-optimal.<p>I think my favorite ORM usage was with Hibernate. I KNOW!!! THAT DEVIL! But honestly we wrote SQL in hibernate, and then invoked it to populate our data. Yes it was a bit more work than RoR&#x27;s &quot;order.items.where(&quot;price &gt; 40&quot;)&quot; but when complex things happened, it was always easier.<p>I&#x27;ve always looked at nosql as &quot;absolutely, sounds great, how do you represent relationships?&quot;
评论 #34586004 未加载
评论 #34587158 未加载
评论 #34586144 未加载
评论 #34585954 未加载
评论 #34586119 未加载
kneebonian超过 2 年前
Holy crap, now I know I&#x27;ve been in this field to long we are right back to the NoSQL vs SQL debate, for the <i>checks notes</i> 3rd time.<p>Wow.
评论 #34585907 未加载
schmichael超过 2 年前
Wow, this is written by an early mentor of mine who introduced me to CouchDB and MongoDB circa 2008! I went on to take MongoDB to Urban Airship (now Airship), make a complete mess out of things (lots of evidence of that on HN even), and eventually port it all to a Postgres cluster. Meanwhile jamwt went to Dropbox and ended up managing thousands of SQL instances of his own!<p>And now both of us are back on non-SQL datastores: Convex for him, and Nomad&#x27;s combination of Raft+MemDB for me. While Convex sounds influenced by transactional memory (define your critical section and let the platform keep trying to apply it until it succeeds), Nomad opted for Raft&#x27;s serialization of mutations. On the read side we both opted for explicit index use, so it seems fair to assume both of us feel like SQL&#x27;s decoupling of indexes from queries does more harm than good. Query planners are great until they&#x27;re not.<p>I would love a SQL (well SELECT) interface to Nomad&#x27;s datastore (MemDB). SELECT is like the C ABI for data instead of code: imperfect, but a lowest common denominator that if implemented unlocks a ton of workflows.<p>I wonder if jamwt feels the same and both projects will eventually grow a SQL adapter (or at least a SQL-like DSL... Nomad is close with bexpr filtering on a number of APIs, but JOINs would be really useful).
评论 #34586364 未加载
评论 #34586388 未加载
jrochkind1超过 2 年前
&gt; In Convex, the application and database types are automatically equivalent because the entire data pipeline from frontend to database uses the same exact types and definitions... There is no adapter code between languages because everything we write is just TypeScript.<p>It may actually be fine to just require everything to be typescript, but the idea that you&#x27;d require your application be written in the same language as your data store, and thus implement a different data store for each language you might want to write an app in (and not share between languages)... would formerly be thought of as pretty ridiculous?<p>But maybe it&#x27;s not anymore?<p>But that seems to be the requirement for &quot;the application and database types are automatically equivalent because the entire data pipeline from frontend to database uses the same exact types and definitions,&quot; yes?<p>In general, most of the purported benefits of convex seem to effectively require the db in the same language as the app, to make it all so seamless.<p>I guess we&#x27;ll see if Convex can get popular enough to spawn lots of &quot;what I wish I knew about convex a year ago&quot; and &quot;Goodbye Convex, hello Postgresql&quot; posts...
评论 #34585843 未加载
DerArzt超过 2 年前
Man what a well written ad.
评论 #34585660 未加载
eatonphil超过 2 年前
On the other side of things, it&#x27;s interesting to see SQL engines innovating. Though the only one I can name for sure is DuckDB: <a href="https:&#x2F;&#x2F;duckdb.org&#x2F;2022&#x2F;05&#x2F;04&#x2F;friendlier-sql.html" rel="nofollow">https:&#x2F;&#x2F;duckdb.org&#x2F;2022&#x2F;05&#x2F;04&#x2F;friendlier-sql.html</a>.<p>Have other implementations done anything for making queries easier (that don&#x27;t involve requiring an IDE or anything, so just query language innovations)?<p>Edit: Not query language innovations but ClickHouse and Snowflake&#x27;s &quot;standard library&quot; of builtin functions just keep getting better and better. Once I saw `parseDateTimeBestEffort` in ClickHouse I wanted that everywhere...
评论 #34585772 未加载
评论 #34587601 未加载
xpil超过 2 年前
&gt;&gt; Unlike SELECT, these operations don&#x27;t feature JOINs or subqueries or any other magic that brings together tables.<p>This is a false statement. Both INSERT and UPDATE support JOINs and subqueries &#x2F; CTEs. At least according to the standard - not every engine implementing them is another story.
评论 #34585713 未加载
评论 #34585422 未加载
cube2222超过 2 年前
If I understand correctly this is basically trying to solve a very similar set of issues as something like entgo[0] but in a very TypeScript-native way?<p>Also, regarding the transaction functions, are those run locally, or are they serialized and run remotely on the database server? Both have their caveats.<p>Number 1 (and that approach to retries) already works just fine with Postgres, you just need a proper library (which wraps your function and retries on transaction isolation errors). But you also have to keep in mind that if you interface with 3rd party services during your transactions, those calls will need to be idempotent as well. This is actually the proper way to do transactions in application code with a SQL database, esp. if you&#x27;re running with serializable transaction isolation.<p>Number 2 is very limiting, as you can&#x27;t have all those third party services and libraries used between different operations in a transaction, which is often (I&#x27;d even argue - usually) very useful.<p>Since you&#x27;re citing stored procedures as a viable alternative to convex&#x27;s take, while not listing the above number 1, it sounds like you&#x27;re doing 2.<p>Anyhow, good luck!<p>[0]: <a href="https:&#x2F;&#x2F;entgo.io" rel="nofollow">https:&#x2F;&#x2F;entgo.io</a>
JohnDeHope超过 2 年前
&quot;It can be done. But can doesn&#x27;t mean should.&quot; I&#x27;m getting worn out on this turn of phrase. Yes, can doesn&#x27;t mean should. But also, couldn&#x27;t doesn&#x27;t mean shouldn&#x27;t. You have to justify &quot;shouldn&#x27;t&quot;. TFA does go on to justify it, which is appreciated.
richbell超过 2 年前
&gt; Tab! Tab! Tab! PostgreSQL demonstrates its field autocomplete feature.<p>SELECT preceeding FROM is such a thorn in the side. :(
评论 #34585474 未加载
评论 #34585150 未加载
WkndTriathlete超过 2 年前
Tell us you don&#x27;t understand the theory or use cases for SQL databases without telling us you don&#x27;t understand the theory or use cases for SQL databases.<p>There are indeed times when a simple key-value store is appropriate, but the encoding of hierarchy and the relational calculus are useful for so many more use cases in business applications. SQL as a <i>language</i> is certainly flawed - it would be nice to be able to algebraically&#x2F;programmatically join select clauses and conditions, for instance, or to perform multi-inserts - but the semantics of the storage and engine are based on some pretty mathematically sound foundations.<p>You may find the seminal paper by Codd as illuminating as I did if you read it.
vlunkr超过 2 年前
I agree with lots of the points here. However one of the great strengths of the SQL family is the FOSS history. I doubt something proprietary is ever going win everyone over. At least I hope not.
评论 #34586539 未加载
评论 #34586478 未加载
cgh超过 2 年前
Optimistic concurrency control is mentioned as a feature of Convex, the advertised product. But OCC is a common concern and has been for ages. In Java, the JPA standard specifies the @Version annotation which enables OCC on entity objects and it&#x27;s implemented by the usual suspects like Hibernate. It&#x27;s been around for at least a decade so I&#x27;m struggling to understand why this is being presented as some big innovative win, unless I&#x27;m completely missing something here.
评论 #34586459 未加载
015a超过 2 年前
I mean... yeah MongoDB got a lot of hate, but I think the broader point is that it was one of the first technologies to popularize the domain of NoSQL. No one knew how to use it properly; so we adapted SQL-like schema design, and when it became obvious that didn&#x27;t work well the hate started spilling over to the first technology to arrive at the party.<p>The elephant in the room is, I suppose, that the modern internet literally would not be possible without NoSQL. It <i>may</i> be possible without SQL; that seems likely to me. Part of that is because NoSQL is a big umbrella, and covers <i>extremely</i> critical databases like Redis or even databases like Cloudflare&#x27;s proprietary edge cache. But, even document stores are extremely critical to enterprise scaling; during Prime Day 2022, DynamoDB peaked at 150M rps. There&#x27;s no SQL setup on the planet that could handle volume like that while still maintaining all the things that Make It SQL; you could start throwing read replicas and removing joins and cross-table lookups and sharding data and ope, you just re-invented a document store.<p>Here&#x27;s the couple conclusions I have started operating by:<p>1. Document stores are, today, a strong choice at both low and high scales on the spectrum of systems scaling. Its great at low scales because you can avoid thinking about it too much. Its great at high scales because once you have the space to think about it you can attain substantially higher efficiency (performance+cost).<p>2. Making a document store operate more like SQL, for the things SQL is good at (joins, validation, etc) is a lot easier than making a SQL database operate like a document store for the things document stores are good at (Planetscale? there&#x27;s a couple players in this game).<p>3. SQL-the-language sucks. There I said it; I&#x27;ll die on that hill. The language was invented at a time +&#x2F;- 2 years of Scheme, ML, Prolog, and Smalltalk. Our industry has rejected all of those. We haven&#x27;t rejected SQL (yet). SQL is <i>demonstrably</i>, as a syntax, just as bad as those languages, evidenced by all the ORMs, injection attacks, etc. Databases tend to have a longer shelf life than programming languages, but SQL-the-language will die.<p>4. But, duh, SQL is fine. Go ahead and use it. In some situations it makes sense. In others it doesn&#x27;t. Its a tool; one that has had 60 years to form around solving as many problems as possible.<p>[1] <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;aws&#x2F;amazon-prime-day-2022-aws-for-the-win&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;aws&#x2F;amazon-prime-day-2022-aws-f...</a>
评论 #34586440 未加载
xupybd超过 2 年前
One of the best things I&#x27;ve seen that integrates SQL with your code is F#&#x27;s type providers. <a href="http:&#x2F;&#x2F;fsprojects.github.io&#x2F;SQLProvider&#x2F;" rel="nofollow">http:&#x2F;&#x2F;fsprojects.github.io&#x2F;SQLProvider&#x2F;</a><p>It&#x27;s amazing how it all works. But only when it works. I&#x27;ve found it so flakey I don&#x27;t use it for production but if the bugs were ironed out it would be amazing.
legerdemain超过 2 年前
<p><pre><code> &gt; We paused just long enough to take a sip of our Spicy Maya Mocha from Coupa Cafe. </code></pre> To be honest, I think almost all drinks at Coupa Cafe are pretty bad.
AnEro超过 2 年前
Graph databases solve most of his issues, outside the complexity of queries.<p>If we are begging DB engineers for things can we get a graph layer for accessing SQL tables please?
bambax超过 2 年前
This example is really curious:<p><pre><code> BEGIN; SELECT post_count, ... from users where ... FOR UPDATE; INSERT INTO posts VALUES(...); UPDATE users SET post_count = new_post_count WHERE ...; COMMIT; </code></pre> For one, it&#x27;s unlikely the number of posts per user is so important and so often requested that it needs to be cached in the database itself.<p>Secondly, why would that value need to be stored with each new insert? Simply insert posts as they come, and calculate metadata about posts at a later time as a batch process, or when some part of the application actually request them.