Old school database Mapper worked along that line, you had a ton of small tables and a lookup table that told your queries what table to look in...all in all it was a mess.
-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin Sent: Friday, November 29, 2013 7:31 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Eficiency : 1 table vs several tables On 29 Nov 2013, at 8:27pm, Carlos Ferreira <car...@csiberkeley.com> wrote: > Let's assume that TABLE now designates my real tables that can be > either SQLITE tables or sub groups of records inside one big real > SQLite table > > > > I have to load to memory and save to DB groups of these TABLE at the > same time ( by saving I refer to update or save the blobs inside each table ). > > > > What if faster? SQLite is optimized for searching a table for specific values. Assuming, of course, that you have an index ideally suited to your search. It is not optimized for searching a huge list of tables for one with a specific name. My assumption is that putting 1000 tables in a database is going to slow down every operation since every operation has to search for the correct table and /then/ search that table for the correct row(s). But I have no figures to prove that. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
