I thank you for your answer. The more I think about it, the more I find the second option better. Just one precision. All tests are always done, so I always hae all columns filled with a result.
My only trouble was about size and performance. I store only a few byte with a lot of overhead (#assessment_nr, labtest_nr) for only one integer and one real per row. And I can have up to 1.500.000 rows per year with at least 10 years on line... It means big indexes. Regards. Alain > I would go for the second one. I think the size of the table is not a > problem. You will have just to write the right indexes for easy joins. > > OBS: " For one assessment, I'll store 60 rows with only two useful > integers in it" ... why? Better make a "lab_test" table where you have > the tab tests and you write in the results(#assessment_nr, labtest_nr, > p, d) only those datas that you have. For example if you have the > assesment no. 3000 and you have only the results for lab_test 10->40 > then why to write in the DB also the lab_test from 40->70(if you don't > have it)??? (if I didn't understand this clear, sorry for the > observation). > > > The second option is better if you change one time the lab_test > list(have to think also this option --- if making the database for at > least 10 years). Because in the first solution you will have to add > always a new column... and that is not the "best" option. In the > second way you just add a new ID in the lab_test list and finish. No > problems. > > If you go for the first option and you have to change something in the > result table... it won't be easy. > > The alter table is not so tragical as it seems... use > constrains...don't ever erase from DB. > > So... my final answer: the second option. Alain Reymond CEIA Bd Saint-Michel 119 1040 Bruxelles Tel: +32 2 736 04 58 Fax: +32 2 736 58 02 [EMAIL PROTECTED] PGP key sur http://pgpkeys.mit.edu:11371 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
