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

121–130 of 135 posts

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

#121

Post by thatwasunusual »

mamcx wrote: post #114
jmull wrote: post #113

Earlier quoted context omitted.

Honestly, I think you’ve misunderstood the previous post.

No. I was directly pointed to the quote. Because is a common narrative "if you have problems in a RDBMs, get out of a RDBMS and use nosql". The previous post kinda say the same, but is weird because call the quote great?

> No.

Yes.

You replied to my reply, where I used addresses as an example. I totally agree with you in general, i.e. use RDBMS as much as possible, but when it's no longer possible - what would you do in the case of addresses?

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

#122

Post by CRConrad »

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

What are the last 0.9%? ;-P

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

#123

Post by CRConrad »

jhgb wrote: post #104
avianlyric wrote: post #103

Earlier quoted context omitted.

> You can't decide where to deliver an item in any other way. Only if you’re a robot, which postal workers aren't. They can use local context, such as no one lives at address X so they must have meant address Y. Or even, person at address X has a birthday this week, so this envelop that looks like a birthday card, and has their misspelled name on it, is obviously for address X not address Y. I’ve had our friendly pos…

> Or even, person at address X has a birthday this week, so this envelop that looks like a birthday card, and has their misspelled name on it, is obviously for address X not address Y. That seems awfully contextual and ad-hoc. Surely this mechanism won't work in many instances unless you only receive mail on your birthday. It's a nice thing if it sometimes succeeds even when it shouldn't, but that's not something you…

> That seems awfully contextual and ad-hoc. Surely this mechanism won't work in many instances unless you only receive mail on your birthday.

No, you're only more likely to receive stuff that looks like birthday cards on or around your birthday.

But, forget the birthday -- your earlier statement:

>>> To me there seems to be a contradiction in those two statements. By definition, an address is written

...is already contradicted if the postal worker just recognizes your name, and knows that you live at your actual address and not the one the written one more resembles. Your name isn't written in the address itself.

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

#124

Post by CRConrad »

willvarfar wrote: post #36
ransom1538 wrote: post #22

Earlier quoted context omitted.

IMHO Blobs usually turn into a mess though. Some VP will ask "what weekday do users comment the most". With blobs this is drama. You end up parsing all these blobs and creating relational tables anyway. Sure you could do metrics separately -- but good luck predicting what stats you will want in the future. Need an admin portal? With blobs you are coding all these custom admin pages. With mysql, I love when new people…

I often put json blobs into MySQL tables. Modern MySQL has support for accessing the fields in the json from normal sql. You can also create computed columns that deref the json, and even index it. Other rdbms often have even better json support.

Those don't sound like "blobs" to me -- that stands for "Binary Large OBject"; JSON is text, not binary, isn't it?

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

#125

Post by CRConrad »

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

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

That's a (silly, IMO) retronym. "No SQL" means literally no SQL in English, and that's all the original "NoSQL" DB evangelism meant, too. Later, as they found their paradigm more or less sucks, the proponents retrofitted -- more or less hastily, frantically, or desperately -- SQL to it.

The original dBase and Paradox formats were also databases, and didn't have SQL: They were the canonical "NoSQL" databases. Are you claiming they're now somehow "Not Only SQL"?

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

#126

Post by jbverschoor »

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.

Naming in tech is shit anyway. It's loaded with marketing mumbo jumbo.

NoSQL should mean: No-SQL, No SQL query language, and therefore no required implementations of the SQL standard (tables, relations, transactions etc).

A lot of "NoSQL" databases actually include an SQL layer.

Heck. CSV is NoSQL too.

The transaction model is one of the things which would be nice to be able to select (eventual-consistent, non-consistent, consistent). In case you have different performance requirements. Similar to UDP vs TCP. But again, it has nothing to do with no-sql.

There was a term - object database. But it was old, so it couldn't be used. Then it was document store / database.

Caching and naming things are the most difficult parts. But instead of selecting a name that makes sense and reflects a system/architecture/we, we let some marketing people (read - advocates) promote a new, seo-clean, name.

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

#127

Post by jbverschoor »

pbourke wrote: post #6
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.

At this point we all generally understand that NoSQL means a system that lacks one or more of: the SQL language, a relational model or ACID guarantees. It’s a useful shorthand for all of that.

What's the benefit then? Just use a CSV file. It's usually faster than any of the "NoSQL" systems out there, and used to be on par in terms of consistency and data-safety with mongodb. Actually better if you only append data.

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

#128

Post by jbverschoor »

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

Let's just rewrite history and state some events were different than what they actually are.

You're tech-gaslighting

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

#129

Post by dang »

mastrsushi wrote: post #29
jeremyjh wrote: post #25

Earlier quoted context omitted.

You might have missed the fact that sharks are awesome.

Oh My God

We've banned this account for repeatedly posting unsubstantive comments and ignoring our request to stop.

If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.

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

#130

Post by mamcx »

thatwasunusual wrote: post #121
mamcx wrote: post #114

Earlier quoted context omitted.

No. I was directly pointed to the quote. Because is a common narrative "if you have problems in a RDBMs, get out of a RDBMS and use nosql". The previous post kinda say the same, but is weird because call the quote great?

> No. Yes. You replied to my reply, where I used addresses as an example. I totally agree with you in general, i.e. use RDBMS as much as possible, but when it's no longer possible - what would you do in the case of addresses?

The big problem with addresses and all that is the same whatever you use JSON or not (in the DB or in the app logic). I concede that using JSON in the DB and move the logic to the App is ok and in part because SQL is an incomplete language.

But that is orthogonal to move out completely to a nosql. That is going too far (in this case).

Post reply on HN