Que ce soit pour séparer les données afin de séparer PostgreSQL Table

Question

Je crée une application avec une interface WPF et une base de données PostgreSQL. Les données incluent les adresses des patients et les adresses des fournisseurs. Il y a en moyenne environ 3 contacts par adresse postale listés. J'estime 10 000 à 15 000 enregistrements de contacts par base de données. Lors de la conception de la structure de base de données, il m'est apparu qu'au lieu de stocker des adresses postales dans une seule table "contacts", une table pouvait stocker des noms et d'autres données individuelles, avec une deuxième table contenant des adresses. Je pourrais alors créer une relation entre les tables, pour faire correspondre les adresses avec les contacts. J'ai une bonne idée de la façon dont je peux facilement organiser des situations telles que le changement de l'adresse d'un seul contact, où les autres contacts restent à la même adresse.

La question est: ça vaut le coup? Puis-je espérer économiser beaucoup sur la taille de stockage? Cela aura-t-il un impact sur la vitesse des requêtes adversley? Que diriez-vous si j'utilisais autre chose que PostgreSQL?

Answer 1

Sauf si vous pensez qu'un grand nombre de vos utilisateurs partageront des adresses et qu'ils changeront souvent, je ne vois pas la nécessité de normaliser la partie d'adresse. Dans les différents endroits où j'ai travaillé et voir les tables des utilisateurs, parfois, parfois, ça n'a jamais vraiment semblé causer beaucoup de problèmes d'une manière ou d'une autre. En termes de performances, avec seulement 10-15k enregistrements et des index appropriés, je ne peux pas imaginer que vous remarquiez trop de différence d'une façon ou d'une autre sur le matériel moderne (bien que techniquement la table séparée devrait être plus lente).

Answer 2

Je suggère fortement de normaliser cela. Vous ne savez jamais quel genre de problème vous rencontrerez. LedgerSMB a un schéma entité/utilisateur/contact/emplacement relativement décent qui crée un environnement très flexible. Vous pouvez le voir ici (à partir de la ligne 363):

http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?revision=3042&view=markup

Answer 3

Je suis d'accord avec Joshua. Une fois correctement configuré (normalisé), il est très facile de gérer les modifications de votre application à l'avenir.