jeg@zorch.SF-Bay.ORG (John E. Girard) (07/07/90)
I am looking for information on the relative effort, trials and tribulations of migrating data and structure between different database products. Does anyone have any boiler-plates or particular words of wisdom/rules-of-thumb on the subject? Also would be interested in estimates of the relative effort involved. Please respond to jeg@zorch.sf-bay.org or 415-968-3324 I will summarize if I get good information. Thanks! John Girard New Science Associates
eric@wdl1.wdl.fac.com (Eric Kuhnen) (07/12/90)
In article on database transfers, John E. Girard writes: >I am looking for information on the relative effort, trials >and tribulations of migrating data and structure between >different database products. Does anyone have any boiler-plates >or particular words of wisdom/rules-of-thumb on the subject? >Also would be interested in estimates of the relative effort >involved. <Am posting here; mail router bounced address.> 1) Stay within the same query language when moving between DBMS's. 2) Use delimited ASCII files for data, employing an obscure delimiter. For example, tab stops would not be good for conversion to Ingres since Ingres doesn't like tabs. Commas are a poor choice because some text data contains commas. The ` character (backward single quote) is less common and therefore a good choice. Even better are multiple-character delimiters like |\| or <?> which are easily constructed and fairly unique. "Q"
pavlov@canisius.UUCP (Greg Pavlov) (07/19/90)
In article <310002@wdl1.wdl.fac.com>,eric@wdl1.wdl.fac.com (Eric Kuhnen) writes: [ Re Porting Databases ]: > > 1) Stay within the same query language when moving between DBMS's. > While this does often help, it is not as big a factor as it may seem. One reason: if you use HLIs, the mechanism and/or syntax utilized by vendors vary substantially (example: imbedded SQL statements vs sub- routine calls). We have done cross-query language conversions that were relatively "easy" because the HLI interface was reasonably close. > 2) Use delimited ASCII files for data, employing an obscure delimiter. > For example, tab stops would not be good for conversion to Ingres > since Ingres doesn't like tabs. > 1. I don't know what "INGRES doesn't like tabs" means. Tabs are as good as any other delimiter I can think of for INGRES. INGRES's database unload/reload utilities use them for field delimiters. 2. I also don't think that, in most cases, delimited data is any easier than fixed format records. The ideal for us has been to write a "dictionary converter" that reads a dictionary produced by the source system and generates definition, creation, and load scripts/ commands/whatever for the target system. The ability to do that effects "ease of conversion" much more than the structure of the data. Especially in large conversions (in terms of numbers of tables). greg pavlov, fstrf, amherst, ny