[development] User Status [WAS: User last access]

[David Timothy Strauss]

----- "Ivan Sergio Borgonovo" <mail at webthatworks.it> wrote:
> Hopefully MySQL is going to fix this kind of quirks and come up with
> a decent boolean implementation and you may end up in a not so
> efficient, hardly portable mess.

There's no industry-standard way to handle booleans, so I'm not sure what you mean by "fix this kind of quirks" when any efficient boolean implementation would be defined by you as a quirk.

> > "Make the common case fast."
> > <http://en.wikipedia.org/wiki/Amdahl%27s_law>
> 
> It can't be read as you're advertising it.
> You can't optimize the most used DB and make the overall application
> run faster on all DB.

Any optimization we make for MySQL has a huge impact on the base of Drupal installations. Any optimization we make for other DBs has a negligible impact. Therefore, it behooves us to spend our time concerned with optimizing for MySQL and merely verifying the correctness of implementations in other databases.

Amdahl's law applies because it establishes the relationship between an optimization and the overall impact on performance. If over 98% of Drupal installations use MySQL and 100% of Drupal installations use the user table, then an optimization to how we manage the user table in MySQL has a huge impact on overall performance. If under 2% of Drupal installations run PostgreSQL, then an optimization for PostgreSQL has minimal impact.

> What about:
> "We should forget about small efficiencies, say about 97% of the
> time: premature optimization is the root of all evil." D. Knuth

This is exactly why I support TINYINT(1) UNSIGNED NOT NULL or CHAR(0) on MySQL. CHAR(0) is portable as CHAR(1) on every database except Oracle. TINYINT(1) UNSIGNED NOT NULL is portable as larger unsigned integer formats on other DBs.

You're misunderstanding Knuth if you think we should care about storage space or performance on non-MySQL databases. Optimizing for MySQL is not premature optimization.