Conception de base de données Multiples “informations de Contact” pour les différents tableaux

J'ai une base de données avec des tables "personne", "société", "boutique", etc. Beaucoup de ces tables doivent avoir des "informations de contact". La possibilité de concevoir cela a été demandé dans Conception de base de données - à l'instar des Informations de Contact pour plusieurs entités
Maintenant, dans ma base de données je laisse une possibilité d'avoir plusieurs adresses, plusieurs téléphones et plusieurs e-mails à chaque les données de contact des. C'est mon schéma de base de données:

Donc, je fais une table intermédiaire "contact" comme la manière la plus simple de lier une "informations de contact" à chaque table.

Ma question: est-ce une bonne pratique de le faire et d'avoir un tableau avec une seule ligne?

Une seule Ligne ou une seule Colonne?

InformationsquelleAutor nb.ag | 2013-10-28

C'est comment je pourrais la conception de votre base de données:

address_types
    id              unsigned int(P)
    description     varchar(10) //Mailing, Physical, etc.

addresses
    id              unsigned int(P)
    line1           varchar(50) //123 Main Street, etc.
    line2           varchar(50) //Default NULL
    city_id         unsigned int(F cities.id)
    zip             varchar(6) //12345, A1A 1A1, etc.
    zip4            char(4) //Default NULL
    lat             decimal(10,8) //13.12345678, etc.
    lon             decimal(11,8) //110.12345678, etc.

cities
    id              unsigned int(P)
    state_id        unsigned int(F states.id)
    name            varchar(50) //Omaha, Detroit, Tampa, etc.

companies
    id              unsigned int(P)
    name            varchar(75) //IBM, Microsoft, RedHat, etc.
    ...

companies_addresses
    id                  unsigned int(P)
    company_id          unsigned int(F companies.id)
    address_id          unsigned int(F addresses.id)
    address_type_id     unsigned int(F address_types.id)

companies_contacts
    id                  unsigned int(P)
    company_id          unsigned int(F companies.id)
    contact_id          unsigned int(F contacts.id)
    contact_type_id     unsigned int(F contact_types.id)

companies_emails
    id                  unsigned int(P)
    company_id          unsigned int(F companies.id)
    email_id            unsigned int(F emails.id)
    email_type_id       unsigned int(F email_types.id)

contact_types
    id              unsigned int(P)
    description     varchar(10) //Home phone, Mobile phone, FAX, etc.

En Amérique du Nord, les numéros de téléphone ressembler à ceci: CC-AAA-EEE-SSSS-XXXXXXX où CC est le code du pays, l'AAA est le code de zone, EEE, c'est l'échange, SSSS est de la station et de XXXXX est l'extension.

contacts
    id              unsigned int(P)
    country_code    varchar(3)
    area_code       varchar(3)
    exchange        varchar(3)
    station         varchar(4)
    extension       varchar(10) //Default NULL

Voir La norme ISO 3166-1.

countries
    id              char(2) //ca, mx, us, etc.
    iso3            char(3) //can, mex, usa, etc.
    iso_num         char(3)
    name            varchar(44) //Canada, Mexico, United States, etc.

email_types
    id              unsigned int(P)
    description     varchar(10) //Personal, Work, etc.

emails
    id              unsigned int(P)
    address         varchar(255) //[email protected], etc.

shops
    id              unsigned int(P)
    name            varchar(45) //Shop A, Shop B, etc.
    ...

shops_addresses
    id                  unsigned int(P)
    shop_id             unsigned int(F shops.id)
    address_id          unsigned int(F addresses.id)
    address_type_id     unsigned int(F address_types.id)

shops_contacts
    id                  unsigned int(P)
    shop_id             unsigned int(F shops.id)
    contact_id          unsigned int(F contacts.id)
    contact_type_id     unsigned int(F contact_types.id)

shops_emails
    id                      unsigned int(P)
    shop_id                 unsigned int(F shops.id)
    email_id                unsigned int(F emails.id)
    email_type_id           unsigned int(F email_types.id)

Voir ISO 3166-2.

states
    id              unsigned int(P)
    country_id      char(2)(F countries.id)
    code            varchar(2) //AL, NF, NL, etc.
    name            varchar(50) //Alabama, Newfoundland, Nuevo León, etc.

Ok, je vois votre point de vue. Vous proposer la même solution que voici stackoverflow.com/questions/3636061/... (méthode 1). Mais ici, un même inconvénient – "la création d'un lot de tableaux associatifs". Il y a une autre façon de le faire?
Ce n'est pas vraiment un inconvénient, la normalisation est une bonne chose. Du SGBDR sont bons à la jointure des tables tant que vous index choses correctement.
Je sais que c'est 2 ans, mais je me demandais ce que vos pensées sont pour mettre de l' email_type_id sur chacun des XXXX_emails tables plutôt que de le mettre sur le email table, parce que tous les e-mails ont un type. Je suis de la conception de quelque chose de similaire et sont arrivés à la même conception que toi (à l'exception de ne pas briser le numéro de téléphone dans autant de colonnes), sauf que j'allais mettre le email_type_id sur l'e-mail de la table.
deux ans plus tard, j'ai fait la conception d'un peu différemment. Je mettrais le email_type_id dans le emails table comme vous le suggérez, mais je voudrais aussi supprimer le id colonne à partir de la shops_addresses, shops_contacts et shops_emails tables. Je voudrais changer leurs respectifs des clés primaires pour être un composite de shop_id et address_id; shop_id et contact_id; et shop_id et email_id.

InformationsquelleAutor Benny Hill

3

Ma question: est-ce une bonne pratique de le faire et d'avoir un tableau avec une seule ligne?

Pas vraiment. Regarde ton schéma, je dois poser la question : peut un contact vraiment être lié à un nombre arbitraire de personnes ? Si non, vous devez utiliser la "personne" comme parent de la table et de faire les autres tables lien.
- En fait oui, je peux avoir un millier de personnes, les entreprises et les magasins. Si je comprends bien vos conseils, j'ai directement le lien de l'email, le téléphone et l'adresse à tous mes entités (personnes, entreprises, magasins)? Je vais donc avoir quelque chose comme ceci: email -> idemail, mail, idperson, idcompany, idshop Est-il vraiment mieux?
- Non, dans votre cas, vous devriez en fait, l'utilisation de tableaux associatifs comme suggéré par Benny Hill ci-dessous. Il est possible de faire autrement, mais en assurant les données restent cohérentes serait vraiment ennuyeux et pas la peine.
- aussi le lien de pays à l'adresse pas de la ville, il y a peut-être des villes dans différents pays et/ou les états de la province ou de comté qui a le même nom
InformationsquelleAutor AurelienT
2

Personnellement, je n'aime pas vraiment cette méthode parce que nous avons besoin de créer une Entité pour chaque table et beaucoup de tableaux associatifs. Je propose une table pour les informations de contact et un autre pour les adresses.
```
informations
- id INT
- name VARCHAR
- value VARCHAR
- type ENUM(phone, email, url, custom)
- idcompany INT NULL
- idcontact INT NULL
```
Et
```
addresses
- id
- address1
- address2
- district
- postcode
- idcity
- idcompany
- idcontact
```
InformationsquelleAutor Youssef El Montaser

Vous devez vous connecter pour publier un commentaire.