Geek Answers Handbook

Address Book Database Design: denormalize?

I am developing a contact manager / address book application, but I can’t design the database design.

In my current setup, I have a Contact that has Addresses, Phonenumbers, Email and Organizations. All contact properties are currently separate tables with fk in the contact table. Needless to say, a contact can have any number of these properties.

Now that I want to read contacts in the application, I join all of these tables. Since filters, callbacks, sorting, etc. are not performed in linked tables, isn’t it better to simply or simply save the linked fields as json-encoded lists according to the direct properties of the contact table?

For example, instead of contacting fk in a phonenumber name table with 3 entries, just encode all the numbers and save them in the contact table field?

Any ideas really appreciated! (fyi I am using Django, although this does not really matter)

+6
sql django-models database-design denormalization
source share
3 answers

Can you guarantee that your application will never grow to use these other features? Do you really want to paint yourself in a corner so that you cannot easily support all this later?

As a rule, denormalization occurs only for reasons of preliminary work. And then a copy of the normalized data is still saved for live work, and the denormalized data is used for offline processing, where a static snapshot is in order.

Get used to writing unions. The way SQL works. To do this does not mean that something is wrong.

+6
source share

I know that I'm too late, but for those who have the same problem.

IMO, in this case, metadata modeling is the way to go. http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map

0
source share

It looks like you are proposing to take the data that is currently modeled as five SQL tables and convert it to a common multi-valued type (does your SQL product have good support for this?) The only way I can see this would be " denormalization "if you propose to violate 1NF , at this point you can also abandon SQL as a data warehouse, because your data will no longer be relative! Otherwise, your data will still be normalized, but you will lose the ability to query your attributes using SQL (unless your SQL product has extensions to query for attributes with multiple values). The decisive factor is: do I need to query these attributes using SQL?

0
source share

More articles:


All Articles