DM Rule #7: ID's are evil.

[David Nuescheler]

Explanation:
---
In relational databases IDs are a necessary means to express
relations, so people tend to use them in content models as well.
Mostly for the wrong reasons through.

If your content model is full of properties that end in "Id" you
probably are not leveraging the hierarchy properly.

It is true that some nodes need a stable identification throughout
their live cycle. Much fewer than you might think though.
mix:referenceable provides such a mechanism built into the repository,
so there really is no need to come up with an additional means of
identifying a node in a stable fashion.

Keep also in mind that items can be identified by path, and as much as
"symlinks" make way more sense for most users than hardlinks in a unix
filesystem, a path makes a sense for a lot of applications to refer to
a target node.

More importantly, it is _mix_:referenceable, which means that it can
be applied to a node at the point in time when you actually need to
reference it.

So let's say, just because you would like to be able to potentially
reference a node of type "Document" does not mean that your "Document"
nodetype has to extend from mix:referenceable in a static fashion
since it can be added to any instance of the "Document" dynamically.

Example:
---
use:

/content/myblog/posts/iphone_shipping/attachments/front.jpg

instead of:

[Blog]
- blogId
- author

[Post]
- postId
- blogId
- title
- text
- date

[Attachment]
- attachmentId
- postId
- filename
+ resource (nt:resource)

[sbarriba]

Hi David,

[Very useful set of DM Rules by the way!]

"so there really is no need to come up with an additional means of
identifying a node in a stable fashion"

We had one requirement that prompted us to introduce an instance of a
numeric 'id' field that is managed using the Sequence node solution. Our
requirement was for a unique id that referenced a particular class of nodes.
This id was to be used as a HTTP parameter. UUIDs are too large and unwieldy
for our application. Furthermore we wanted to control the format and UUIDs
may change format in the future.

Introducing this solved the requirement but has caused is various headaches
of ensuring when saving, importing etc that the ids remain unique. I'm not
aware of any alternative solutions with JCR?

Regards,
Shaun

-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@...]
Sent: 07 July 2007 12:35
To: users@...
Subject: DM Rule #7: ID's are evil.

Explanation:
---
In relational databases IDs are a necessary means to express
relations, so people tend to use them in content models as well.
Mostly for the wrong reasons through.

If your content model is full of properties that end in "Id" you
probably are not leveraging the hierarchy properly.

It is true that some nodes need a stable identification throughout
their live cycle. Much fewer than you might think though.
mix:referenceable provides such a mechanism built into the repository,
so there really is no need to come up with an additional means of
identifying a node in a stable fashion.

Keep also in mind that items can be identified by path, and as much as
"symlinks" make way more sense for most users than hardlinks in a unix
filesystem, a path makes a sense for a lot of applications to refer to
a target node.

More importantly, it is _mix_:referenceable, which means that it can
be applied to a node at the point in time when you actually need to
reference it.

So let's say, just because you would like to be able to potentially
reference a node of type "Document" does not mean that your "Document"
nodetype has to extend from mix:referenceable in a static fashion
since it can be added to any instance of the "Document" dynamically.

Example:
---
use:

/content/myblog/posts/iphone_shipping/attachments/front.jpg

instead of:

[Blog]
- blogId
- author

[Post]
- postId
- blogId
- title
- text
- date

[Attachment]
- attachmentId
- postId
- filename
+ resource (nt:resource)

[Jukka Zitting]

Hi,

On 7/7/07, sbarriba <sbarriba@...> wrote:
> We had one requirement that prompted us to introduce an instance of a
> numeric 'id' field that is managed using the Sequence node solution. Our
> requirement was for a unique id that referenced a particular class of nodes.
> This id was to be used as a HTTP parameter. UUIDs are too large and unwieldy
> for our application. Furthermore we wanted to control the format and UUIDs
> may change format in the future.

It really sounds like you have some heavy external constraints that
you need to satisfy. What external system needs this "id" field and
why the format needs to be controlled?

If you just need something to identify a node in a HTTP parameter,
then I'd much rather use just the path of the node.

BR,

Jukka Zitting

[Tako Schotanus]

I agree completely with this "rule", I just want to point out that:

On 7/7/07, David Nuescheler <david.nuescheler@...> wrote:
> Keep also in mind that items can be identified by path, and as much as
> "symlinks" make way more sense for most users than hardlinks in a unix
> filesystem, a path makes a sense for a lot of applications to refer to
> a target node.

this is not so much a preference but more dictated by the inherent
limitations of hard-links which make them a lot less useful than
soft-links (actually, in most real life situations they are useless
because they can't cross drive boundaries).

Personally I never use soft-links for anything "dynamic", like
documents or images in a user's home directory. They are prefect for
pointing to strictly named/structured files/folders like for example
dynamic libraries in /usr/local/lib or something. Even then,
soft-links are most often used for alias purposes (libFoo.so pointing
to libFoo-3.3.so or /bin/java pointing to /opt/java/jdk1.5/bin/java).