On Thu, Mar 16, 2006 at 11:34:31AM -0600, Jay Sprenkle wrote: > > > You may legitimately need one really large table but most applications > > > don't. > > Too bad. My guess is that you're doing the right thing trying to consolidate. > It's going to take expensive hardware no matter what you end up doing. > Your design is larger than any I've ever heard of using sqlite. My guess is > that it will work if you have enough RAM.
Why would it require a lot of RAM? I ask not because I doubt you, but because my intuition says that a BTree based database should scale pretty well. While certainly it would run faster if you can fit the whole thing in RAM, if the index can be made to fit in RAM it seems like the data can be just about any size. > I've used much larger databases than this on all of the big > commercial database engines (sqlserver, db2, informix, oracle). Any > of them will certainly work for you. Again, my intuition would be tha for single-user usage patterns SQLite should have less rather than more drop-off in performance than those. Is there something about the way that SQLite handles large files that would cause it to degrade faster than a commercial database? Are you saying he could get by with less hardware using a heavier weight database? --nate
