| | 407 | Since I am not familiar with the suggestion on database refactoring I will only comment on the evolutionary versioning approach being debated. I have been working with relational databases for more than 30 years. SQL is fine, but whey force anyone to learn it if they don't already know it or don't want to? Otherwise why does Django provide automatic Model to SQL translation for everything from initial table creation to record entries, reads, etc.? I prefer the approach of providing a script or method that defines the changes from one version of a model to the next. It would be nice to have an automated introspection tool to create a first pass at this that I can edit to be absolutely correct and then have a tool that applies the intended changes so I do not have to generate the SQL and it will work no matter what database server I am using. This approach seems MUCH easier then Rails. Its also pretty much a requirement to automate and simplify updates to existing deployed apps. For those that love SQL, create a 2nd or optional alternative to the scripting/method approach alows the SQLphiles to use SQL. In much the same way that Django has a variety of parameters when defining Forms or Models to control Unique, Blank, etc. I can see a similar approach in version that defines how to translate a field from a prior version to the current version and if its simply a name change, it would work the same way. The prior column name would be changed to the new one, the data would not be translated and all will be right with the world. It would be nice for the tool that runs the evolution method to check for data translation incompatibilities so we wont hurt ourselves too badly. If this description was not clear, please say so because the solution seems clear and obvious to me. |