Hacker News Reader

Comment by cmenge | Hacker News Reader

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements.

But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works.

For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginners believe that SQL databases guarantee serializability everywhere and all the time, relying on the database (and OR-mappers) a lot / too much in my opinion.

Choosing a system that only offers very few guarantees forces you to think about them more explicitly. On the other hand, if you never bothered to understand SQL, you probably won't bother understanding anyDB's restrictions and guarantees either, and then everything goes to sh*t.

Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV.

View on HN

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.

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.

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).".

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.

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.

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

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.

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.

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.

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

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.

> Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV.

I agree with most of this, relational databases have a lot of moving parts that many developers (myself included) don't fully understand.

However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive.

+1 - Mongo is much easier to misuse. Not to mention that many users of SQL these days use ORM's that abstract many of the complex SQL features with a professional library that actually knows how to handle the small details and only exposes a basic subset of functionality that is good enough for most use cases.

> I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this.

Strongly, strongly agreed. Learning every moving part in InnoDB (as an example) is quite a task. But not knowing about those features will rarely burn you, and it's usually apparent when you need to know something you don't.

Meanwhile Mongo... well, Mongo says a replicated write is complete as soon as it's queued to be written. They eventually updated the default settings to be slightly less catastrophic, but still far from good. What you don't know about Mongo can and will hurt you, which arguably makes the appearance of ease a drawback.

http://hackingdistributed.com/2013/01/29/mongo-ft/

Man, people just looooove to link 5 year old blogs about fault tolerance, meanwhile that isn't even relevant anymore, and honestly, it wasn't relevant at the time either, because changing the write concern is trivial.

The real nugget of truth here is this; don't use tools that you don't understand... PERIOD.

Further, there are a plethora of alternative engines for Mongo that do have fault tolerance in mind.

> However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive.

Postgres has good and sane defaults. Also the documentation INSIDE the config file is top notch. The one thing which makes postgres the golden standard in my opinion is its extensive documentation. Documentation is key to maintaining an RDBMS

Mysql does some weird things on an initial install, and documentation is sadly all over the place.

"some text-based SQL statements"

What do you have in mind there? Systems that process SQL statements interpret these statements, validate them for correctness against a schema and then provide an auditable plan. Just because SQL bears some resemblance to spoken/written English (a property that vanishes pretty quick when you get past simple use cases) doesn't mean it isn't rigorously analyzed by database systems; SELECT isn't some alternative form of 'grep.'

Perhaps you're thinking of SQL injection attacks that plague that the LAMP stack? If so then you should know that NoSQL isn't immune to injection attacks. Here[1] is an OWASP page on testing for NoSQL injection vulnerabilities; the same sloppy coding patterns that allow attackers to synthesize SQL statements are also manifest in NoSQL applications.

[1] https://www.owasp.org/index.php/Testing_for_NoSQL_injection

Being condescending isn't helping your argument here. No, I didn't think of SQL injection and I do have a vague understanding of the SQL grammar. The NoSQL injections seem a bit constructed and pretty much can't happen with a strongly typed language in the application layer.

> Choosing a system that only offers very few guarantees forces you to think about them more explicitly.

Yes, of course. And it also forces you to implement, on your own: relational (key) constraints, real transactions, etc.

And thus, you, on your own, compete against more or less 44 years of research, developing, and releases by brilliant computer scientists and engineers (Ingres DB, 1973- PostgreSQL latest version, 2017), scientists who already solved those problems {relational constraints, transactions, etc} and made said solutions perform to the max possible.

So a better alternative is to simply... learn more about relational databases.

I'm sorry, you're so right. I'm just one of the idiots on the Internet who haven't used a system for 10+ years (or the bulk of their existence at least) and makes condescending comments...

Reply on news.ycombinator.com