Hi Rene,

The reasons for the failure to upgrade smoothly are due the evolution of the project and the imperfections of the upgrade scripts due to historical errors

Yes, there are reasons for this as there are often good reasons for deviating from third normal form, especially in web applications.

The first reason is that it helps make it possible to integrate data from more than one installation and have the ability to restore the relationships even though the integer keys will have to be different. This supports the scenario of 2 companies merging with 2 different sites.

The second and more useful reason is that it makes it possible to do things you can't do with normal table relationships.

For example, I recently implemented a content rating system. Because of using guids I can use the same content rating system to rate articles, products, sites, pages, users, or any other feature where the content has guid identifiers.

Each thing can pass in its own guid and select its ratings, but there is no formal foriegn key relation to the ratings table from any of the tables that store their related ratings there. So many different tables can join to the rating table and get their own ratings.

The same solution will allow me to build a content versioning system, tagging, comments and re-use them across features.

Hope that makes sense to you.

Best,

Joe

I've considered it but not sure that's the best for performance, I think joins are faster on integer columns and it would be a lot of work with additional potential to break things and no value added for actual use.

I don't rule it out for someday, but I'm working full time on my own funding so its not something I plan to put my energy into any time soon. The redundancy doesn't keep me up at night, especially because its possible I would do all that work and then regret it later. :-)

Best,

Joe