Rusty Wright escribió: > I would go the other way; I'd add a unique constraint to L10NCODE and > leave the ID field in as the primary key.
However, it can't be done right now with DdlUtils (see Thomas's first reply) and, for me, using DdlUtils is a must. > I think it's a bad idea to > use anything in your data as a primary key because I worry that you can > never be absolutely sure that you won't need to change that data. To > me, the only safe primary key is a synthetic primary key, only because > it's probably safer in the long run. Well, in this case, the L10NCODE is certainly the value that uniquely sets apart any two records in L10N table. It will never be two records with the same value by design. Besides, for efficiency reasons, those tables in which references exist to L10N records have an L10NCODE field instead of something like a "L10N-ID" field (L10NCODE has a meaning for humans, L10N-ID not, which would require an additional query to L10N). Anyway, I clearly see your point, and I agree that, in general, the synthetic key (BTW, weird spelling of "sintetic" the one I did before, sorry) is a better and safer choice. Thanks, Ricardo
