Topic: Schema Design Anti-Patterns | Guide to design schema with a list of six don’ts
Hey what’s up everybody, I present to you a six-part series on schema design anti-pattern for document-oriented databases. This article is an introduction to the series; feel free to skip to the bottom of this article if you’re already aware of what document-oriented databases are; what are anti-patterns and how does it affect you as a developer.
What the heck are document-oriented databases?
Well all you NoSQL databases fan, document-oriented databases is one of the NoSQL databases. MongoDB, Couchbase, Apache CouchDB, etc are some examples of document-oriented databases. A wide spectrum of developers must have used MongoDB some day or other; as it offers a free tier managed database on MongoDB atlas.
A schema without a plan is not a schema, it’s a bug 🙂
This is a lot similar to constructing a building without blueprints. You don’t realize what you’re building until it gets big enough.
A lot of developers including me intend to directly jump into designing our schema and writing code, especially as beginners. Little do we know of the effect, when this same database has started scaling. Things start to turn out pretty bad, as we did not brainstorm while designing the schemas.
Also read, AWS Athena Start Query Execution In Java Spring Boot
What can you expect from this series?
This series will shed some light on the common mistakes that we developers do while designing schemas for document-oriented databases. Team MongoDB calls these mistakes “schema design anti-patterns“.
A new beginning of Schema Design Anti-Patterns
Without further ado, let’s get started with this series. Refer to the below links to navigate through each part of this series. Make sure that you take it easy while studying/implementing this topic.
I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.Bruce Lee
Something exciting is coming up soon! Stay tuned for Part 1.