Votre avis sur ma Bdd

Ben44
PHP Laravel

Bonsoir,

Je suis en train d'apprendre Laravel 5.2 histoire de m'obliger à m'organiser en utilisant le MVC.

J'en suis au stade préalable de la structure de ma BDD, je le lis assez peu mais je pense que c'est très important qu'elle soit bien fabriquée.

Pourriez-vous regarder cette dernière et me dire si au delà des relations, elle vous parrait cohérente ? Mon application servira à des particuliers d'enregistrer leur patrimoine et revenus.

Laravel SD

Par ailleurs, au niveau des relations, j'ai des doutes sur le fonctionnement. J'ai fait des essais, n'en tenez pas vraiment compte.

Exemple : Table Type : le nom permet de détermine si un tel, une adresse ou un mail est Privé, professionnel, secondaire. Est-ce que je dois me dire qu'un type est associé à une adresse donc c'est une relation HasOne ? ou bien qu'un type est associé à plusieurs lignes de la table adresse donc Hasmany ?

Bref, merci d'avance :-) !

4 réponses

Lartak

Bonsoir.
Le lien, ce ne serait pas plutôt ça ?

Est-ce que je dois me dire qu'un type est associé à une adresse donc c'est une relation HasOne ?

Non, les relations hasOne, signifie qu'un enregistrement d'une table, ne correspond qu'à une seul enregistrement d'une autre table.
Pour faire simple, un exemple :

  • Un utilisateur n'à qu'un profil et ce seul profil n'appartient qu'à un seul utilisateur : 1↔1.
Ben44
Auteur

Ah yes, le lien est bien celui que tu as mis, désolé ^^. J'essayerai de modifier les relations demain. Que penses-tu de la structure sans les liens ?

Ben44
Auteur

Bonsoir, je viens de revoir l'ensemble des liens de ma BDD. N'hésitez pas à donner votre avis, ça m'intéresse beaucoup avant de me lancer dans le code :-)

Je suis assez étonné d'utiliser que HasMany et BelongsTo.. mais je pense que ce sont les plus courantes. Je pense que je dois également revoir les noms de mes tables sans majuscule ?

Enfin, si je fais un lien supplémentaire entre ma bdd patrimoine et revenus, je pourrais utiliser HasManyThrough pour optimiser le tout lorsqu'un revenu est lié à un bien immobilier par exemple ?

Bonne soirée et encore merci.

julienb

Salut, si je comprends bien tu envisages qu'un utilisateur puisse avoir plusieurs téléphones et plusieurs emails. Dans ce cas, ne serait-il pas plus simple de faire 3 attributs emails et 3 attributs téléphone dans ta table Utilisateurs (ou 2 ou 4...) en obligeant ton utilisateur à remplir au moins un de chaque, c'est à dire avoir un mail et un téléphone non null et le reste en null.

Pour les tables Regimes et Regime_Utilisateur, ça me paraît être plus approprié de simplifier en une seule table Regime_Utilisateur en ajoutant l'attribut nom dedans. Si tu avais des propriétés spéciales à chaque régime à mettre, ça m'aurait parut logique de séparer Regimes et Regimes_Utilisateur mais pour l'instant ce n'est pas le cas dans tes tables.

Même chose pour Foyers et Familles, si tu n'as pas de données à mettre dans la table familles, pourquoi ne pas rajouter un attribut type dans la table Foyers ?

Et même chose pour CSP, si tu n'as pas de données spéciales à chaque CSP à rajouter dans ta table CSP, pourquoi ne pas mettre un attribut Nom_CSP dans ta table Professions?