June 30, 200421 yr I know the drill ... Keep all Customer data within the Customer table, unless it is 1:n (one-to-many). But do you ever split a table just to make your life easier and the table more manageable? Our current design in 7 is hitting the 300-field mark (before any calculations or globals) and, wading through it is already tiring. There are no two 'like' fields within it but I have already gathered a few logical groups, ie, Credit information containing bank info, credit rating, FedID, OwnerOfRecord, etc - 45 fields); or Business properties, ie, sq. ft of store, # of employees, EndCap requirements - another 30). I see absolutely no problem or additional work to create these related records because, being a 1:1, I can simply place any non-key fields cross-layout anywhere I wish (with Allow Creation on) and a new record would be created if I enter any information. And NONE of these fields would ever contain more than one piece of information. And since 7 allows reaching up or down through all Table Occurrence Graphs, it shouldn't matter, right? 30% of our Customers will have nothing in the Credit section anyway so splitting would decrease file size a bit. And I feel more free in 7, not worrying about external files and additional network protections; and knowing I can easily access the data again. Before I split this and make our lives (hopefully easier), are there additional reasons for keeping it together in 7? Benefits I might lose (or just might be more difficult) if I split them? I appreciate any thoughts on it... LaRetta
June 30, 200421 yr These are called subset tables. They are used when you have different fields for different subgroups. I think that 300 fields in one table is way too many.
Create an account or sign in to comment