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. You should be able to keep the schema of a table in your head at one time. So no tables with 30 or more columns. Finding a table with numbered columns, especially, is usually a sign of poorly designed schema. There are speed and handling problems with tables with more than one BLOB column. It's feasible, under some circumstances, that you might want to spin multiple-BLOBs-per-record into a second table, or keep only one BLOB in the first table. 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. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
