J'ai une base de données avec des tables "Personne", "Société", "Shop", etc. Beaucoup de ces tables doivent avoir des "coordonnées". La possibilité de concevoir cela a été posée dans Conception de la base de données - Coordonnées similaires pour plusieurs Entités
Maintenant, dans ma base de données Donc, 
Ma question: Est-ce une bonne pratique de faire cela et d'avoir une table avec une seule rangée?
3 Réponses :
Ma question: Est-ce une bonne pratique de le faire et d'avoir une table avec une seule rangée?
Pas vraiment. En regardant votre diagramme, je dois demander: un contact peut-il vraiment être associé à un nombre arbitraire de personnes? Sinon, vous devez utiliser la «personne» comme table des parents et rendre les autres tables qui y sont liées.
En fait oui, je peux avoir mille personnes, entreprises et magasins. Si je comprends bien votre conseil, je dois lier directement un courriel, un téléphone et une adresse à toutes mes entités (personnes, entreprises, magasins)? Je vais donc avoir quelque chose comme ceci: Email -> Idemail, Mail, IdPerson, Idencompany, IDshop Est-ce vraiment mieux?
Non, dans votre cas, utilisez en fait des tables associatives comme suggéré par Benny Hill ci-dessous. Il est possible de faire autrement, mais d'assurer les restes de données cohérents serait vraiment ennuyeux et ne valent pas la peine.
également lier le pays à ne pas aller à la ville, car il peut exister des villes dans différents pays et / ou des États / province / comté qui a le même nom
Voici comment concevoir votre base de données:
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 ton point. Vous proposez la même solution que ici Stackoverflow.com/Questtions/3636061/... (méthode 1). Mais ici un même désavantage - "Création de nombreuses tables associatives". Il y a une autre façon de faire cela?
Ce n'est vraiment pas un inconvénient, la normalisation est une bonne chose. Les SGBDM sont bons pour rejoindre des tables aussi longtemps que vous indexez les choses correctement.
Je sais que cela a 2 ans, mais je me demande quelles sont vos pensées pour mettre le email_type_id sur chacun des tables xxxx_emails plutôt que de la mettre sur le Email Table car chaque email aura un type. Je concevons quelque chose de similaire et est venu à un design similaire comme vous (à l'exception de ne pas casser le numéro de téléphone dans autant de colonnes), sauf que j'allais mettre le courrier électronique_type_id sur la table de messagerie.
@ KRRALCO626 - Deux ans plus tard, je concevrais cela légèrement différemment. Je mettrais le e-mail_type_id dans la table EMAILS Comme vous le suggérez, mais je supprimerais également la colonne ID à partir du shops_addresses , shops_contacts et shops_emails tables. Je modifierais leurs clés principales respectives pour être un composite de shop_id et adresse_id ; shop_id et contact_id ; et shop_id et email_id .
Personaly, je n'aime pas vraiment cette méthode parce que nous devons créer une entité pour chaque table et beaucoup de tables associatives. Je propose une table pour des informations de contact et une autre pour les adresses.
addresses - id - address1 - address2 - district - postcode - idcity - idcompany - idcontact
Une seule ligne ou une seule colonne?