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

91–100 of 135 posts

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

#91

Post by pier25 »

codefreakxff wrote: post #3
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.

Your comment made me read the article and I find the article’s language sufficiently abstract by say things like “many NoSQL databases”, etc Perhaps your comment was meant to say that in general talking about tradeoffs can fall into that trap, but the article here looks like a good discussion

> I find the article’s language sufficiently abstract by say things like “many NoSQL databases”, etc

I'd say it's more vague than abstract.

For example, what dbs is the author referring to when saying things like "NoSQL databases generally make tradeoffs around these guarantees." when referring to ACID?

This seems to be an outdated view. These days, all major NoSQL databases offer transactions with ACID guarantees.

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

#92

Post by pier25 »

rendall wrote: post #84
chrisandchris wrote: post #14

Earlier quoted context omitted.

> 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“.

@chrisandchris is correct. NoSQL means "Not Only SQL" Furthermore, the article is uninformed and writes as if "NoSQL" is an alternative paradigm to SQL. In fact, NoSQL covers a whole range of paradigms and approaches, from key-value, to document, to graph, to more exotic flavors. Some of which can even be queried with SQL ACID can be a feature of other database paradigms as well, if necessary. With MongoDB Atlas, for…

> NoSQL covers a whole range of paradigms and approaches

Exactly, and that's my whole point.

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

#93

Post by thatwasunusual »

gadrev wrote: post #43
hnfong wrote: post #39

Earlier quoted context omitted.

I don't quite understand "was before RDBMS solutions supported JSON "... did (for example) MySQL not support storing JSONs as binary blobs or text before?

You could always store JSON as text, but you'd miss out on the ability to query over JSON efficiently, among some other things, see [1]. Maybe that's what made it useful/viable to GP. [1] https://dev.mysql.com/doc/refman/5.7/en/json.html

Correct.

If only storing/retrieving was the goal, a text field would have been more than enough.

But we also needed to retrieve data based on their address, and to generate reports on a daily basis, which made for being able to do "JSON queries" so much easier.

So we put that logic in the application layer instead, something like:

    User
      - lookupByAddress(data)

    GermanUser inherits from User
      - overrides lookupByAddress(data)
...etc., so that we could be very specific about our queries depending on the country, or even _region_ in some countries.

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

#94

Post by lmilcin »

MikeDelta wrote: post #74
lmilcin wrote: post #41

The choice of technology by developers and their managers is guided in large part by trends rather than by wholly rational decision process. The type of database should be dictated by the application requirements. Relational databases provide some exceptional guarantees while also being able to run quite large systems. This means, when you have: 1. Relational data, 2. Queries that are not known beforehand, 3. Data th…

True, I've also seen enterprises where central architects decide for what framework/solution the whole company should go. The answer to questions like 'what is the best DB' is online always 'depends on your use case', but in enterprises is usually 'what upstairs decided'.

And the reason for this is there is usually "a guy" that mistakes his current love for X with X being better than every other competing product.

Sometimes what happens is that somebody buys X, X is expensive, and so now everybody must use X for everything (even if it is not strictly needed). Usually because it looks silly when X is being paid for on an ongoing basis but not being used for anything important.

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

#95

Post by avianlyric »

jhgb wrote: post #73
avianlyric wrote: post #70

Earlier quoted context omitted.

> I understand these issues. I seriously doubt you do. The closest you can get to “standard address format” is: Address Line 1 Address Line 2 Address Line n Postal code (which can be blank) Postal Area (which can be blank) Country There is no way to build “first-class” support for addresses. Because theres no such thing as a valid or invalid address, only whether or not someone can find the correct location by readin…

I don't see how this changes anything. You can accommodate any address format, or any finite union of multiple address formats, including any computed or materialized views of the address with a custom type (AND including an "I give up" default for when everything else fails). > there’s no standard, it’s entirely dictated by local conventions, which can change street-to-street, city-to-city Well, that may be an inter…

> In my country's case, it's quite clearly defined by law.

I theory the same is true in my country. But clearly someone forgot to inform the populous that not using the official standard is criminal, because I’ve seen plenty of “valid” addresses that don’t follow the standard. These addresses are clearly encoding local conventions, which makes decoding using the official standard not only impossible, but nonsensical, because manipulations that assume the standard will produce unusable addresses.

Best part is, i know this because i was responsible for the system that was then to munge these addresses into the “official” format for tax reasons. That code is 99% edge cases, 0.09% “well shit, just shove it all in the last line and hope for the best” and 0.01% “official” standard.

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

#96

Post by TheCoelacanth »

jhgb wrote: post #73
avianlyric wrote: post #70

Earlier quoted context omitted.

> I understand these issues. I seriously doubt you do. The closest you can get to “standard address format” is: Address Line 1 Address Line 2 Address Line n Postal code (which can be blank) Postal Area (which can be blank) Country There is no way to build “first-class” support for addresses. Because theres no such thing as a valid or invalid address, only whether or not someone can find the correct location by readin…

I don't see how this changes anything. You can accommodate any address format, or any finite union of multiple address formats, including any computed or materialized views of the address with a custom type (AND including an "I give up" default for when everything else fails). > there’s no standard, it’s entirely dictated by local conventions, which can change street-to-street, city-to-city Well, that may be an inter…

That might work if you have infinite resources and can create special handling for individual cities in the world or maybe even individual neighborhoods.

Mailing works in a very decentralized way and has a lot of local variations when you go outside of places that have put a lot of effort into standardizing addresses. Most post offices won't be looking at your whole address. They just care about understanding enough to forward it to a post office one step closer to the final destination. Understanding the final local address might not even use written data. It might just be tacit knowledge that's shared between a few local postal workers.

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

#97

Post by jhgb »

TheCoelacanth wrote: post #96
jhgb wrote: post #73

Earlier quoted context omitted.

I don't see how this changes anything. You can accommodate any address format, or any finite union of multiple address formats, including any computed or materialized views of the address with a custom type (AND including an "I give up" default for when everything else fails). > there’s no standard, it’s entirely dictated by local conventions, which can change street-to-street, city-to-city Well, that may be an inter…

That might work if you have infinite resources and can create special handling for individual cities in the world or maybe even individual neighborhoods. Mailing works in a very decentralized way and has a lot of local variations when you go outside of places that have put a lot of effort into standardizing addresses. Most post offices won't be looking at your whole address. They just care about understanding enough…

IMO that just makes it a very interesting problem to work on.

> Understanding the final local address might not even use written data. It might just be tacit knowledge that's shared between a few local postal workers.

To me there seems to be a contradiction in those two statements. By definition, an address is written. You can't decide where to deliver an item in any other way. If one and the same written text of the address could imply two or more "final local addresses", and somehow the delivery worker decided where is the item actually supposed to arrive, how would the sender indicate the alternatives if not by including it in the text of the address? Or did you mean something different by this?

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

#98

Post by psd1 »

jhgb wrote: post #80
hug wrote: post #75

Earlier quoted context omitted.

This sounds to me like a "just draw the rest of the owl" solution. You're right in that there's nothing you can do with JSONB that you can't do with a custom type, but the larger problem is "do I even know how to make a custom type that might fit all of the various inconsistencies that I might face with this data?" The answer, for me, is no. I have no idea, and I'm not going to pretend. I can throw it all into a gian…

In my case, I actually do know that; there's even a legal definition of what an address is and there's a national registry of all addresses. The problem is that I can't solve this for every country myself since I only have national knowledge (which is sufficient for my needs, fortunately).

Sounds like, for your purposes, you can define an address type that you can map to columns. But I think you're the outlier.

We have fairly regular addresses in the UK. You can enforce a country and a postcode. You can enforce at least two lines of the local address. That's where it ends.

I live right now I'm a house that's described as one village everywhere except by the local council, who address us by the other village. We're in a lane between the two. But the lane is impassable in the middle except with an off-road vehicle. Google maps doesn't know that. Visitors get lost even with GPS and precise co-ordinates!

Before moving out here, I've frequently had to just enter "London" twice due to aggressive validation. I've even entered "London, London, Greater London". It works, but I know there's a senior engineer somewhere who's obstinate and wrong. Hell, I lived somewhere where flats B, C and D for our house number were a different door to A, because properties can be converted.

What is the value of structuring this data? Store a country, a postal code, and a multiline local field, and don't try to validate that field except maybe to clean up surplus whitespace.

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

#99

Post by jhgb »

avianlyric wrote: post #95
jhgb wrote: post #73

Earlier quoted context omitted.

I don't see how this changes anything. You can accommodate any address format, or any finite union of multiple address formats, including any computed or materialized views of the address with a custom type (AND including an "I give up" default for when everything else fails). > there’s no standard, it’s entirely dictated by local conventions, which can change street-to-street, city-to-city Well, that may be an inter…

> In my country's case, it's quite clearly defined by law. I theory the same is true in my country. But clearly someone forgot to inform the populous that not using the official standard is criminal, because I’ve seen plenty of “valid” addresses that don’t follow the standard. These addresses are clearly encoding local conventions, which makes decoding using the official standard not only impossible, but nonsensical,…

The type should always include provisions for manual fixes. IMO such an address type should even include a provision for manual geocoding for cases where automated geocoding fails ("This is how I write it, and this is where it's located").

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

#100

Post by lukaseder »

cageface wrote: post #17
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?

In Java, you don't build SQL queries by gluing strings together. You use https://www.jooq.org, of course.
Post reply on HN