Re: Surrogate Keys: an Implementation Issue
Date: Fri, 28 Jul 2006 16:01:24 GMT
Message-ID: <oxqyg.258599$IK3.228448_at_pd7tw1no>
Bob Badour wrote:
> paul c wrote:
>
>> Brian Selzer wrote: >> >>> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message >>> news:e43yg.27359$pu3.361813_at_ursa-nb00s0.nbnet.nb.ca... >>> >>>> JOG wrote: >>>> >>>>> J M Davitt wrote: >>>>> >>>>>> [big snip] >>> >>> ... >>> How much work have you done in the field? This comment makes you >>> sound like a neophyte. >>> ... >> >> Is this changing the subject?
>
> Paul,
>
> Selzer is apparently unable to extract the meaning from relatively
> simple english. Why would anyone care what anything sounds like to such
> an idiot?
Shouldn't have to, I admit. I was merely trying to keep the discussion honest. I've met so many people who throw out such red herrings when what they really want to do is extend a theory because they like a technique that deals with a problem the theory doesn't talk about at all (ie., concurrency, which I see as an application problem, in the same sense that the changing of an account balance is an application problem, not an RT problem). I resent the push to hack together/entangle different theories because it makes it so much harder to see whether any one of them is being applied correctly. I admit it's 'jobs for the boys' but those jobs are a phony kind of economy and I don't see why it should be that most dbms's are so fat. It would be more faithful to the end purpose if application designers understood their concurrency requirements rather than memorize locking degree hierarchies.
p Received on Fri Jul 28 2006 - 18:01:24 CEST