2012/8/28 Jim Nasby <jim@nasby.net>:
> On 8/28/12 2:51 PM, Pavel Stehule wrote:
>>>
>>> >The thing I don't like about this is it assumes that time is the best
>>> > way to
>>> >refer to when things changed in a system. Not only is that a bad
>>> > assumption,
>>> >it also means that relating things to history becomes messy.
>>
>> On second hand I don't have a problem with some optional counter,
>> although I think so database system time is very useful and other
>> counters for versioning are not necessary - because in one time I can
>> have only one version - it doesn't do versions from rollbacked
>> transactions.
>
>
> What happens if the system clock runs backwards?
>
probably, than you have more significant issues than this - it can be
same with overloading any counter
> What happens if two transactions start in the same microsecond? (And I know
> for a fact that's possible, because I've seen it).
yes, it is possible - and probably you need to know end of transaction
- commit time - auxilary counter doesn't help - because it can be in
different order too - when first transacttion was rollbacked
Pavel
>
> More importantly, I believe using time to handle recording a versioned
> history of something is flawed to begin with. You might care about what time
> a new version was created; but what's far more important is recording the
> correct ordering of things, and time isn't actually a great way to do that.
>
> Note that no version control systems use time as their primary attribute.
>
> --
> Jim C. Nasby, Database Architect jim@nasby.net
> 512.569.9461 (cell) http://jim.nasby.net
