Rule #38
Do you stop dealing with Data and Schema?
  v4.0 Posted at 25/05/2011 9:13 AM by system

Why don't most developers plan ahead? Take an average VB or Access application that you sell to a few customers. When the customer wants a new version, there is no problem giving the customer the new mdb or exe. But what if you made a back-end structural changes to your database? Big hassle! You need to compare the database to remind you what was changed. Sure there are utilities for this - for Access backends you can use SSW Data Renovator or for SQL Server backends there is Red-gate SQL Compareleave site - but why go to this trouble?

Take a version control approach. It doesn't have to be too complicated, but you should keep a history of structure changes in a table. Some developers use a text file (.sql) or hardcode it in code, that's fine, just don't make changes in the interface (i.e.. Access or Enterprise Manager). Changes should be made programmatically, or in a method that they can be played back.

An assumption to this is you have a front-end and backend table that is used to record the version number.

Table with cross through it Figure: Never make a change manually in Enterprise Manager or Access  Figure: Always save your changes in script  Figure: Name them in the order they're executed  Figure: An example of a backend table recording the version numbers

Tip: If you’re using Next Gen and you’re changing just one table, then just regenerate for that table

We have a program called SSW SQL Deploy to solve this problem and automatically make schema changes.
 

Loading
Do you like this rule?
Loading
Do you follow this rule?
Loading

......