Object Relational Mappers are evil (a meditation)

[Mick Krippendorf]

If I knew what First Anormal Form was [...]

This refers to the Normal Forms one goes through when normalizing
relational databases.
(http://en.wikipedia.org/wiki/Database_normalization#Normal_forms)

The First Anormal Form (FAN) means just lumpin' data together in a comma
separated string that has to be un-lumped in a program. When there is
more than one such program operating on the same FAN-field you can bet
they interpret "comma separated" differently, or one wants the comma
separated values sorted and gets confused when the other program inserts
values in arbitrary order, or, if the one program expects ints, and the
other inserts floats, maybe not even using dotted notation, but
commas... you get the picture. In summa: FAN is evil.

Mick.

 

[Mick Krippendorf]

It appears to be a made-up term.

I read it somewhere once, I just can't find or even remember the source.
I definitely didn't make it up, though I wish I had.

Mick.

 

[Paul Rubin]

I read it somewhere once, I just can't find or even remember the source.
I definitely didn't make it up, though I wish I had.

I found exactly one google hit for it, which is this clpy thread.

 

[Robert Kern]

I found exactly one google hit for it, which is this clpy thread.

I believe he mistyped it. Try "First Abnormal Form":

http://www.sqlmag.com/Article/ArticleID/21369/sql_server_21369.html

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Paul Rubin]

I believe he mistyped it. Try "First Abnormal Form":
http://www.sqlmag.com/Article/ArticleID/21369/sql_server_21369.html

Ah, that makes sense. Article is subscriber-only but would seem to
explain the situation.

 

[Mick Krippendorf]

The word “anormal†appears to have been made up by you.
The negation of the word “normal†is “abnormalâ€, perhaps you meant
“First Abnormal Form�

Maybe my English (and my memory) is just not so good. I'm german, and
here "abnormal" and "anormal" are both negations of "normal", but with a
slight difference in meaning. "anormal" means just "not normal", whereas
the meaning of "abnormal" is more like "perverted". That's of course the
better word for the case at hand.

That term was in use when E. F. Codd was originally describing the normal
forms, and seemed to imply a database that was in even worse shape than 0NF.
More recently, this witty commenter at Daily WTF has defined a plausible
(though certainly not universally-agreed) set of abnormal forms
<URL:http://thedailywtf.com/Comments/Roll_Your_Own_Clustered_Index.aspx#121564>.

That's better. I'll keep googling though, because I distinctly remember,
if nothing else, that I have read "First Abnormal Form" being used for
the comma separation stuff.

Mick.

 

[Tim Wintle]

Maybe my English (and my memory) is just not so good. I'm german, and
here "abnormal" and "anormal" are both negations of "normal", but with
a slight difference in meaning. "anormal" means just "not normal",
whereas the meaning of "abnormal" is more like "perverted". That's of
course the better word for the case at hand.

From my understanding, the prefix "ab-" comes from latin (away /away

from) - which can also be shortened to "a" in some usages. (e.g.
abnormal)

The prefix "an" - which is more commonly shortened to "a" comes from the
greek - meaning "without" (e.g. anaerobic )

I agree that "abnormal" would be the better term here - as it does /can
have normalisation information, just not in a standardised manner.

 

[mario ruggier]

Occasionally I fantasize about making a non-trivial change
to one of these programs, but I strongly resist going further
than that because the ORM meatgrinder makes it somewhere
between extremely unpleasant and impossible to make any
non-trivial changes to a non-trivial program, especially after
it has been populated with data.

Object-relational mappers are like putting lipstick on a pig:
http://gizmoweblog.blogspot.com/2006/10/putting-lipstick-on-pig.html

m ;-)

 

[Aaron Watters]

Object-relational mappers are like putting lipstick on a pig:http://gizmoweblog.blogspot.com/2006/10/putting-lipstick-on-pig.html

m ;-)

Cute, but wrong. Using ORMs is better than using "Object databases".

In my case I use Python to un**** data created by java/hibernate.
If I was using a java based "object database" I would be simply stuck.
At least if you use an ORM you have a way to access the information
without writing a program in the programming language that the
ORM was defined in. Anyway, thanks for all the great comments on
this thread from all you Sarcopterygii and Haplorrhini out there.

-- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/GenBankTree/index

===

SQL is the worst possible data interface language
except for all the others. -- Churchill (paraphrased)

 

[J Kenneth King]

Cute, but wrong. Using ORMs is better than using "Object databases".

In my case I use Python to un**** data created by java/hibernate.
If I was using a java based "object database" I would be simply stuck.
At least if you use an ORM you have a way to access the information
without writing a program in the programming language that the
ORM was defined in. Anyway, thanks for all the great comments on
this thread from all you Sarcopterygii and Haplorrhini out there.

Data persistence isn't a "one-size fits all" problem. It really depends
on the needs of the system. Object databases solve the problem of
storing complex object graphs, deeply nested data structures, and
serializing language-specific objects like continuations or
what-have-you (but I think that last one is yet unsolved). We all know
what RDBMS' are good for. Neither is perfect for solving every data
persistence situation.

 

[Steve Holden]

I found exactly one google hit for it, which is this clpy thread.

It's a pun on First Normal Form. To transform a schema into First Normal
Form you remove repeating groups from the entity and place them in a
newly-created entity, leaving a copy of the identifier column behind to
express a relationship between the two.

regards
Steve

 

[Steve Holden]

I found exactly one google hit for it, which is this clpy thread.

It's a pun on First Normal Form. To transform a schema into First Normal
Form you remove repeating groups from the entity and place them in a
newly-created entity, leaving a copy of the identifier column behind to
express a relationship between the two.

regards
Steve

 

[Steve Holden]

Simon Forman wrote:
[...]

As far as the OP rant goes, my $0.02: bad programmers will write bad
code in any language, with any tool or system or environment they're
given. If you want to avoid bad code there's (apparently) no
substitute for smrt programmers who are familiar with the tools
they're using, not just the syntax but the underlying conceptual
models as well.

Hear, hear!

regards
Steve

 

[Steve Holden]

Simon Forman wrote:
[...]

As far as the OP rant goes, my $0.02: bad programmers will write bad
code in any language, with any tool or system or environment they're
given. If you want to avoid bad code there's (apparently) no
substitute for smrt programmers who are familiar with the tools
they're using, not just the syntax but the underlying conceptual
models as well.

Hear, hear!

regards
Steve

 

[Steven D'Aprano]

Simon Forman wrote:
[...]

As far as the OP rant goes, my $0.02: bad programmers will write bad
code in any language, with any tool or system or environment they're
given. If you want to avoid bad code there's (apparently) no
substitute for smrt programmers who are familiar with the tools they're
using, not just the syntax but the underlying conceptual models as
well.

Hear, hear!

That's all very well, but some languages and techniques encourage the
programmer to write bad code.

 

[J Kenneth King]

Simon Forman wrote:
[...]

As far as the OP rant goes, my $0.02: bad programmers will write bad
code in any language, with any tool or system or environment they're
given. If you want to avoid bad code there's (apparently) no
substitute for smrt programmers who are familiar with the tools they're
using, not just the syntax but the underlying conceptual models as
well.

Hear, hear!

That's all very well, but some languages and techniques encourage the
programmer to write bad code.

That's just BS.

Bad code doesn't just write itself. Programmers write bad code. And
ignorance is not an excuse.

Just because a language allows a programmer to write sloppy code doesn't
put the language at fault for the bad code programmers write with it.
Any half-way decent programmer should be cognisant of when they're
writing bad code and when they're writing good code. They should be
able to admit that they don't know enough about a language to be writing
programs for money in it. They should be able to see anti-patterns and
areas of their code that should be re-factored or re-written.

The real underlying problem is the human characteristic that allows us
to let ourselves believe that we're better than everyone else or more
simply, better than we really are.

 

[r0g]

That's just BS.

Bad code doesn't just write itself. Programmers write bad code. And
ignorance is not an excuse.

Just because a language allows a programmer to write sloppy code doesn't
put the language at fault for the bad code programmers write with it.

Okay, as long as you realize the corollary of your argument is:

It is impossible for a language to encourage programmers to write good
code and promote good programming practices by design.

I'm not sure that's entirely true either.

I think python's "one way to do something" design philosophy goes some
way toward that, as does Smalltalk's enforced message passing. I think
PHP's superglobals and namespacing encourage bad practices (or used to
back in the day), as do Basic's GOTO and Ecmascript's prototype overriding.

Surely a language CAN be said to encourage kludges and sloppiness if it
allows a good way and a bad way and makes the bad way much easier to
implement or understand for noobs.

Roger.

 

[J Kenneth King]

Okay, as long as you realize the corollary of your argument is:

It is impossible for a language to encourage programmers to write good
code and promote good programming practices by design.

I'm not sure that's entirely true either.

I think python's "one way to do something" design philosophy goes some
way toward that, as does Smalltalk's enforced message passing. I think
PHP's superglobals and namespacing encourage bad practices (or used to
back in the day), as do Basic's GOTO and Ecmascript's prototype
overriding.

I think your corollary is slightly misleading.

It would be more apt to say, "Just because a language allows a
programmer to write good code doesn't mean that the language is
responsible for the good code programmers write with it."

It is the responsibility of the programmer to recognize the advantages
and flaws of their tools. PHP doesn't encourage a programmer to be a
bad programmer because it lacks name-spaces or because BASIC has GOTO
statements. A bad programmer will be a bad programmer because they
don't understand what makes these features distinct, useful, or
damaging.

The language doesn't encourage anything. It's just a medium like oil
paints and canvas. A painting can be good or bad despite the medium it
is constructed on. The skill of the painter is what matters.

Surely a language CAN be said to encourage kludges and sloppiness if it
allows a good way and a bad way and makes the bad way much easier to
implement or understand for noobs.

Roger.

The programmer can be encouraged to use kludges and produce sloppy
code. Whether by ignorance or inflated ego. Languages with more choice
just give them more rope to hang themselves with.

 

[Neil Cerutti]

The language doesn't encourage anything. It's just a medium
like oil paints and canvas. A painting can be good or bad
despite the medium it is constructed on. The skill of the
painter is what matters.

Technically, oil paints do encourage a certain kind of painting.
They can be layered on top of old paint easily, and they dry
slowly, allowing you to slowly "build up" a painting in layers,
and create effects with texture. If you try doing thse things
with watercolors, and you'll probably be discouraged.

I think a programming language does encourage a certain kind of
code. Good code in one language can be poor in another.

 

[J Kenneth King]

Technically, oil paints do encourage a certain kind of painting.
They can be layered on top of old paint easily, and they dry
slowly, allowing you to slowly "build up" a painting in layers,
and create effects with texture. If you try doing thse things
with watercolors, and you'll probably be discouraged.

I think a programming language does encourage a certain kind of
code. Good code in one language can be poor in another.

It's a weak analogy on my part, but I think I do understand what you
mean here.

In regards to my original point, I think I just came up with a clearer
way to express it:

A language is a thing. It may have syntax and semantics that bias it
towards the conventions and philosophies of its designers. But in the
end, a language by itself would have a hard time convincing a human
being to adopt bad practises.

I believe it's the fault of the programmer who adopts those poor
practises. Surely their acceptance of GOTO statements and
prototype-overloading are signs of their own preferences and ignorance?
It suggests to me that they learnt enough of one language to get by and
stopped thinking critically as soon as they sat in front of their
keyboard.

Throw an idiot behind a Python interpreter and it won't teach them a
damn thing unless they're capable of learning it on their own. No
matter how well you manage to hard code your conventions into the
language. Bad code is written by bad programmers, not bad programming
languages.