On 16/10/2010 12:01 PM, Dustin Sallings wrote: > > ...but there will also be a unique index on rowid, which will get large > and need to be maintained. I'm concerned that this alone could be limiting > me somewhat. > > I have a similar application with a single table that I'd like to split > into more based on an identifier that appears in the table. All of my > operations are limited to one of these identifiers (though it's not indexed, > the lookup is always by rowid). Occasionally, I want to delete all records > based on an ID. > > Bobby Tables is not relevant to my application as I know how to do my > bindings properly and have no confusion with data types (this is an integer) > or user data vs. executable code. > > As a single table, I can easily have many tens of millions of rows. > Splitting it into 1,024 tables by a specific ID, I'd expect the each index to > be smaller and (at the very least), I'll have a far easier time deleting a > large chunk all at once. > > I do intend to do some experimentation here, though it'd be helpful to > have some more detailed pointers as to why the intuition is wrong here. >
Very similar to me. So far it is proving a good solution. But proof would be scaling from a dozen dynamic tables so far to hundreds+. If you do some testing on that please post. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
