Re: Natural keys vs Aritficial Keys
Date: Sat, 23 May 2009 01:41:04 -0300
Message-ID: <4a177e1c$0$23742$9a566e8b_at_news.aliant.net>
toby wrote:
> On May 21, 1:02 pm, Michael Schuerig <mich..._at_schuerig.de> wrote: >
>>Bob Badour wrote:
>>
>>>Michael Schuerig wrote:
>>
>>>>Bob Badour wrote:
>>>>
>>>>>Mindless, automatic use of a numeric id without regard to the logical
>>>>>requirements is NEVER the lesser evil.
>>
>>>>Where do you get the "mindless"? Innuendo instead of argument, I
>>>>gather.
>>
>>>Where is the mindfulness in "Rails requires all tables to contain a
>>>column called 'id'" ?
>>
>>You wrote your accusation in response to a message where I refered to an
>>extension that makes composite primary keys available in Rails. If you
>>want that limitation lifted so bad, just use this extension.
> > Oh, no, you misunderstand profoundly if you think Bob is speaking of > personal antipathy to the restriction. His point is very sound that > such restrictions are almost certain to ruin any essay at correct > modelling. That's a profound flaw in popular ORM tools such as Rails > (and derivatives such as CakePHP, etc). > >>>>>notwithstanding the advantages that tool might provide in other
>>>>If you're sure you are right, I'd like to know your reasoning why it
>>>>is always bad to use a tool that encourages numeric ids,
>>>>regards.
>>
>>>First, we are not talking about a tool that "encourages" numeric ids.
>>>We are talking about a tool that mindlessly requires them.
>>
>>See above.
> > That there is "some extension" which may mitigate the problem doesn't > change Bob's point about the flawed design of the framework.
"The patient has been decapitated." "No problem, I have a box of bandaids."
An add-on to address a single detail of the flaw does not solve the problem.
>>>The appropriate tool for data management is a data management system.
>>>Among the principal functions of a data management system are the
>>>integrity function and the manipulation function. Compensating for the
>>>loss of the integrity function is a tall order that neither rails nor
>>>any ORM even begin to fill.
>>
>>Would you say that these principal functions are essential for, say,
>>blogs, wikis, or social networking sites such as Flickr?
>>
>>>Your suggestion that these products have anything that even remotely
>>>begins to compensate for the loss of the integrity function merely
>>>tells us you are ignorant of that function in the first place and
>>>confirms the OP's suggestion regarding a lack of understanding.
>>
>>No, we're talking at cross-purposes and you're unwilling to acknowledge
>>it, insisting that your constraints apply always and everywhere.
>>
>>There are application domains where quick development is more important
>>than 100% data integrity.
> > I don't recall Rails having a disclaimer, "Do not use this tool if > data integrity is important to your application." If it had, perhaps > adoption would have been more lukewarm. > >
>>There are applications, where high performance
>>is more important than immediate global consistency. You put down your
>>technical considerations categorically, whereas in practice they tend to
>>be toned down by business considerations. Like it or not, and whether I
>>like it or not, for that matter. There is a difference between
>>understanding the rules and abiding by them at all times.
> > Which is entirely beside the point, as the criticism was of dangerous > limitations of a *specific* tool.Received on Sat May 23 2009 - 06:41:04 CEST