Re: Natural keys vs Aritficial Keys

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).

>
> >> 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,
> >> notwithstanding the advantages that tool might provide in other
> >> 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 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.

>
> Michael
>
> --
> Michael Schuerig
> mailto:mich..._at_schuerig.dehttp://www.schuerig.de/michael/
Received on Sat May 23 2009 - 05:04:51 CEST