Re: Database Versioning with IDS

Ing. Melvin Perez Cedano wrote: > > Hello all! > > I would like to get your opinions about having different database > versions for development or testing purposes in an IDS environment. > Apparently, the database vendors are not working in database version > management, so we have to find a way to maintain the change control, as > we do with source code files. > > There are several needs that could involve in having several version of > the database. A version could be a database with change at the schema > level or at the data level. > > Differently from SE, which create a directory for each database, IDS > doesn't allow to have several databases with the same name within the > same configuration (ONCONFIG). > Even though we could rename a database, we couldn't use the programs > with that renamed database. I think that Informix and the other database > vendors should provide a concept like synonym applying to databases > rather than tables, in such way that we could refer to a database with a > logical name within the programs and just change the synonym/link to the > desired database. I use a similar concept with SE trough UNIX symbolic > links. > > The first thing that comes to my mind in this issue is to have as many > ONCONFIG as desired databases versions. But, this approach will be very > resource consuming. > > Obviously, we'll need other tools, as script files to implement a fully > version control. > > I hope that my english had been fluently enough to let me understood.. > > Could you send your comments about this issue? > > Thanks in advance! > > --------------------------------------------------------------- > > Name: vcard.vcf > Part 1.2 Type: text/x-vcard > Encoding: 7bit > Description: Card for Melvin Perez From what I understood, you are talking about transaction-time temporal support in a database, where I might be intersted to query the database for old historical data that were relevant at a specific instance in the past, and it is not longer available now. This involves two issues, the database definitions or the schema and the actual data stored at the relevant point in time. In the database research community this is termed transaction-time databases which is part of temporal databases. One of the research database engines that supported this feature was the POSTGRES project at the University of California. This effort were led by Dr.Stonebroker in the early 1990's. POSTGRES introduced the no-overwrite storage manager, where transactions are appended only to the current data. This allowed for the application of the time-travel concept, where you can query the database at the current time or any time in the past. Relevant records at that time will only be reterived. This works fine, but introduces many difficulties. First, is the schema versioning where your schema changes will be recorded (not-overwritten) and the query engine will figure-out which version to use in the query. Second, is the challenging volume of data that have to be stored along with the optimal ways to speed thier queries. Commercial databases (to the best of my knowledege) does not yet provide this kind of capabilities natively (With the exception of Illustra, which provided similar functionality, but that functionality is no longer available in INFORMIX IDS Universal Data Option). That means you have to cater for them yourself. Like the efforts you had already mentioned above. However, temporal support in databases had been accepted into the SQL-3 database draft standard, and we do hope that major database vendors will add it to their databases. WHAT ABOUT INFORMIX OFFERING IT AS A DATABLAD MODULE IN IDS-UDO?? I hope this helps. Amgad