I'm missing something, here; what earthly good is there, in having two fields
in the same tuple being created so that they both automatically store exactly
the same data... and if it was valuable, is there no way of more reliably
building this behaviour into the external application?
Okay, so I understand the idea about one field being the "creation" time, and
the other being the "last modified" time (which a particularly pedantic
application might regard as being one-and-the-same, at time of
first-creation) and so I see you might want to _store_ that fact in both
fields at time of creation: but even so, there is a fundamental difference of
type between the two fields, that remains, that is much more important than
the fact you can declare them both as DEFAULT NOW()... "Time of creation"
must never change; or it's existence is useless. "Time of modification" must
_always_ change; or it's existence is useles.
That kind of logic can only really be enforced by external business rules
built into the code, anyway, can't it? After all, we're building proper MySQL
Internet-based apps, here (Or at least I am), not some little Mickey Mouse MS
Access system, where the whole database manager is supposed to provide all of
the functionality for input, output and storage!
Anyway, what's all this got to do with subqueries?
On Thursday 09 June 2005 20:53, Greg Whalin wrote:
> Jeff Smelser wrote:
> > On Thursday 09 June 2005 01:26 pm, George L. Sexton wrote:
> >>Another limitation in MySQL is that you can only have one timestamp
> >> column with a default of CURRENT_TIMESTAMP.
> > How many friggin times do I have to say that this is not an issue with
> > 4.1 and above? Which, BTW, is production mysql..
> > Why do you keep bringing this up?
> > Jeff
> Are you sure? I don't see that from
> It seems that w/ > 4.1, you can specify any ONE timestamp col w/ default
> of CURRENT_TIMESTAMP. You are not limited to the 1st one, but still
> seems you are limited to a max of 1 timestamp. Or am I reading this wrong?