Discussion :

[Sephiroth Lune]

Bonjour à tous

Je suis dans le cas ou j'ai un objet qui stocke des données, voici son architecture (réduite pour la compréhension) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
POOL
	- address
	- name
	- hashrate
	- efficiency
	- estimated time
	- taxe fee
 
	SERVERS
		- address
		- port
 
	SHARES
		- shares this round
		- share rate
		- estimated
 
	WORKERS
		- count
 
	BLOCKS
		- last
		- current block height in blockchain
		- estimated
		- progress to find next block
		- time since last

Je veux stocker ça en base, donc je créé des entités POOL, SERVERS, SHARES, WORKERS, BLOCKS.
Autant entre POOL et SERVERS je fais une OneToMany, aucun problème de structure de base.
Mais entre POOL et SHARES, POOL et WORKERS, POOL et BLOCKS, j'ai des OneToOne qui m'embête. Cette relation va créer une table pour POOL (ok), mais aussi une pour WORKERS, SHARES et BLOCKS. J'aimerai ne pas avoir ces tables, et mettre les données directement dans la table POOL. Comme c'est une relation OneToOne avec forcément des données des deux côtés (relation 1,1), créer des tables est inutile et compléxifie les requêtes.

Par contre je ne sais pas comment faire dans Symfony2 et Doctrine2 pour avoir un modèle objet comme celui que je veux, sans pour autant multiplier les tables.

Est-ce que quelqu'un a une idée ?

[Nico_F]

Hello,

Arrête moi si je me trompe : ce que tu veux c'est garder le modèle objet que tu as écrit dans ton post, et coté BDD, migrer les attributs de chacune des relations OneToOne vers la table POOL.

Je pense que c'est une mauvaise idée pour plein de raisons.

Voilà ce qu'il va se passer dans le meilleur des cas : tu vas avoir trois ou quatre entités qui devront mappés sur la même table et qui auront chacun leurs attributs. Tu auras donc un objet POOL avec ses attributs, un objet SHARE avec ses attributs etc. mappés sur la table POOL qui regroupe tous les attributs. À aucun moment tu ne peux avoir un objet complet puisque tu ne pourras plus faire de relations (coté BDD il n'y a plus qu'une table, et il n'y a pas de relation entre Pool et Pool ... et il n'y a aucune raison qu'il y en ait une). Admettons même qu'à aucun moment tu ne veuilles avoir ton objet complet parce que tu rempliras ces attributs au fur et à mesure en plusieurs étapes par objet : là encore problème : création d'un POOL avec ses attributs : ok, édition d'un SHARE qui correspond au POOL que l'on vient de créer : ça risque d'effacer les données que tu as entré dans POOL puisque ces données n'existeront plus dans ton objet que tu voudras persister.

La structure objet peut être différente de la structure de BDD dans certains cas, s'il s'agit de rajouter quelques attributs non mappés pour simplifier la manipulation de l'objet. Mais en dehors de ça, j'aurais tendance à te déconseiller de faire de telles choses.

Dans un cas classique : une entité => une table.
Dans un cas d'héritage : plusieurs entités => une table.

Là il ne s'agit pas du tout d'héritage, je pense que ton modèle objet est viable, et que le modèle BDD avec plusieurs tables et des relations OneToOne l'est aussi. Dans de nombreux cas, lorsqu'une table possède beaucoup de champs, il est préférable de la scinder en plusieurs tables, pour la compréhension, la logique, et même l'optimisation du code. Si tu n'as pas besoin des liaisons tu peux quand même manipuler chacun de tes objets de manière plus légère qu'un seul objet avec tous les attributs.

La "complexité" (très relative dans ce cas) des requêtes n'est pas à tenir en compte lorsqu'on définit le modèle.

[Sephiroth Lune]

Tu as très bien compris ce que je veux faire.

J'ai compris ton explication, mais je ne suis pas trop d'accord avec. Si on parle uniquement en terme de possibilités offertes par SF2 / Doctrine, alors je suis ok avec toi, il faut garder le principe des entités séparées et avoir plusieurs tables avec des OneToOne.

Mais si j'avais eu à faire ce modèle objet / base de données hors SF2 / Doctrine, je n'aurai pas fait plusieurs tables, et j'aurai rempli mes objets en une seule fois via une seule requête. C'est ce que je cherche à faire, automatiquement, parceque je peux très bien faire ça via un repository perso.

Je ne pense pas qu'il existe de solution technique "automatique" pour ce que je veux faire. Je vais donc faire avec un repository perso

Concernant la complexité des requêtes, qui ne doivent pas changer le modèle, là par contre je pense l'inverse. Je ne dis pas qu'on doit faire un modèle en fonction des requêtes, bien sur. Mais il arrive souvent que le modèle soit changé parceque les requêtes sont trop complexe, mettent trop de temps, etc. Le cas tout con d'une table "repertoire", avec un champ "parent" qui stocke l'id du répertoire parent : on peut ajouterun champ "path" qui indique tous les ids des parents, dans l'ordre chronologique, pour récupérer bien plus facilement les parents qu'en faisant une requête pour avoir le répertoire voulu, une autre pour avoir le parent, encore une pour le parent du parent, etc. Même avec des liaisons ça se complique quand même.

Merci d'avoir pris le temps de répondre, et d'avoir été aussi complet