Combine everything?!

[LaRetta]

I realize I'm not the only one confused on how to fully take advantage of the new relationship model in FM7 but I hope someone can provide some insight. I understand relating Invoices and LineItems -- or Customers with their addresses, etc. but how far up the chain should these databases be combined? Staff also relates to Customers and I'm unsure whether to combine them also. If you think about it, EVERYTHING is related to the one single company and could be combined!

I'm specifically confused on my existing Preferences and Graphics databases - which hold buttons and backgrounds. If I combine everything into one model, will it be too much for FM7? In FM6, I have 14,000 Customers, 96,000 Invoices and 200,000 LineItems. And that doesn't even touch my Products (Inventory) and all my 'lookup' tables (special pricing for customers, etc.).

So I guess my question is ... should anything be separate? The only suggestion for some dbs being separate, is in relation to ease of updating the dbs. Security-wise, integration looks like the way to go. I feel a bit lost as I veiw my existing structures, on where to split them (if at all).

I've read a few other posts on this issue and still remain unsure. Splitting the interface makes sense but, since even lookup tables relate to some part of the overall related structure, separating them doesn't really make sense to me.

Any feedback would be much appreciated ...

LaRetta

Version: Developer v7

Platform: Windows XP

[Kurt Knippel]

Well, were you using Oracle or SQL Server you would most likely have 1 database with many tables, so going so far as to combine EVERYTHING is not extreme. However, even in those DBs, you will many times split tables into seperate DB for a variety of reasons. Load balancing, multiple servers, security, providing different resources to different groups, internal vs external usage/access, etc.

I am working right now on planning a rewrite of a 200+ DB system and I am probably going to end up with 11 files.

I have basically broken it down structurally: Billing, Staff, ProjectSetup, Utility, Library, MainMenu/UI, Calendar, ProjectMainMenu/IU, ProjExtras, Allocation, PhotoAlbum.

Even though there are alot of shared data and tables, I organized them according to what they were most related to. For example, even though the Company/Contact/Project information is used all over the place, it is most related the ProjectSetup group and thus is in that file.

What I plan on doing is putting only data in the files, the entire interface will reside in the two UI files.

[Fitch]

I've been thinking along the same lines as Kurt. Consolidate files that are related (in the conceptual sense), and then put all the UI stuff into a single file. The UI would not contain any actual data, except perhaps the graphics and globals.

[LaRetta]

Thank you, Kurt. This business is pretty simple structurally; although, we (they) plan for rapid development over the next five years so I want to be prepared to expand and flux as necessary. I appreciate your input and I'm glad to hear that 'everything' together won't overwhelm FM7.

Tom, the separate interface GUI makes total sense also. The freedom this new structure offers reminds me (somewhat) of Approach in that the Views are (can be) separate from the data and I feel quite at home with the concept. My original first-test structure indicates I'm moving in the right direction then, thank you.

This is an exciting time! I admit I feel a bit overwhelmed with FM7 but ... well, I operate at optimum levels when overwhelmed so I'm happier than a pig in mud.

LaRetta