Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against SQL

scattered-thoughts.net

Post reply on HN
Print view View original

321–330 of 354 posts

Re: Against SQL

#321

Post by hobs »

paulmd wrote: post #152
ako wrote: post #142

Earlier quoted context omitted.

Postgres allows you to run python in the database, Oracle has support for java, Postgres can do limit 100, you can build subqueries using views, and reuse these in larger queries... Problem with query optimization is that it needs to be done at runtime, you can't optimize it in some procedure language easily. The optimal way to retrieve data depends on the number of records in your tables, the where clauses you use,…

> Postgres allows you to run python in the database, Oracle has support for java, Postgres can do limit 100, you can build subqueries using views, and reuse these in larger queries... Compiling down to fast bytecode is important and what I am thinking is more of a "pythonesque"/"javaesque" than an actual thing on a python VM / java VM. Limit the allowable syntax, it doesn't need to be full-spectrum python/java where…

(SQL Server) Query hints(OPTIMIZE FOR), fixed plans, compiled stored procedures - they all do things like this but they all have tradeoffs that you generally would rather just let the engine take care of and write more clearly expressive queries than take on, mostly "hey wait why did my performance suddenly get worse?" type of reasons.

Re: Against SQL

#322

Post by zX41ZdbW »

pjungwir wrote: post #10

It would be really cool if databases had an Option type. Then you could remove all the NULLs. Although you can mark a column as NOT NULL, that restriction doesn't "travel": it isn't present for function inputs/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 woul…

This is how it is done in ClickHouse. It has Nullable(T) type. The functions of non-Nullable types will return non-Nullable types (except some specific functions).

https://clickhouse.tech/docs/en/sql-reference/data-types/nul...

Re: Against SQL

#323

Post by zX41ZdbW »

Izkata wrote: post #108

The GROUP BY section is odd: > You can use as to name scalar values anywhere they appear. Except in a group by. -- can't name this value > select x2 from foo group by x+1 as x2; ERROR: syntax error at or near "as" LINE 1: select x2 from foo group by x+1 as x2; -- sprinkle some more select on it > select x2 from (select x+1 as x2 from foo) group by x2; ?column? ---------- (0 rows) Looking at that first one I'm just ki…

This is also fixed in ClickHouse - you can set and reuse aliases in any expressions in the query.

Re: Against SQL

#324

Post by balfirevic »

blacktriangle wrote: post #262
neuronic wrote: post #231

Earlier quoted context omitted.

Can you? For every article hating SQL there is one for hating NoSQL: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...

NoSQL is much bigger than Mongo, which deservers books written on hating it. The relational algebra is great, but its also overkill for things like event streams, message brokers, caches, does hit scalability issues for certain legitimately large workloads, and in comparison to Mongo and other document-based databases, fails when your data simply is not relational. Then there's the whole object/relational impedance m…

> fails when your data simply is not relational

What's an example of data that's not relational?

Re: Against SQL

#325

Post by lenkite »

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.

Re: Against SQL

#326

Post by CornCobs »

twodave wrote: post #266

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. 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, str…

I think the author makes a valid point about this though - that it is precisely because of the limitations of SQL that we think this way. If SQL was a much more expressive data processing language we may not even require an app layer.

I do agree with this - after all SQL is supposed to be the data layer - why should we think that data processing shouldn't happen there?

Re: Against SQL

#327

Post by adsharma »

paulmd wrote: post #126
danbruc wrote: post #75

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…

I think the criticisms of the article are basically right. SQL sucks in a lot of ways, and the base SQL standard really sucks such that virtually everyone has extended it at least somewhat, but they've all done it in a completely nonstandard way so nothing is portable, and the standard is never officially updated anymore. Oh also it's a massively leaky abstraction and you may have to tune your query to the database a…

https://github.com/adsharma/fquery/ https://adsharma.github.io/fquery/

Uses python expressions and generates SQL.

Also does static typing, so you can run a type checker on the code

Re: Against SQL

#328

Post by justshowpost »

It'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.

In contrast, users of, for example, the lingo where object minus object equals NaN are terrified when suddenly exposed to type zoo like https://www.postgresql.org/docs/9.5/datatype.html (Disclaimer: a relatively randomly chosen example, neither endorsement nor preference of particular RDBMS/dialect). And let'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/DML keeps scripters out of SQL.

So the reason behind that endless «SQL bad» teeth gnashing turns out to be very simple.

Re: Against SQL

#329

Post by bmn__ »

thrusong wrote: post #240
slx26 wrote: post #67

I think the problem of this essay is that it'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 "SQL will get the job done in the end", 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 th…

I completely agree with you. Is SQL perfect? No. Have I accepted and embraced it? Yes, because it'll get the job done. I also happen to really dislike how the author hasn't capitalized the syntax like SELECT FROM WHERE or CREATE TABLE which, to me, poorly affects the legibility and therefore makes me less interested in reading the argument overall.

It's not 1960 any more. We have colour video. We are allowed to highlight syntax with colours instead of the less legible all caps.

Re: Against SQL

#330

Post by goto11 »

mcv wrote: post #320
jandrewrogers wrote: post #297

Earlier quoted context omitted.

Graph databases have been around nearly as long as databases generally, at least since the 1970s. The sole feature that makes a database a "graph database" is support for a minimal amount of recursion in queries, which was a feature before SQL even existed. There are good technical reasons graph databases have never been commercially successful. Most databases support some form of recursion and have for decades. The…

Interesting. But are those old graph databases similar to modern ones like Neo4j? Neo4j has pretty amazing performance compared to doing the same thing in SQL. Although it's certainly possible that SQL database was poorly designed. Even so, a handful of developers new to graph DBs managed to easily beat its performance. I've also heard that some modern graph databases are not true native graph databases below the sur…

Performance was not the selling point of relational databases in the first place. It is hard to beat the performance of a perfectly tuned hierarchical or graph database on the workloads they are designed for. At best a relational database can be equally fast. For this reason hierarchical/graph databases never went away and are still appropriate for specialized tasks.

The selling point of relational database is they can accommodate long-lived multi-purpose databases used by multiple different users and applications over time and where the data model would change and evolve over time as the world changes. The is achieved by "data independence" - the logical model is decoupled from physical storage structure and is not hard-coded to accommodate particular query patterns. So you can have ad-hoc queries - cross-cutting queries which you didn't know you would need when the schema was designed. The key insight is that relationships between entities are also just data.

Post reply on HN