cornix Posted August 5, 2003 Share Posted August 5, 2003 Greetings I\'m developing an intranet-based system for filing sampling journals. I have 6 different types (which may get more later) of samples which need different forms. Partially these forms contain parts which may be taken for all different types of samples, for example the header with positional data and so on. Now the current way I\'m doing it is that I have a totally modular system. I split up the forms, write the code and put them into a DB named form_parts. It\'s set up like this: form_parts formpart_id show_form add_form add_sql ... Next DB I have is sample_type which connects the samples with the proper form-parts. My question now is: How do I choose the right DB-stucture for the sample data? 1. I may continue the modular way: 1 table per form-part (the way I\'m doing it ATM), which ends up in a whole lot of tables (approx. 8 parts per form x 6 samples = 32 tables) which results in a whole lot of chaos :? Pro of this way is that I may add more sample types later easily 2. One table per sample type: Much less tables, but double structure for e.g. the header 3. One for all, all in one: I could put everything into one table. Would make life easy. Not needed columns would be filled with Null-Values. Proper output would still be given due to the \"show_form\" parts, which pick out the proper parts Which of this 3 would you choose or do you know any better solution? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.