Why Schemaless? MongoDB is a JSON-style data store. The documents stored in the database can have varying sets of fields, with different types for each field.And that’s true. But it doesn’t mean that there is no schema. There are in fact various schemas:
- The one in your head when you designed the data structures
- The one that your database really implemented to store your data structures
- The one you should have implemented to fulfill your requirements
With a schemaless database, 90% of the time adjustments to the database become transparent and automatic. For example, if we wish to add GPA to the student objects, we add the attribute, resave, and all is well — if we look up an existing student and reference GPA, we just get back null. Further, if we roll back our code, the new GPA fields in the existing objects are unlikely to cause problems if our code was well written.Everything above is true as well.
“Schema-less” vs. “Schema-ful”But let’s translate this to SQL (or use any other “schema-ful” database instead):
And we’re done! Gee, we’ve added a column, and we’ve added it to ALL rows. It was transparent. It was automatic. We “just get back null” on existing students. And we can even “roll back our code”:
ALTER TABLE student ADD gpa VARCHAR(10);
Not only are the existing objects unlikely to cause problems, we have actually rolled back our code AND database. Let’s summarise:
ALTER TABLE student DROP gpa;
- We can do exactly the same in “schema-less” databases as we can in “schema-ful” ones
- We guarantee that a migration takes place (and it’s instant, too)
- We guarantee data integrity when we roll back the change
What about more real-world DDL?Of course, at the beginning of projects, when they still resemble the typical cat/dog/pet-shop, book/author/library sample application, we’ll just be adding columns. But what happens if we need to change the student-teacher 1:N relationship into a student-teacher M:N relationship? Suddenly, everything changes, and not only will the relational data model prove far superior to a hierarchical one that just yields tons of data duplication, it’ll also be moderately easy to migrate, and the outcome is guaranteed to be correct and tidy!
CREATE TABLE student_to_teacher AS SELECT id AS student_id, teacher_id FROM student; ALTER TABLE student DROP teacher_id;
Let’s face the truthSchemalessness is about a misleading term as much as NoSQL is: And again, MongoDB’s blog post is telling the truth (and an interesting one, too):
So, there’s absolutely nothing that is really easier with “schemaless” databases than with “schemaful” ones. You just defer the inevitable work of sanitising your schema to some other later time, a time when you might care more than today, or a time when you’re lucky enough to have a new job and someone else does the work for you. You might have believed MongoDB, when they said that “objects are unlikely to cause problems”. But let me tell you the ugly truth:
Anything that can possibly go wrong, does – MurphyWe wish you good luck with your dynamically typed languages and your dynamically typed database schemas – while we’ll stick with type safe SQL.