I haven't had a table that large, but I have had big ones... the disadvantage is the number of records you can scan in a single disk read, but an advantage is that you don't have to take the time to join tables, especially when you need to do it ALL THE TIME.
-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin Sent: Wednesday, May 22, 2013 3:11 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Max of 63 columns for a covering index to work? On 22 May 2013, at 7:58pm, David de Regt <dav...@mylollc.com> wrote: > if I have a 300 column table I'm going to sound my customary note of caution here. Do you really have a 300 column table or is it several thinner tables which have the same primary key ? Or do you really have a property list which should be one thinner table with a two-column primary key ? Generally in database design you should be able to hold a table schema in your head. When you find yourself numbering columns it's usually a sign you're doing something wrong. Not true in every case, of course, and you may have one of the incredibly rare cases which really is best represented with a 300 column table. In which case, please excuse me. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
