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...
RalphL Posted February 24, 2005 Share Posted February 24, 2005 If you have to be talked into it then you probably shouldn't. You have to be confortable with it before you use it. Even with data completely separated there is a chance that you will add new data fields and that will require upgrading the data file. Link to comment Share on other sites More sharing options...
Jodin Posted February 25, 2005 Author Share Posted February 25, 2005 sounds good ralph, that's kinda where i'm at with it, but was looking for some corroberation. an importless upgrade *would* be nice, but it alone doesn't appear to be worth the extra work for us. then again -- there's the speed issue. our app does do some serious math (decaying isotopes, charting decay verse equipment readings, etc.) that would really slow down the poor overtaxed and non-normalized tables in our old version. assuming the poor design is corrected and totally normalized in v7, is there any signs of a slower table (lots of complex calcs) dragging on the rest of the system? that's the only other reason i see to split files -- one for tables with math intensive fields (the slow file) and one with quicker tables. thoughts? and where are all the other experts on fm forums? i would hang out here much more if it wasn't so full of newbie questions. ralph you seem to reply the most often to my stuff. Link to comment Share on other sites More sharing options...
bruceR Posted February 26, 2005 Share Posted February 26, 2005 I don't see why 3 files would be required. Also, regarding new fields, you can hedge by adding some extras and not using them. They are Text01, Text02, etc and you just put labels on them in the interface file. Finally, there is an entirely different design method. You roll your own data structure. There is one table. Each record has a table ID, recordID, fieldID, and then the actual data field. You can build any kind of strucure this way. Link to comment Share on other sites More sharing options...
DLS Posted February 28, 2005 Share Posted February 28, 2005 I am not totally sold on the separation model. I am concerned with all the unstored calcs in the BR file. I haven't heard any feedback from anyone regarding this issue. Am I missing something here? All calcs in the BR will be dependent on a relationship therefore they cannot be stored/indexed. Right? If you are running reports on large files with unstored calcs it could take hours to do what could otherwise be done in minutes. Link to comment Share on other sites More sharing options...
bruceR Posted February 28, 2005 Share Posted February 28, 2005 There are various ways to do separation. The most "pure" way is the 3 file model, put all the calcs into the BR file but this isn't the only way to do things. You can also use a 2 file model where you have the interface in one file and data plus calcs in the data file. You reduce the need to change the data file and *most* changes can be accomplished just by swapping out the interface file. Link to comment Share on other sites More sharing options...
Jodin Posted March 2, 2005 Author Share Posted March 2, 2005 yeah i can see advantages to the seperation, mainly for busy custom developers who need a nice template system, for instance, and multiple projects that all require a calendar or contact manager, etc. the extra fields idea is also doable if you are not adding extensive features to the system when updating. true, there's bug fixes and UI features that can be added without ever touching the data tables, but we try to roll out new data-driven features also, and those require changes to the back end. so, no comments on the concept of a 'slow' file and a 'fast' file, or offloading the intensive math tables into their own file to seclude their speed hit from the rest of the system? i guess this gets into multi-threading and other non-disclosed FMP internals, but if you have a table that is churning away in the background, does it's speed hit affect the entire FM app, just the file the table lives in, or just processes that touch that particular table? thanks for all the feedback here -- i'm more cut-off than usual on this project so i like having a sounding board, especially with the new version making us all feel like newbies again. Link to comment Share on other sites More sharing options...
artypants Posted March 13, 2005 Share Posted March 13, 2005 These are intriguing comments but there is more to it than one versus two versus three layers. FileMaker is great for rapid development. When you start adding layers I cannot see why this is any better than developing your tool in another platform where the database and code are naturally seperate. SQL upgrades to the table structure are done without affecting the data and compiled code is upgraded without affecting the data at all, too. Clean and simple. So, it seems to me that the only reason to do the three table thing is really that FileMaker is your safety zone. Not that I feel real comfortable with MySQL and Java, yet. But that seems to be the more logical way to develop a commercial tool. Are there advantages to FileMaker compared to more traditional development platforms other than it is my comfort zone? Link to comment Share on other sites More sharing options...
artypants Posted March 13, 2005 Share Posted March 13, 2005 These are intriguing comments but there is more to it than one versus two versus three layers. FileMaker is great for rapid development. When you start adding layers I cannot see why this is any better than developing your tool in another platform where the database and code are naturally seperate. SQL upgrades to the table structure are done without affecting the data and compiled code is upgraded without affecting the data at all, too. Clean and simple. So, it seems to me that the only reason to do the three table thing is really that FileMaker is your safety zone. Not that I feel real comfortable with MySQL and Java, yet. But that seems to be the more logical way to develop a commercial tool. Are there advantages to FileMaker compared to more traditional development platforms other than it is my comfort zone? Link to comment Share on other sites More sharing options...
artypants Posted March 13, 2005 Share Posted March 13, 2005 These are intriguing comments but there is more to it than one versus two versus three layers. FileMaker is great for rapid development. When you start adding layers I cannot see why this is any better than developing your tool in another platform where the database and code are naturally seperate. SQL upgrades to the table structure are done without affecting the data and compiled code is upgraded without affecting the data at all, too. Clean and simple. So, it seems to me that the only reason to do the three table thing is really that FileMaker is your safety zone. Not that I feel real comfortable with MySQL and Java, yet. But that seems to be the more logical way to develop a commercial tool. Are there advantages to FileMaker compared to more traditional development platforms other than it is my comfort zone? Link to comment Share on other sites More sharing options...
Newbies FMGuru Posted March 13, 2005 Newbies Share Posted March 13, 2005 I continue to use separate, related files as then if one file becomes corrupted, the chance of losing data is limited to that particular file. With the integrated "tables" schema, if the file crashes and corrupts, so does all data resident within. But then I could be wrong . . . Link to comment Share on other sites More sharing options...
Newbies FMGuru Posted March 13, 2005 Newbies Share Posted March 13, 2005 I continue to use separate, related files as then if one file becomes corrupted, the chance of losing data is limited to that particular file. With the integrated "tables" schema, if the file crashes and corrupts, so does all data resident within. But then I could be wrong . . . Link to comment Share on other sites More sharing options...
Newbies FMGuru Posted March 13, 2005 Newbies Share Posted March 13, 2005 I continue to use separate, related files as then if one file becomes corrupted, the chance of losing data is limited to that particular file. With the integrated "tables" schema, if the file crashes and corrupts, so does all data resident within. But then I could be wrong . . . Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 6978 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 accountSign in
Already have an account? Sign in here.
Sign In Now