I've seen that done, minus the timezone. That was a freaking moment.
I imagine! I wanted a far-fetched example, so encountering something like that in the wild is a bit of a wtf-moment.
Codd did not say 'eliminate every repeating group', as that would imply that we cannot even store the day number '12'. It would repeat for each month, after all. Putting the day-numbers in a separate table and linking to them using a Guid would be an option, but also a bit insane.
The 'worst' modeling decision that I remember are storing everything as a varchar, including an array of bits; actually stored as a "11101010001100"-string. When I asked who wrote it (same tone as usual), my boss-for-the-moment responded saying it was an optimization
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
Bit array as varchar scores quite high on the list of wtf moments
The really stupid part of storing time in six different fields is that they are all just different representations of the same thing (time) and you can calculate one from another.
If there wasn't a date type available I'd simply store seconds in a number field, which coincidentally is what happens behind the doors in a database.
Since this is an existing application presumably with multiple international clients presumably you will already be familar with dealing with issues about how the data will be used and how it is viewed. That will impact some of the design.
I would expect that you would need to use a template which defines addressing schemes. That would be a dynamic (loaded from somewhere) part of the application to define layout for display and printing.
The following is interesting read in terms of possible variations.
As I'm a programmer in Heart and Soul I was hoping something upon a solution similar to object inheritance where I can modify a base table into a new table , but maybe I'm way far of the planet earth.
I'm considering all your answers and try to figure out a neat solution. At this moment I'm thinking about a common table (where data resides that belongs to all variants) and a "varianttype-key-value-type" (dutchAddress-roomnumber-34-int) table in which I store differences.
I'd say that it depends.
It's often a balance between complex queries vs. performance. You might end up with extremely wide tables with a lot of null values where you will need many indexes instead of having one large index in the "HUMAN" table and several small optimized indexes for the "Inherited" tables.
So it is a decision that can't be generalized, but rather one you need to make depending on the situation.