Concepts de conception de base de données

Question

Je viens de démarrer un projet et j'ai besoin d'un peu de poussée dans la bonne direction. Voici ma structure de table:

users   departments  sub-departments 
-------  -------   ------- 
id   id    id 
name   name   name 
email 
password 
created 
modified 

posts   photos  profiles 
-------  -------  ------- 
id   thumbnail  id 
content  large   photo_id 
created  created  user_id 
user_id  profile_id department_id 
profile_id id   sub-department_id 

La table de profils a environ 5 autres champs qui sont sans conséquence. Si l'un de ces éléments semble un peu éteint, c'est probablement le cas.

users have one department 
users have one sub-department 
users have many posts 
users have one photo 
users have one profile 

Ce que je « voulais » faire était de créer mes tableaux, je nécessaires et les mettre tous ensemble sous la table de profil à l'aide des clés étrangères. Un extrait CakePHP de mon modèle de profil ressemble:

var $belongsTo = array('User', 'Department', 'Sub_Department', 'Photo') 
var $hasMany = array('Comment'); 

Si maintenant vous pensez « WTF est cette merde? » .. Je suis là avec vous. Cette association travaille dans l'échafaudage. Mais je ne veux pas avoir de problèmes quand je commence vraiment à brancher ma logique.

Je suis encore nouveau à ERD et CakePHP. Dois-je déclarer tout ce qui appartient à l'utilisateur et sous ma requête ProfilesController à partir de là comme $ this-> Profile-> User-> find ('all', array ('contain' => ....)); ?

Je suis un peu perdu à ce stade. Toute aide serait appréciée. Comment appliqueriez-vous cela?

Answer 1

Vous avez dit:

• utilisateurs ont un département
• les utilisateurs ont un sous-département
• utilisateurs ont de nombreux messages
• utilisateurs ont une photo
• utilisateurs ont un profil

Terminologie amusante ... les utilisateurs travaillent dans un département d, en fait, travailler dans un sous-département. Puisque, probablement, un sous-département fait partie d'un seul département, vous n'avez pas besoin d'enregistrer le département et le sous-département dans la table de profil. En fait, si vous enregistrez les deux, vous avez une contrainte complexe à appliquer. Donc, à moins qu'il y ait quelque chose que vous ne nous avez pas dit, le profil du ministère n'est pas nécessaire. Cependant, je note qu'il n'y a pas de référence croisée entre les départements et les sous-départements, donc un seul sous-département peut apparemment être associé à plusieurs départements - rien n'empêche le sous-département numéro 1 d'être associé à une personne travaille dans le département 1 et une autre personne travaille dans le département 2. C'est inhabituel - pas nécessairement mauvais, mais pas la façon dont la plupart des organisations travaillent. Il est tentant de demander "si les utilisateurs n'ont qu'une seule photo à la fois et n'ont qu'un seul profil, pourquoi les séparer de la table des utilisateurs?", Mais il y a des raisons de les séparer.

L'un des points clés dans les tables de modélisation est d'identifier les clés primaires naturelles. Les colonnes d'ID ne comptent pas - ou peuvent être comptées, mais vous devez déterminer quelles autres combinaisons de colonnes doivent être uniques. Par exemple, dans la table de profil, bien qu'il existe un ID de profil, l'ID utilisateur doit être unique selon les règles que vous avez indiquées, de sorte que l'ID de profil est superflu - une perte d'espace, en fait (deux fois, une fois colonne de données, et une fois pour l'index qui sera créé dessus). Maintenant, si vous avez décidé qu'un utilisateur peut avoir plusieurs profils au fil du temps et que les profils ont une période valide ou quelque chose de similaire, la colonne ID de profil a du sens, mais le dernier point n'est plus valide.

Dans le tableau des messages, pourquoi enregistrez-vous à la fois l'ID utilisateur et l'ID du profil? Encore une fois, cela vous donne une contrainte complexe à appliquer sans bénéfice évident. L'identifiant de profil est suffisant. à partir de cela, vous pouvez trouver l'utilisateur.

Vous dites qu'un utilisateur a une photo, mais ce n'est pas ce que vous avez modélisé. Vous avez modélisé 'chaque profil a une photo, et une photo n'est utilisée que par un profil'. De même, en fait, vous n'avez pas modélisé «les utilisateurs ont un sous-département»; vous avez modélisé les «profils ont un sous-département». Il est fort probable que ce soit un problème avec les définitions bâclées, mais vous devez faire attention car les définitions bâclées conduisent à des bases de données bâclées, et les bases de données bâclées mènent à des réponses incorrectes et à de mauvaises performances.

Résolvez ces problèmes et vous serez très loin d'avoir un design plus fonctionnel. Cependant, je ne suis pas sûr d'avoir découvert toutes les anomalies qui existent dans ce schéma.

Answer 2

Vous pouvez tester les concepts de conception de base de données CakePHP sur CakeApp.com.

Answer 3

J'ai fourni un exemple de schéma/diagramme que vous pouvez consulter.

Quelques points à noter. Le modèle Post (table posts) a un champ slug. Utilisez le comportement Sluggable pour gérer la création de limaces ici pour vous.

Le modèle de département (table departments) a un champ nommé department_id, ce devrait être être parent_id mais l'outil Builder renvoie des erreurs à ce sujet. Changez-le comme vous en avez besoin. Les champs lft, rght et parent_id correspondent au comportement Tree. L'utilisation du comportement de l'arborescence sur le modèle de département permettra aux départements d'appartenir arbitrairement aux départements 'parents'. Cela vous évite d'avoir besoin d'une table sub_departments, car un sous-département est en réalité un département avec un parent_id défini sur l'identifiant d'un autre département.

Un profil attaché à l'utilisateur, et Photos habtm profil de sorte que vous pouvez avoir un nombre illimité de photos attachées à un utilisateur. J'aime garder mon modèle d'utilisateur maigre, avec seulement ce qui est nécessaire pour le composant Auth. Le modèle de profil est où je garderais le prénom, le nom de famille, l'âge, la ville, etc.

Utilisez un comportement de téléchargement (MeioUpload) sur le modèle photo pour gérer les téléchargements automatiquement.

Cela devrait être un bon point de départ pour réviser votre conception.

http://cakeapp.com/sqldesigners/sql/centro

Mot de passe: centro