Hi Don,

>>Maybe its best to forget this whole concept and revert to intelligent keys.
>
>I have been coming to the same conclusion. It seemed like a nice idea to begin with but as they say ... the devil is in the details. If you haven't already figured it out ... I like simple. At first it was simple ... but no longer.

>>If you don't have/want a commercial framework, you should be writing your own >set of classes, tools and userinterfaces.
>
>Which is exactly what I am doing and is why I am searching for the best data structure on which to base my classes. Not using codes at all is as simple as it gets and I am surely attracted to that concept. However, that just seems to go against all my years of development instincts. On the other hand it seems tha only systems with huge amounts of data would be noticeably affected by this concept. I think I am going to try it.

I'm not sure why you think having huge amounts of data would hurt this concept. Could you explain ? I would think that just when having to deal with huge amounts of data, one should minimize joins. And as noted, using surrogate keys in general increases the need of having joins.

Sure, when using surrogate keys, you could use 32 bit integers which take less space as a foreign key oposed to the avarage intelligent key, but having as much as intelligent data in a table could save you headaches when having performance problems.

As I said before. Intelligent keys and surrogate keys have different properties. Sometimes its better to use surrogates, sometimes you need to revert to intelligent.

Walter,