RE: Seriously.. When are we going to get subqueries?!

[Jay Blanchard]

[snip]
The issue with timestamp is this:

You can only have one timestamp with a default of the current date.

My app has two fields in one table

Created_date	datetime default now()
Last_update		datetime default now()

This doesn't work with timestamp because timestamp doesn't support two
columns with default current_timestamp. Additionally, it looks like if
you
default to current_timestamp then any time the record is modified, that
value is changed.
[/snip]

Well, George, you never mentioned that this was your problem. And you
would run into the same problem, given your definition above, regardless
of database (unless the database product has a hack to account for it, I
am not aware of any). But it is simply fixed. When creating the row you
include as your value for Created_date, NOW()....

INSERT INTO tblFoo (Created_date) VALUES (NOW())

...and then you never modify the Created_date again. The column with the
timestamp will continue to update properly when the record is UPDATED.

[snip]
While tinker-toys were wildly popular (I had them), they are wholly
unsuited
for large scale building projects.
[/snip]

I disagree. As shown by this link, a computer desk has been made from
tinker toys. http://www.charm.net/~jriley/tinkertoy.html :)

As far as MySQL is concerned it has been documented that there are more
than several large scale database application being utilized today,
including projects at Fortune 500 companies. I personally  manage
several MySQL databases containing 100's of millions of records on
OpenBSD and Linux systems. I have seen examples of MySQL databases
larger than the ones I am intimately familiar with. There are several
folks on this list who operate MySQL databases for large scale projects.