Re: Database Versioning with IDS

This is a multi-part message in MIME format. --------------EA261E3FE91D7356C62884A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, Amgad for your comments! What you explained is one of the possible needs. Another one, my major problem right now, is when you write commercial applications that are delivered in releases with customers using different ones and supporting them. In the development environment you have to maintain source code versioning and database versioning. But, I think that having an ONCONFIG for each version is not a practical solution. Thanks again! amgad wrote: > 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 --------------EA261E3FE91D7356C62884A0 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Melvin Perez Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Melvin Perez n: Perez;Melvin org: CAM Informatica. S. A. email;internet: cam@codetel.net.do title: Technical Vicepresident tel;work: (809) 686-5574 tel;fax: (809) 686-5467 tel;home: (809) 227-2893 x-mozilla-cpt: ;-960 x-mozilla-html: FALSE version: 2.1 end: vcard --------------EA261E3FE91D7356C62884A0--