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
