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:
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?
No replies to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users