Optimize DB schema

[rr-]

Right now DB has 400MB for 10k users. Some columns should be scaled down to make DB smaller.

[rr-]

Scaling columns is not possible in SQLite.

We can use custom INTEGER instead of VARCHAR(10) to store date times, but that's rather extreme approach. We can also "vacuum" the database sometimes (basically, it's like defragmentation).

[oczki]

Saving time in Unix format - is anything extreme about this?

[rr-]

The problem is that user can skip specifying month while specifying year. UNIX timestamps are not designed for this. So the solution would be doing something YEAR_13_32 + MONTH * 32 + DAY to store and doing proper divisions to get them back.

[oczki]

Ah, I see. Indeed, it sounds a bit extreme, but I'm all for this if it works toward smaller database.

[rr-]

There are also following workarounds:

• Delete old users after a while to keep low database size
  Pros: we have total control over size, if it's too big -- just decrease user limit; sounds like the only reasonable choice
  Cons: fewer user sources for recommendation engine; global statistics will be meh; another cron job
• Perform "vacuum" occasionally
  Pros: will keep database size low... to some extent
  Cons: another cron job; this operation is extremely slow
• Switch to SQL engine that supports static typing (i.e. understands that INT(2) is different from INT(4))
  Pros: some micro-optimizations will become available
  Cons: some other micro-optimizations will become unavailable; lots of annoying changes; database goes non-portable

[rr-]

We're going to delete old users occasionally when DB gets too large. Also see #72.