DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • NoSQL for Relational Minds
  • SQL Interview Preparation Series: Mastering Questions and Answers Quickly
  • Exploring the New Eclipse JNoSQL Version 1.1.0: A Dive Into Oracle NoSQL
  • Navigating NoSQL: A Pragmatic Approach for Java Developers

Trending

  • Artificial Intelligence, Real Consequences: Balancing Good vs Evil AI [Infographic]
  • Issue and Present Verifiable Credentials With Spring Boot and Android
  • Automatic Code Transformation With OpenRewrite
  • AI, ML, and Data Science: Shaping the Future of Automation
  1. DZone
  2. Data Engineering
  3. Databases
  4. Your NoSQL Database Has an Implicit Schema

Your NoSQL Database Has an Implicit Schema

There's an assumption in our industry that NoSQL or document database systems doesn't have schema, and hence are more easy to use. This assumption is simply wrong!

By 
Thomas Hansen user avatar
Thomas Hansen
DZone Core CORE ·
Oct. 14, 20 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
6.2K Views

Join the DZone community and get the full member experience.

Join For Free

I've heard several software developers say "Nahh, I'll just use a document database, because it allows me to completely ignore schema, and I don't have to design my database up front". This assumption is positively wrong. Let me illustrate with a use case. Imagine you start out your project, and your database model looks like the following.

C#
 




x


 
1
class Customer
2
{
3
  string Name;
4
  string Email;
5
  string PhoneNumber;
6
}


You start using the above class to persist your objects into your CosmosDB, CouchBase, or MongoDB. 6 months down the road, you've got 1 million customer records in your database, and you want to change your application, because you realise that a customer might have more than one phone. The customer might have a home phone, cell phone, and work phone. Ignoring the type of phone number, and just focusing on a sub part of the problem, we could imagine the developer happily updates his db model, because he does't "need to fiddle with the database schema". The new version becomes as follows.

C#
 




xxxxxxxxxx
1


 
1
class Customer
2
{
3
  string Name;
4
  string Email;
5
  List<string> PhoneNumbers;
6
}


Congratulations! You now have one million "garbage records" in your database. Records you can no longer read, simply because your Data Access Layer (DAL) returns an instance of Customer as you query for customers, and your existing customers that are persisted as follows into your database ...

JSON
 




xxxxxxxxxx
1


 
1
{
2
  "Name": "John Doe",
3
  "Email": "john@doe.com",
4
  "PhoneNumber": "555 555 5555"
5
}


... can no longer be read using your "new and shiny improved database model". Why? Because "PhoneNumber" no longer exists, and has been replaced with an array called "PhoneNumbers" (plural). At best, this will return in you having a million customers with a "null" phone number. At worst, your DAL will throw an exception as you try to read any old records from your database.

NoSQL has (some few) advantages over relational database systems, but the lack of schema is not one of them. And if you use NoSQL for the wrong reasons, implying for instance that "they have no schema, it's more easy to start my app", you're in for a lot of pain further down the road ...

If you had used a relational database system, such as SQL Server, MySQL or MariaDB - And you combined it with for instance Entity Framework or (n)Hibernate, you'd at least get a compiler error as you updated your database model from your database, or vice versa. With NoSQL, you're on your own. In these regards, NoSQL becomes the equivalent of an "untyped programming language", such as JavaScript - Compared to a "strongly typed programming language", such as C#, Java or TypeScript. And "untyping" your database is a very, very, very bad idea - Unless you absolutely have to (for other reasons).

For the record (pun!), there are ways to fix this, such as injecting some sort of adapter logic between the database reader, returning an untyped object, for then to "map" from the old structure to the new using code - But this only implies that you are aware of that there's an implicit schema in your database, and that you are willing to accommodate for it with code. In a "strongly typed" database (SQL), you could have done the entirety of the job during development, and then created an update database SQL script, converting your production database to its new structure. In NoSQL, you'll often end up with tons of "if version x, then do y" type of code, in your production environment, cluttering your project, with "temporary garbage code", not needing to be there if you had a "strongly typed" database. Besides, if others read some random X records from your database, interpolating their "average", trying to create a strongly typed model for reading these documents, maybe in a totally unrelated project for that matter - They might miss out on parts of your "implicit schema changes", making their code end up becoming a ticking bomb, just waiting to explode once they read an "old record" ..D

Database Relational database Schema NoSQL

Opinions expressed by DZone contributors are their own.

Related

  • NoSQL for Relational Minds
  • SQL Interview Preparation Series: Mastering Questions and Answers Quickly
  • Exploring the New Eclipse JNoSQL Version 1.1.0: A Dive Into Oracle NoSQL
  • Navigating NoSQL: A Pragmatic Approach for Java Developers

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!