Chris's Wiki :: blog/programming/DatabasesAlwaysSchemas Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/DatabasesAlwaysSchemas?atomcommentsDWiki2019-02-26T02:11:03ZRecent comments in Chris's Wiki :: blog/programming/DatabasesAlwaysSchemas.By Salient Panda on /blog/programming/DatabasesAlwaysSchemastag:CSpace:blog/programming/DatabasesAlwaysSchemas:af571da36d3bb8ee2422946d60d907e39cca8451Salient Panda<div class="wikitext"><p>This is analogous to the comparison of strongly typed vs loosely typed languages. It's a question of how many tools are helping you ensure that you've fully considered your mental model and have correctly translated it into working software.</p>
</div>2019-02-26T02:11:03ZBy Hal on /blog/programming/DatabasesAlwaysSchemastag:CSpace:blog/programming/DatabasesAlwaysSchemas:805e6628099c5490b9c26902ce0b2f8786d4a875Hal<div class="wikitext"><p>I always thought every application should have a rigid database with a well planned schema until I ran into a coordinating system that supported a large number of commercial applications at various release levels as well as various computer systems using various operating systems. In the part where the coordinating system sends instructions to the other systems the database has an XML datatype column. Each combination of operating system / application / release has its own XML schema that is defined within the code for that particular combination. You have to purchase these modules separately. When the base code calls the specific system it uses the module which interprets the XML and sends the correct commands to the other systems. Now you can support each type of combination independently and coordinate everything from one consistent source.</p>
</div>2019-02-25T16:23:45ZBy Greg A. Woods on /blog/programming/DatabasesAlwaysSchemastag:CSpace:blog/programming/DatabasesAlwaysSchemas:269b76eeea666e6c1707f6cff70f3886b7827fb4Greg A. Woods<div class="wikitext"><p>One other advantage to having a schema in the DB is that you can much more easily manage migration of your overall data schema over time as your code changes.</p>
<p>Code and data are necessarily separate, at least they are if you consider that your system survives over more than one execution and especially if your system evolves to meet changing needs, expectations, and understandings.</p>
<p>I've found in systems that I've worked on recently, where code and DB schemas are derived from one shared definition, that evolution of the schema is far safer and more reliable if the persistent store (the DB) contains a recorded schema as well, one that matches the current state of the data at any given time. With some care in defining conversion code to support any previously released version of the schema this means we can take any new version of the code and have it successfully run on any old DB.</p>
<p>Furthermore we've found that the persistent DB schema is also useful in helping manage optional features in library code shared by several applications. Here we can use the presence of a table, or a field in a certain table, to enable a feature in the library code, and to allow this feature to be enabled and disabled by the evolution of the application and specific instances of the DB.</p>
<p>I don't see how these two things could be done reliably if there were not also a persistent schema associated with the persistent data. I guess in theory the only persistent schema strictly needed would be a single value, a version ID. However all the other traditional features of an SQL schema make the whole system far more robust and manageable, and flexible.</p>
</div>2018-09-22T20:38:02Z