Thanks again Drake, I'll investigate those alternatives. On 05/10/2010 13:52, Drake Wilson wrote: > Quoth Ian Hardingham<i...@omroth.com>, on 2010-10-05 12:27:38 +0100: >> CREATE TABLE IF NOT EXISTS userTable (name TEXT PRIMARY KEY NOT NULL >> UNIQUE, password TEXT NOT NULL, email TEXT, key TEXT, status TEXT, date >> TEXT, playedFor INTEGER, totalScore FLOAT DEFAULT 0, totalRecord TEXT >> DEFAULT '0\t0', dailyScore FLOAT DEFAULT 0, dailyRecord TEXT DEFAULT >> '0\t0', dailyGameRecord TEXT DEFAULT '', dailyGamesPlayed INTEGER >> DEFAULT 0, scoreStreak TEXT DEFAULT '', scoreStreakNumber INT DEFAULT 0, >> noEmail INT DEFAULT 0, playedInfIds TEXT DEFAULT '') > Those *Record fields look like the sort of thing that will expand to > include large blobs later on. If this is the case, possibly consider: > > - Moving the blobs into a separate table or tables, if they're > really best represented as singular blobs. Frequently updating > large blobs isn't going to give you very good performance, but > keeping them in separate tables will help prevent them from > impacting smaller updates. > > - Using separate tables and then actually storing the data in > relational form, if it's suitably representable. This could > result in much more efficient storage and access, because you'd be > using the SQLite components in a more natural way. The presence > of that \t suggests that you might be storing sequences of records > in those fields to start with; those could well be separate rows > in a suitable secondary table. > > ---> Drake Wilson > _______________________________________________ > 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
