[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).
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.
[/snip]
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.
[snip]
My understanding was the timestamp fields were only set when the record
is created. They are not changed when the record is modified.
[/snip]
Not true, see above. And you can use the table creation statement I
provided earlier to make a table to test this with.
[snip]
> 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.
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.
[/snip]
Really? We do some very complex stuff with the data each day and have
had relatively little problem with these issues.
[snip]
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.
[/snip]
Spot on.
