Some time ago we found severe normalizations issues with Microsoft's PetShop implementation (which by the way were fixed in the 3.0 version).
Now we were planning to build a PocketPC front end for the ASP.NET TimeTracker Starter Kit, using the new SQL Server CE support/Compact Framework Windows Forms generator in DeKlarit 3.0.
When we reverse-engineered the database, we found normalization problems again. They have a Projects table, similar to:
Projects:
ProjectId (Primary Key)
Name
(... more fields )
And a Categories table:
Categories:
CategoryId (Primary Key)
ProjectId
Name
(... more fields )
Then they have a table to store the time tracking entries, and they designed it like:
EntryLog
EntryLogId (Primary Key)
ProjectId
CategoryId
(... more fields )
Of course, as a CategoryId implies a ProjectId, the ProjectId field should not be in the EntryLog table.
Two thoughts:
- Microsoft cannot let this kind of mistakes see the light. Please find someone that attended to a DB Modeling 101 to review your database designs.
- When we explain the database-normalization features in DeKlarit we always say that normalizing a data model is easy for simple applications but very hard for complex ones... This is a 6-table application!! So I think we'll use this to show how sometimes even professional developers can't do it right in very simple models.