> Well, George, you never mentioned that this was your problem. And you
> would run into the same problem, given your definition above,
> of database (unless the database product has a hack to account for it,
> am not aware of any).
Not true. PostgreSQL can do it. If you want the timestamp modified every
time, a record is changed, you can use triggers to achieve this
transparently. In PostgreSQL you can also set the default value (at
creation time) to the output of a function.
I was unaware of that, but then you have to create a trigger...which is
a hack. A timestamp column will update anytime the tuple is updated
without additional triggers. And as Jeff points out MySQL 4.1 has a way
to control when the field gets populated.
My understanding was the timestamp fields were only set when the record
is created. They are not changed when the record is modified.
Not true, see above. And you can use the table creation statement I
provided earlier to make a table to test this with.
> As far as MySQL is concerned it has been documented that there are
> than several large scale database application being utilized today,
> including projects at Fortune 500 companies.
Indeed, but it depends on your application. If you are running something
big but very simple (e.g. 1 daily batch if INSERTs over night, and the
rest of the day of millions of SELECTs), MySQL is fine. On any project
where I actually have to manipulate the data and do more complex things,
I have been finding that MySQL simply isn't up to it.
Really? We do some very complex stuff with the data each day and have
had relatively little problem with these issues.
Horses for courses, as ever. If MySQL isn't capable enough for your
application, the correct solution is to find a more suitable database -
not moaning about how MySQL isn't good enough for your specific
application, just because you are afraid of learning how to use
something slightly different.