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

Relational databases aren’t dinosaurs, they’re sharks

simplethread.com

Post reply on HN
Print view View original

11–20 of 135 posts

Re: Relational databases aren’t dinosaurs, they’re sharks

#11

Post by thatwasunusual »

jseban wrote: post #10
thatwasunusual wrote: post #8

Great article, and I this particularly brought back memories for me: > [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. I've worked with a big application that utilised this appro…

I think your solution here was to move the typing to the application layer, which kind of makes sense because that's where you know the locale. But why also move the data to NoSQL, I don't see what that would add. If you had already removed the typing from the relation DB I think that would have worked as well, or am I missing something?

The main problem was that we were unable to store the different types of addresses because of their different "layouts" in a "relational way."

Re: Relational databases aren’t dinosaurs, they’re sharks

#12

Post by tuatoru »

laurent92 wrote: post #7

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduc…

What ORMs have taught me: Just Learn SQL

https://wozniak.ca/blog/2014/08/03/1/index.html

Re: Relational databases aren’t dinosaurs, they’re sharks

#13

Post by gunnarmorling »

laurent92 wrote: post #7

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduc…

Hibernate isn't at all meant to avoid understanding or writing SQL; rather, it is meant to map result sets of queries to managed object graphs, track mutations to the loaded graphs, and synchronize those changes efficiently back to the database.

The SQL generated by Hibernate is as good or bad as you tell it to; something like inappropriate config causing the n+1 SELECT you describe will instantly show up in any decent dev workflow. You're not bound to JPQL, you can very well use SQL directly too if that benefits your situation.

As any powerful tool, Hibernate ORM requires good knowledge of it in order to use it efficiently and effectively. Use it if you have the problems which it solves; don't use it, if you don't have those problems.

Disclaimer: former Hibernate core team member

Re: Relational databases aren’t dinosaurs, they’re sharks

#14

Post by chrisandchris »

pier25 wrote: post #2

The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. Talking about "NoSQL tradeoffs" implies all non SQL databases share similar features, operational models, use cases, etc, which is simply not true. For example, DynamoDB, Mongo, and Fauna have absolutely nothing in common.

> The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. […]

Except that it does not. It does mean „Not Only SQL“, and not „no SQL“.

Re: Relational databases aren’t dinosaurs, they’re sharks

#15

Post by d4tocchini »

Relational databases may be ACID, but no, they do not "give us" ACID.

Take LMDB as an example. LMDB is a fast low-level KV storage engine. NoSQL here, but with full ACID semantics & usable as a backend for whichever DB flavor you so wish to implement. LumoSQL and the older sqlightning are sqlite implementations backed by LMDB.

Re: Relational databases aren’t dinosaurs, they’re sharks

#17

Post by cageface »

laurent92 wrote: post #7

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduc…

Building SQL queries by gluing strings together is tedious and error prone. So you write a lot of helper functions to build queries for you and pretty soon you've invented your own crappy ORM.

Why not save a lot of time and bugs and use a battle tested ORM and drill down to SQL for the queries that really matter instead?

Re: Relational databases aren’t dinosaurs, they’re sharks

#18

Post by erk__ »

chrisandchris wrote: post #14
pier25 wrote: post #2

The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. Talking about "NoSQL tradeoffs" implies all non SQL databases share similar features, operational models, use cases, etc, which is simply not true. For example, DynamoDB, Mongo, and Fauna have absolutely nothing in common.

> The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. […] Except that it does not. It does mean „Not Only SQL“, and not „no SQL“.

I think that is a more recent backronym and was not the original, so it is wrong to say that what the above post said is incorrect.

Re: Relational databases aren’t dinosaurs, they’re sharks

#19

Post by sigg3 »

chrisandchris wrote: post #14
pier25 wrote: post #2

The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. Talking about "NoSQL tradeoffs" implies all non SQL databases share similar features, operational models, use cases, etc, which is simply not true. For example, DynamoDB, Mongo, and Fauna have absolutely nothing in common.

> The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. […] Except that it does not. It does mean „Not Only SQL“, and not „no SQL“.

I think you're wrong. I distinctly recall NoSQL being hailed as a move away from SQL, as in you'd never need SQL again.

This turned out to be misleading, so the Not Only SQL was suggested as an alternative name.

See e.g. https://hostingdata.co.uk/nosql-database/

Re: Relational databases aren’t dinosaurs, they’re sharks

#20

Post by cpursley »

thatwasunusual wrote: post #8

Great article, and I this particularly brought back memories for me: > [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. I've worked with a big application that utilised this appro…

This is exactly what I do - store location components as jsonb in Postgres
Post reply on HN