On Mon, Oct 18, 2010 at 02:16:55PM +0100, Ian Hardingham scratched on the wall:
> If I wish to log how often a user does action x, I'm assuming I would be > best off doing something like: > But it strikes me that an alternative is to have one row for each time > the user performs action x, and to take the row count on the select > rather than the number column. This seems more "database-ey" (or normal > form-ey or whatever), but it also seems kind of a waste of space that I > might have 100 rows rather than one. The advantage of one row per event is that you can record event specific information, such as a timestamp, permission level, or audit/undo info, such as the old value and new value. If you don't need that information, and you truly just need a count, then there is no reason not to use a count. The only other considerations is if you have a huge number of rows, and if the database is write-mostly, or a more even balance. In most cases that's not a huge concern, however, other than reading a single value from a single row is usually much faster than a full table scan. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
