Jay Blanchard wrote:
[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.
Not true. Triggers are in the SQL specification. They are a legitimate
feature with specified expected behaviour. A hack is only implementing
function returns as default field values on timestamps, rather than
handling all field types in a unified way and allowing them to be set to
the return value of a function by default.
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.
You really cannot have tried very hard, then. :-)
[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.
Thank you. :-)
Gordan
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
