I'm currently building a library of database schema that developers can use to design database schema faster. https://www.dbschemalibrary.com
I find myself spending days to design a database schema on every new project. The motivation behind this is that developers can use the library as reference or to copy paste from existing schemas. The hope is that those examples will lead to better design decisions in a shorter amount of time.
Would love to hear if this is something you'll find useful. Thanks!
It went offline earlier this year, but <https://web.archive.org/web/20220330034214/http://www.databa...> is something similar too. Diagrams not copy-pastable DDL, but at least for me the value is in seeing how other people have approached similar modeling problems, not in copying down their solutions -- so diagrams are perfect.
I think you might get better reception once there is some actual content, because I think this is a fantastic idea.
But right now it’s nothing more than a nice graphic and email collection form. Hope to see it again here soon.
My heartburn with schema.org is that they took the "junior developer writes javadoc" approach for so many of the fields by just restating the field name in more words: https://schema.org/bookEdition ("The edition of the book.") -- yeah, thanks, Einstein; so "2nd", "2E", "second ed.", and "I like big butts and I cannot lie" are equally valid book editions, are they? :-/
I worry we are skipping over an important design step by outsourcing our schema.
What tables and columns are involved in a database is just as much the business owners concern as it is the developers concern. There aren't a whole lot of situations where the developers can invent a fantasy schema that just happens to fit perfectly with everyone else's understanding of the business. There are also seriously powerful, multi-spectral dragons lurking for those who think they can lock their nasty schema behind an API and throw away the key.
In my experience, things tend to go a lot more smoothly when non-technical stakeholders can look at a sample excel workbook demonstrating the schema and agree with its contents. Every nasty workaround I have ever had to deal with at scale could ultimately be boiled down to a bad database schema or model that was poorly designed relative to the problem domain. How you arrange your data is the most fundamental part of any software. This all gets back to information theory and hard math at a certain level. The instructions are just a means to an end.
All of that said, we usually have to start somewhere and having a library of schema samples to review can serve as a powerful kickstart in the right direction. Just make sure you aren't inventing this in a vacuum relative to the business at hand.
13 comments
[ 3.8 ms ] story [ 40.6 ms ] threadI'm currently building a library of database schema that developers can use to design database schema faster. https://www.dbschemalibrary.com
I find myself spending days to design a database schema on every new project. The motivation behind this is that developers can use the library as reference or to copy paste from existing schemas. The hope is that those examples will lead to better design decisions in a shorter amount of time.
Would love to hear if this is something you'll find useful. Thanks!
Oh wait... "Get early access"? So it's not an open library?
Anyway, check out David Hay's "Data Models: A Metadata Map", it's basically a big catalog of all the data models you'll need already worked out. https://books.google.com/books/about/Data_Model_Patterns_A_M...
Here's a great free resource-- https://web.archive.org/web/20160308080311/http://www.databa...
https://schema.org/
I worry we are skipping over an important design step by outsourcing our schema.
What tables and columns are involved in a database is just as much the business owners concern as it is the developers concern. There aren't a whole lot of situations where the developers can invent a fantasy schema that just happens to fit perfectly with everyone else's understanding of the business. There are also seriously powerful, multi-spectral dragons lurking for those who think they can lock their nasty schema behind an API and throw away the key.
In my experience, things tend to go a lot more smoothly when non-technical stakeholders can look at a sample excel workbook demonstrating the schema and agree with its contents. Every nasty workaround I have ever had to deal with at scale could ultimately be boiled down to a bad database schema or model that was poorly designed relative to the problem domain. How you arrange your data is the most fundamental part of any software. This all gets back to information theory and hard math at a certain level. The instructions are just a means to an end.
All of that said, we usually have to start somewhere and having a library of schema samples to review can serve as a powerful kickstart in the right direction. Just make sure you aren't inventing this in a vacuum relative to the business at hand.