Hacker News Reader

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.

Most of your points are ripe with folly.

1. ORMs are slow, but generally they are worth it, and it's trivial to dive into raw queries when needed for performance reasons.

2. Mongo supports relationships, not sure what you're trying to get at. Reverse delete rules are TRIVIAL to implement in your models. This is NOT the fault of the database engine, but fault of the developer, 100%.

3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist! If you are having to look "all over the code" to figure out the models, then the problem is you don't have any models.

This problem isn't even limited to Mongo either, this can happen on a SQL-backed project too if the developer is an amateur. Not having a model layer is the fault of the developer (or architect), not to be blamed on the DB engine of choice.

You should try to not start a comment with an attack. It just makes you look bad. See: http://www.paulgraham.com/disagree.html

Regarding your points:

> 1. ORMs are slow

Maybe you haven't used any recent ORM. Where did you get this idea from? In the JVM world, Hibernate is nearly dead for new projects. EBean[1] and JOOQ[2] are both great choice server-side Java/Kotlin/Scala projects. On Android / for SQLite, there's DBFlow[3], which I've used, and had great experiences. These ORMs are fast, intuitive, and powerful.

Also relevant is: https://dzone.com/articles/martin-fowler-orm-hate

> 2. Mongo supports relationships

Mongo's approach to relations[4] is far weaker and less powerful than what an RDBMS can handle. It was almost tacked on later as an afterthought. In addition, joins aren't a easy and straightforward with the kind of relations that NoSQL databases, like MongoDB support.

> 3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist!

NoSQL databases actively encourage de-normalization. For example, just take a look at this Firebase blog post[A] or see this page in their documentation[B]. It's almost sad and a shame that a company like Google is encouraging such poor ideas and practices; practices that they likely don't follow themselves (but I could be wrong).

I know some young devs, who just graduating out of college, swoon all over databases like Firebase's. They read articles like these that say "schema-free" is cool, and denormalization is "normal". Ugh... I almost want to throw up.

Model layers are optional. I recently worked at, and quickly quit, a (Fortune 500) company that used MongoDB, had an incredibly complex data model, and had no model layer or schema enforcement of any kind. Their codebase was thoroughly bug-ridden, and their heavily denormalized data had out-of-sync and stale copies all over the place. It was disgusting.

[1] http://ebean-orm.github.io/

[2] https://www.jooq.org/

[3] https://agrosner.gitbooks.io/dbflow/content/

[4] https://stackoverflow.com/a/6994654

[A] https://firebase.googleblog.com/2013/04/denormalizing-your-d...

[B] https://firebase.google.com/docs/database/web/structure-data

None of your points are derogatory to MongoDB in particular, any more-so than any other database.

Your points are wholly reflective of bad implementors and their implementations, not to the underlying technologies.

If one misuses a tool, that's on them, not on the tool. Further, I think it's pretty fair to say: if it's as easy to mis-use something as it is to use it, then you have a very powerful tool that should be used carefully. If it's hard to mis-use something, then it's probably not a powerful tool.

Basically, to use an analogy, don't use a jack-hammer to re-grout delicate tiles. A chisel and hammer work better, and you definitely wouldn't want to use a hammer and chisel to break up a concrete slab. Similarly, you wouldn't use a handheld rotary tool to cut a concrete slab, but using it to remove grout is perfect. Misuse of a tool leading to damage doesn't mean the tool is flawed, bad, or broken, it means it is being used incorrectly. Can you use it that way? Sure! Should you? Probably not.

ORMS are indeed slower than straight SQL, period, always, 100% of the time. This is not opinion, but hard fact of simple logic. Generally speaking, it is rather silly to expect a complex abstraction to be faster, leaner, and more efficient than a lower level one. Adding more code and complexity will never make things execute faster. (Caching does not count, obviously, that's not the point here)

That F500's total lack of effective systems architecture is the problem, not the database they used.

This is like building a treehouse with nails driven at 90 degree angle, and then blaming the hammer when it falls apart. Totally, man, you definitely shouldn't have used screws, or driven your nails at an angle converse to the lines of force. Keep blaming your tools...

Well

1.) It's always a text-based interface. The ORM merely hides the fact. Type safety is weak, as is with JSON, but both aren't un-typed.

2) Yes, they are, and there are a lot of good use cases for relational databases. But if you have a number of services that share nothing (especially not the database), what is the foreign key good for?

3) You can do any style with any database. Overly aggressive normalization in read-heavy environments can be bad, as is de-normalization in write-heavy environments. Choose the tool for the job..

4) Why all over the code? Can't you make it easy to find the model classes? Doesn't seem so hard. Also, is this so different from, say, EF code first? And anyway, doesn't every SQL database in fact, have multiple schemas (the one in the db, the one in the scripts, the one in the ORM and the one in the code?) Is that really so different?

* Type safety is weak, as is with JSON, but both aren't un-typed."

How is type safety "weak" with an ORM? You are using strongly typed objects.

Yes, but they don't match the data types your SQL database supports, do they? You're talking to a remote service here., i.e. varchar, decimal, datetime, etc. in SQL aren't the same as in whatever language you're using.

That's true for JSON as well, but you probably need JSON on the other side (the API) as well...

Yes. When you use Entity Franework's generator to map from a database table to a class, it not only maps the types from the database to your class, it also maps constraints like charactr length, nullable fields vs. non nullable fields, etc.

The same for Mongo if you are using the C# driver. If you get a Mongo collection using the standard C# syntax --

var collection = database.GetCollection<Users>("Users");

You will work with a strongly typed "schema". As long as you are working with the "collection" object, you will be working with strongly typed objects and doing type safe Linq queries.

> There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate.

I am a happy user and can recommend the following ORMs:

for Java, Hibernate (a classic)

for C# in .NET, how about... NHibernate?

for Python... SQLAlchemy.

Really good software. WARNING: they require you to read the manual.

Couple of points: 1. ORMs I'm not sure why you dismiss ORMs. Have you ever used a good ORM? There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. There is no reason to write text-based SQL anymore.

I use ORMs to do just what the name implies -- to map relational models to objects. If I'm working with objects anyway, either I'm going to end up using an ORM or creating my own object mappings.

2. Relations: Foreign keys are incredibly useful. They're the biggest feature I miss out in relational databases. They help keep your data in a sane state. If a user deletes his account, you can configure your database use a DELETE CASCADE to automatically remove all data associated with the user.

Or I can just as easily use my User management micro-service to enforce business rules.....

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. With NoSQL database, you have to handle all the complications of denormalization. (You, the developer, have to remember to update/delete/etc from the multiple places the same piece of data lives in.) The database doesn't do it for you. (The database is a dumb key-value store, nothing more.) Relational databases encourage keeping the logical design of your databse normalized. To quote Wikipedia: "The preferred method is to keep the logical design normalised, but allow the database management system (DBMS) to store additional redundant information on disk to optimise query response. In this case it is the DBMS software's responsibility to ensure that any redundant copies are kept consistent. This method is often implemented in SQL as indexed views (Microsoft SQL Server) or materialised views (Oracle).".

Why would you have your business logic strewn all over your code base instead of using a common library/microservice that all of your code depends on? I wouldn't design a system even with Sql where all the code modifies the database willy-nilly.

4. Schemas: The worst thing about NoSQL is the absence of an enforced schema. Schemaless databases are a scourge. There's always a schema -- it's just that it's scattered all over the code. If you are joining a new company, you have to sift through piles of code to figure what the structure of the data is. Schemas are like types, and my dislike for dynamically typed languages carries over to schema-less database. Relational databases make you think carefully about the schema, and specify the schema explicitly.

Why is your schema "scattered all across your code? I use Mongo with C#. When I'm reading from writing to a collection, I'm not reading/writing BsonDocuments.

A typical code snippet from C# using RoboMongo is:

var collection = database.GetCollection<User>("Users").AsQueryable();

All of my Linq queries, inserts, updates, etc. are strongly typed objects with autocomplete and type safety.

The "User" object is defined in one central place.

In the end, you end up needing to do a lot of extra work, likely end up with more unstable and buggy system, just to avoid the small amount of totally-worth-it upfront work that setting up a relational database requires.

"It's a poor carpenter that blames his tools"

> "It's a poor carpenter that blames his tools"

I think the point of the article is that Mongo is being used mostly by "poor carpenters", and provides worse defaults than SQL does. It's obvious you're operating at an advanced level that young and hungry startups aren't.

...which brings us back to the original point: if you use tools you don't understand, chances are things go wrong.

Key-value stores provide very little. The whole deal with SQL/relational databases, is that they provide much much more. The SQL database like CockroachDB are built on top of RocksDB, a key-value database: https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mappin...

It's the difference between assembly language and a high-level language. Key-value stores are simple, basic, and primitive. What's wrong with that? It's like a farmer saying, I don't want to learn how to use a tractor (it's too complicated), and who chooses to farm with a hand tools instead.

> if you use tools you don't understand

Yea.... key-value stores are incredibly complex and require years of learning to understand.

I could explain a key-value store to a five-year old. In fact, I think even a pigeon can understand the fundamental principle underlying a key-value store. https://en.wikipedia.org/wiki/Pigeon_intelligence

For any non-trivial data model, go with something that can capture your model at a high level, like a relational database or a graph database.