harryk Posted February 26, 2005 Share Posted February 26, 2005 Having thought of data separation, and noticing it is a hot topic now, just a thought for what it's worth. Data separation is a good thing, but it can be complex. It solves problems (data import after upgrading for example) but creates other problems to solve, too. My thought is, that if a database is relatively simple, and not too huge, you might think of a semi-solution. That is, that the main operations are executed on the main file (and perhaps some related files), just as you were used to without data separation. Extra though, is the built in option, to scripted export and import of data from the main file to a backup-data file (related of course), fully controlled through scripts. When update is needed of the main file, the data in it must be backed up to the data-file, before it is replaced. The new main interface file can be delivered/installed empty, scripts and control flags take care of the 'refill' of the main file with the contents of the related data file. The extra work of this scenario is scripting (field by field) the in- and export of the data. You could script it in a way that modifications are noticed and that on startup and/or closing the file the data-file is kept up to date. Extra benefit, some kind of backup. Just a thought. Harryk Link to comment Share on other sites More sharing options...
This topic is 6581 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now