Jodin Posted February 24, 2005 Share Posted February 24, 2005 We are rebuilding our vertical market solution which was 32 files in v4/5/6. Will probably have 50+ tables in v7 when properly designed. No need for separate interface files. Solution is bound and put into an installer for 'shrink-wrap' distribution. Have shipped about 1 upgrade per year for 4 years, always with a built-in 'update wizard' written in FMP and using Troi-File for the behind the scenes file movement. Data imports would take anywhere from 30 minutes to 2 hours depending on machine speed and dataset size. I have been learning the new relationship model for 7 and the only actual advantage I see for us splitting into more than 1 program file is the promise of import-less upgrades. I can't imagine that after 1 year we would release an update with no business logic improvements, therefore to do a true importless upgrade we would need to employ the true separation model (meaning keep all the potentially buggy or changeable logic out of the data tables). From what I understand about this true separation model it requires a 'staging' file or a mimicked data file and in many ways doubles or triples your development work and confusion. I guess I see this as a no-win situation - you either continue to deal with big data imports when updating out in the field, or you need 3 separate files minimum and the development that goes along with that (security & script replication, relationship graph confusion, etc.) If anyone has a suggestion or good argument for using a separate data table, even if you still must import it to a new one upon upgrade, please let me hear it. This is just dealing with the app itself -- we are considering a separate Utilities file that only opens to repair, archive, or compress our solution file. But my initial thoughts of having the data file seperate to increase speed hasn't shown up in much testing. Link to comment Share on other sites More sharing options...
This topic is 6585 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