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
