--- title: "Mortal sin: A non-relational relational database." url: "https://osherove.com/blog/2004/2/19/mortal-sin-a-non-relational-relational-database.md" canonical: "https://osherove.com/blog/2004/2/19/mortal-sin-a-non-relational-relational-database.html" published: "2004-02-19T11:55:00" updated: "2004-02-19T11:55:00" tags: [".Net Original"] author: "Roy Osherove" description: "[Update: I removed the reference to COBOL. It was taken the wrong way and did not add anything to the conversation. Sorry if I've hurt anyone. ] This sin is probably one of the most prevalent of the sins I've listed…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Mortal sin: A non-relational relational database. By Roy Osherove February 19, 2004 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published February 19, 2004; technical details may be outdated. \[Update: I removed the reference to COBOL. It was taken the wrong way and did not add anything to the conversation. Sorry if I've hurt anyone. \] This sin is probably one of the most prevalent of the sins I've listed thus far. I've seen it in a lot of places but it takes its worst form when there are no relations at all in the database. I'm not talking about a 4 table DB here, I'm talking a full blown tens and hundreds of tables, almost all of them without a relation to save their life. This is a maintenance nightmare. The main reasons for this happening are usually: - Lack of knowledge\\experience building and designing relational databases - Getting the wrong hands to do the DB(People with no experience\\knowldge in DB design) - Not refactoring the DB when its time to. For example, you get new requirements and one of them turns a 1 to 1 relationship into a 1 to many relationship, but no one bothers to change the DB to accommodate. It's “too much work“. So they just pile up more rows or whatever else structures into the existing table instead. - After enough time has passed, you can't even refactor the DB anymore. Theres too much junk on it and anything you do breaks something terribly big. the main downsides: - You don't let the database provide an extra layer of confidence, especially data integrity rules, in which relational databases excel and make life very easy. - No one will be able to understand what the hell goes on in your DB without the dedicated help of the person who built it. That's trouble waiting to happen. - You won't be able to create pretty diagrams of the database with logical connections in them, although **mentally** these relations are there. They are just transparent and as weak as the code you wrote to protect them. You also won't be able to use automated code generators, object model generators and the like. Your DB is not speaking the universal language of DB description. **It's all in your head**. - Everyone will laugh at you in the newsgroups. (I bet that's the most potent argument yet!). Then again, if you create such a database, you probably don't read any newsgroups relating to these issues, do you? **Solution:** Get a good DBA already! Or, train someone in the fine art of relational databases. It's not that hard and it will save you huge amounts of money in the long run. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Feb 21, 2004 ### [Iterating over collections - As simple as possible, but no simpler.](https://osherove.com/blog/2004/2/21/iterating-over-collections-as-simple-as-possible-but-no-simp.html) - Feb 19, 2004 ### [Mortal sin: Just "Doit"](https://osherove.com/blog/2004/2/19/mortal-sin-just-quotdoitquot.html) - Feb 19, 2004 ### [Get your resource kit (and disregard the kit name)](https://osherove.com/blog/2004/2/19/get-your-resource-kit-and-disregard-the-kit-name.html) - Feb 18, 2004 ### [Stuff to know about the Data Application Block](https://osherove.com/blog/2004/2/18/stuff-to-know-about-the-data-application-block.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/