I have a User
with one or more saved Documents
, but each Document
has specific attributes in Brasil for example we have:
-
RG(General Register) have the following attributes:
-
A number
-
Expedition Date
-
Emission Org
-
-
CPF(Like a Social Security Number) have the following attributes:
- A number
-
CNPJ(Like a National Registry of Legal Entities) have the following attributes:
-
A Name (of a company)
-
A Number
-
-
CNH(Driver's License) have the following attributes:
-
A Name (Of a person)
-
A Number
-
Expedition Date
-
Valid Date
-
Then I designed the following model:
FK Document Type
will control what attributes of table will be null, for example ifFK Document Type
appoint to CPF
the Valid Date
attribute will not be used.
That's the correclty way to design a system with more than one type of document? I think that is not good make one table to each document type.
Best Answer
Instead of storing number of repeating DocType
names
you store theids
of the DocType descriptions from the reference table. This is a common practice callednormalization
.The sparsed table with nullable attributes is good enough while the number of possible attributes isn't too big. Sometimes it's more efficient to store all the attributes in the aux table
docid -- attrname -- value
containing only not-null values and join them whenever you need.The only difference is that by join you'll get not the single row but the table like that:
This table can be easily parsed on the app side.
An advantage of that approach is that you can add as many attributes as you want. Attributes names can be separated into the reference table for the normalization reasons.
The main disadvantage is that all attributes should be converted into the same type (VARCHAR() for example) and some functionality can be lost - like datetime arithmetics and/or timezone conversions.
Having a number of tables for each type of document isn't a good design.
There is no universal recipe and you have to decide what approach is suitable for you. Sometimes single table with hardcoded list of attributes is preferrable. Sometimes an expandable table of EAVs (entity-attribute-value) fits better.