On 2 Mar 2012, at 3:44am, Mario Becroft <m...@becroft.co.nz> wrote: > Making schema changes, such as adding or removing attributes, is not > necessarily difficult. This is what DML is for. However one thing SQL > does not handle well is temporal schemas, i.e. ones in effect during > different periods of time. The main reason why you might need to use > design B instead of A in this case is if you need to be aware of which > fields were valid at past times or will be valid in the future; for > instance, if you remove a field but you do not wish to lose the > information previously reported while that field existed, or more > subtly, if after adding a new field, you need to know that past reports > explicitly did not include that field.
Reports change. Data is eternal. Your schema should reflect the data stored in it, not the format of the report you happen to want at the moment. The people talking to you, Rich, were right. But they were rubbish at explaining why. One hint is that there's nothing special about the number 25. So any schema that allows you to immediately identify 25 should be treated with suspicion. Use the two-table design, and don't forget SQLite's group_concat(X) function: http://www.sqlite.org/lang_aggfunc.html which allows you to gather all the data for one row of your report in one long string, as long as the structure you store it in is well thought out. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
