On 11/30/12 8:34 AM, "Simon Slavin" <slav...@bigfraud.org> wrote:
> >On 30 Nov 2012, at 3:50pm, Staffan Tylen <staffan.ty...@gmail.com> wrote: > >> I'm looking for both administrative and technical advice on the pros and >> cons of either creating one single database table with many columns or >> creating multiple tables with fewer but related columns to be JOINed >>when >> needed. Assume that the data is all related 1-to-1, like name, home >> address, primary phone, shoe size, favourite politician (NULL >>accepted!), >> etc. At a first glance it seems logical to select a single table as it >> simplifies access to the data but there may be good reasons that I'm not >> aware of to split the data over multiple tables. I have only limited >> experience of SQL so any guidelines are appreciated. Thanks in advance. > ><snip> >Apart from that, SQLite is pretty efficient at 'wide' tables as long as >you keep the column count below 30 or so. There's really not that much >to worry about and no need to do JOIN in cases where you have a 1-to-1 >relationship. I use SQLite as a data store for a simulation model. I have a number of different kinds of simulation entity, and then many results that are computed during simulation. These results are often 1-to-1 with a given kind of entity, but in practice I create one table for the entity definitions, and separate tables for each kind of result. This allows a nice separation of concerns: I never need to puzzle over where a particular column's value comes from. It's either a scenario input, or from the particular model with which the table is associated. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
