Comment by zer00eyz | Hacker News Reader

Comment by zer00eyz | Hacker News Reader

Parent Full thread

As someone who thinks both systems have their place, there are a few issues in your arguments:

1. ...There is no reason to write text-based SQL anymore.

There sure is! Unless your schema is dead simple your going to run into places where hand tuning is a requirement. Lots of ORM's are third rate at best, people swear by them but don't have complex data that would make one throw fits.

3. Normalization: NoSQL databases encourage you to denormalize your data. I've seen NoSQL databses frequently run into problems with stale data, with date that is duplicated and not kept updated, where you have multiple out-of-sync version of the same piece of information.

Nosql doesn't encourage you to de-normalize, and there are reasons to de-normalize in an RDBMS. Denormalization when done right should NOT result in duplication, if it does your doing it wrong. Both systems are afflicted by these poor choices. It is easier to screw it up in a document store like mongo.

4. Schemas: The worst thing about NoSQL is the absence of an enforced schema... If you are joining a new company, you have to sift through piles of code to figure what the structure of the data is...

Again were not talking about a problem that is exclusive to document stores. You can just as easily have queries all over the codebase that make changing your RDBMS hard. People also do very stupid things like throwing giant json blobs (and before that xml) into their RDBMS and expect it to work. However a schema makes dealing with data apart from your application a much simpler task, unless you throw all those rules out the window, and a shocking number of people do.

> Denormalization when done right should NOT result in duplication

Isn't that what it is by definition? Can you give an example of how would you denormalize without causing some sort of data duplication?

There are two main reasons to denormalize: security, and performance.

The former (security) is something I have only ever had to deal with twice. If your going to cordon off data based on some arbitrary ruleset (3rd party) it is a path you can take. For transactional integrity, and from an operations perspective both cases were perfectly valid.

The latter is one I have also only seen rarely.

I have seen it done to keep a history of actions without cluttering up the primary table. As an example I worked on a DB with millions of entries for users, and a separate table for emails, when the user updated their email, it would add a new row, verify it and then fetch the newest complete row when the user was queried. Getting rid of all the history in that table provided a fairly significant performance bump.

The second was to split little used columns in a single table out from the frequently accessed ones. The resulting trimmed table then fit in memory and was orders of magnitude faster than going to disk.

Is there ever a case to denormalize and duplicate? There are a few:

OLAP systems are unique beasts, and duplicate and denormalize in many a strange way, and all in the name of performance and ease of use for end users. The reality is that these systems usually have a SINGLE point of entry for adding and updating records (that aren't materialize views of end users). OLAP systems are weird, because nothing makes sense in them, but most of them (with all their duplicate data) aren't primary stores. Oddly I have replaced a handful of OLAP RDMBS with document stores...

The other major reason to duplicate is for "snapshotting". If you need to know the state of one record when another record was created then your probably going to end up with duplicate information. IN every case where I have seen this the words "compliance" and "audit trail" are part of the conversation. However rather than being problematic the decoupled nature of the duplicate record is desirable.

Reply on news.ycombinator.com