Discussion :

[ForgetTheNorm]

Bonjour à tous
Je suis confronté à un problème de conception. En effet, je souhaite relier des lignes de tables différentes entre elles dans la même base de données.
Pour cela, j'ai besoin d'une table, qui associe à 2 couples (table,identifiant) une unique valeur. La table générée pourra avoir plusieurs millions de lignes.
Par exemple, elle pourrait comprendre cette ligne :
("table1_name", 12, "table2_name", 600, "x")
12 étant la clé de la table1, 600 l'identifiant de la table2, et "x" la valeur qui est associée.

Je suis à la recherche de la meilleure clé (en termes de performances). Dois-je :
- Utiliser le quadruplet (table1.name, table1.id, table2.name, table2.id) comme clé, vu que mon identifiant dépend de ce quadrulet,
- Ajouter une clé plus traditionnelle, avec un identifiant numérique par exemple

Les requêtes qui suivront sur cette table seront la récupération de la valeur associée aux 4 valeurs précédentes.

Quelle est la meilleure solution d'après vous ?

Pierre

[dehorter olivier]

Regardes ce cours, normalement la réponse y est

[CinePhil]

On peut connaître l'origine de ce besoin bizarre ?

C'est de la réingénierie de base de données ?
De l'archivage de données ?

[SQLpro]

Bonjour à tous
Je suis confronté à un problème de conception. En effet, je souhaite relier des lignes de tables différentes entre elles dans la même base de données.
Pour cela, j'ai besoin d'une table, qui associe à 2 couples (table,identifiant) une unique valeur. La table générée pourra avoir plusieurs millions de lignes.
Par exemple, elle pourrait comprendre cette ligne :
("table1_name", 12, "table2_name", 600, "x")
12 étant la clé de la table1, 600 l'identifiant de la table2, et "x" la valeur qui est associée.

Je suis à la recherche de la meilleure clé (en termes de performances). Dois-je :
- Utiliser le quadruplet (table1.name, table1.id, table2.name, table2.id) comme clé, vu que mon identifiant dépend de ce quadrulet,
- Ajouter une clé plus traditionnelle, avec un identifiant numérique par exemple

Les requêtes qui suivront sur cette table seront la récupération de la valeur associée aux 4 valeurs précédentes.

Quelle est la meilleure solution d'après vous ?

Pierre

Encore un qui va nous réinventer la roue avec une seule table contenant toutes les données de son application et puis qui va venir pleurer lorsque effectivement les temps de réponse vont vite devenir catastrophiques....

Mon collègue Stéphane Faroult, montre assez bien les conséquences dramatiques de ce genre de modèle parfaitement débile...
Il y a quelques années, un de ses clients lui avait demandé un cours sur l'optimisation des SGBDR... Il a réfléchis et a fait une vidé qui s'appelle "comment obtenir les performances les plus pourries" histoire que les développeurs se reconnaissent rapidement dans leurs bêtises !



A voir donc : [ame="http://www.youtube.com/watch?v=40Lnoyv-sXg&feature=related"]SQL Best Practices in less than 20 minutes 1/3 - YouTube[/ame]

A +

[CinePhil]

Excellent !
J'adore les petits dessins illustratifs et le sérieux avec lequel il présente ça !

Au passage, si c'est un francophone, chapeau pour l'expression orale en anglais !

[punkoff]

Vraiment bien présenté ce truc

[SQLpro]

Stéphane à décidé de ne plus rien faire en français (livre comme vidéo), car il trouve les informaticiens français tellement nuls et bornés qu'il trouve que ça ne vaut pas la peine de s'y investir...

Et quand je lis de telles bêtises, je me dit qu'il n'a vraiment par tort !

A +

[ForgetTheNorm]

Bonjour à tous et merci pour vos commentaires.

Je vais en décrire un peu plus l'application finale, en tentant de simplifier.
La base de données comporte 2 "gros" types de tables :
- les utilisateurs (que ce soient des utilisateurs simples ou des groupes d'utilisateurs). Il y a plusieurs types d'utilisateurs, dans plusieurs tables, car ils n'ont pas les mêmes applications.
- les objets auxquels les utilisateurs vont accéder (même principe : ça peut être un objet ou un groupe d'objets). Idem, il y a plusieurs types d'objets.

On pourrait assimiler cette base de données à un système de fichiers. Prenons le FS Linux, qui décrit :
- des utilisateurs, et des groupes d'utilisateurs,
- des fichiers, et des répertoires.

L'idée de la table "centrale" est de relier d'un côté un ou plusieurs utilisateurs, et de l'autre un ou plusieurs fichiers, en leur donnant des "droits" : lecture et/ou écriture. L'objectif est pouvoir :
- à partir d'un utilisateur, avoir les objets qu'il peut lire ou écrire
- à partir d'un objet, avoir les utilisateurs qui peuvent le lire ou l'écrire.

L'histoire du couple (nom de la table / id) est un héritage fort de Ruby on Rails, qui possède ce mécanisme de base pour décrire dans une même table des transactions de tables différentes. On a ainsi 2 couples (nom de la table / id), l'un pour les utilisateurs, l'autre pour les objets. La 5eme colonne représente le droit lecture/écriture/aucun des deux.

Avant d'agir, je me pose des questions si c'est la bonne manière de faire, ou je me plante complètement...

Pierre

[SQLpro]

L'idiotie est d'utiliser un littéral comme clef. Cela divise les perf de manière catastrophique.

Remplacez ces littéraux par des clefs numériques de type INT et n'oubliez pas l'intégrité référentielle et les contraintes d'unicité.

Si vous voulez un peu plus d'aide, postez vos tables sous forme de script SQL DDL (CREATE TABLE... CREATE INDEX...)

A +

[CinePhil]

Je crois qu'il faut carrément revoir la conception de la BDD !

La base de données comporte 2 "gros" types de tables :
- les utilisateurs (que ce soient des utilisateurs simples ou des groupes d'utilisateurs). Il y a plusieurs types d'utilisateurs, dans plusieurs tables, car ils n'ont pas les mêmes applications.

Déjà là, ça commence mal !
Un utilisateur est un concept en soi, donc une entité type dans le modèle conceptuel de données (MCD) merisien ou une classe dans le diagramme de classe UML.
Application en est semble t-il une autre.

- les objets auxquels les utilisateurs vont accéder (même principe : ça peut être un objet ou un groupe d'objets). Idem, il y a plusieurs types d'objets.

Idem ci-dessus un objet est un concept => entité type / classe.
Dans cette phrase, on voit par contre qu'il y a une association entre utilisateur et objet, ce qui n'était pas évident entre utilisateur et application précédemment.

On peut écrire la règle de gestion suivante :
Un utilisateur peut accéder à plusieurs objets et un objet peut être accédé par plusieurs utilisateurs.

Ce qui donne le MCD suivant :
utilisateur -0,n----accéder----0,n- objet

Ce qui donnera les tables suivantes :
utilisateur (usr_id, usr_nom, usr_prenom...)
objet (obj_id, obj_nom...)
usr_acceder_obj (uao_id_utilisateur, uao_id_objet...)

On pourrait assimiler cette base de données à un système de fichiers. Prenons le FS Linux, qui décrit :
- des utilisateurs, et des groupes d'utilisateurs,
- des fichiers, et des répertoires.

S'il faut gérer les droits d'accès aux objets via des groupes, c'est le même principe que ci-dessus.

L'idée de la table "centrale" est de relier d'un côté un ou plusieurs utilisateurs, et de l'autre un ou plusieurs fichiers, en leur donnant des "droits" : lecture et/ou écriture

Oublie cette "table centrale" qui sera une usine à gaz ingérable !

L'objectif est pouvoir :
- à partir d'un utilisateur, avoir les objets qu'il peut lire ou écrire
- à partir d'un objet, avoir les utilisateurs qui peuvent le lire ou l'écrire.

Aucun problème avec un modèle de données solide et les requêtes adéquates, pas très compliquées d'ailleurs !

L'histoire du couple (nom de la table / id) est un héritage fort de Ruby on Rails, qui possède ce mécanisme de base pour décrire dans une même table des transactions de tables différentes. On a ainsi 2 couples (nom de la table / id), l'un pour les utilisateurs, l'autre pour les objets. La 5eme colonne représente le droit lecture/écriture/aucun des deux.

Encore un machin fait pour développer des logiciels mais qui se moque de l'étape de conception de la BDD !
Sans doute muni d'une espèce de saloperie d'ORM qui plombe les performances dès que le volume de données devient conséquent !

Avant d'agir, je me pose des questions si c'est la bonne manière de faire, ou je me plante complètement...

Est-il besoin que je réponde à cette question ?

Reprends ton projet à zéro en commençant par écrire des règles de gestion claires comme je l'ai fait plus haut puis dessine un bon MCD, de préférence avec un logiciel de modélisation tel que Power Amc ou Open Modelsphere par exemple puis crée ta BDD.

Ensuite, tu passer à la création des vues qui seront nécessaires pour ton programme et le programme ne devra s'adresser qu'à ces vues.

Si tu as des problèmes pour le MCD, tu peux le poster dans le forum Schéma. Il y a d'ailleurs déjà eu des sujets là-dessus.

Bon courage !

[ForgetTheNorm]

Je crois qu'il faut carrément revoir la conception de la BDD !
Déjà là, ça commence mal !

Justement, c'est l'objectif que je ne souhaite pas atteindre. La BD actuelle comporte plus 250 tables...

Un utilisateur est un concept en soi, donc une entité type dans le modèle conceptuel de données (MCD) merisien ou une classe dans le diagramme de classe UML.
Application en est semble t-il une autre.

On est bien d'accord, les utilisateurs sont dans une unique table, ce sont les groupes d'utilisateurs qui peuvent être dans des tables différentes, car ils ne possèdent pas du tout les même champs.

Idem ci-dessus un objet est un concept => entité type / classe.
Dans cette phrase, on voit par contre qu'il y a une association entre utilisateur et objet, ce qui n'était pas évident entre utilisateur et application précédemment.

On peut écrire la règle de gestion suivante :
Un utilisateur peut accéder à plusieurs objets et un objet peut être accédé par plusieurs utilisateurs.

Ce qui donne le MCD suivant :
utilisateur -0,n----accéder----0,n- objet

Ce qui donnera les tables suivantes :
utilisateur (usr_id, usr_nom, usr_prenom...)
objet (obj_id, obj_nom...)
usr_acceder_obj (uao_id_utilisateur, uao_id_objet...)
S'il faut gérer les droits d'accès aux objets via des groupes, c'est le même principe que ci-dessus.

Voilà le problème que je vois : il n'y a pas un unique type d'objet, puisqu'ils sont répartis dans plusieurs tables. C'est en fait ce majeur problème que je dois régler : éviter de créer n tables pour mes n types d'objets.

Encore un machin fait pour développer des logiciels mais qui se moque de l'étape de conception de la BDD !
Sans doute muni d'une espèce de saloperie d'ORM qui plombe les performances dès que le volume de données devient conséquent !

Les outils RoR ont bien pour but d'aider les utilisateurs à créer "facilement et sans trop réfléchir" des BD. Cependant, lorsqu'on cherche à comprendre les mécanismes de création des tables, on s'aperçoit vite fait que ce n'est pas optimal.
Le système fonctionne bien pour de petites BD ; cependant, nous récupérons aujourd'hui des erreurs de conception de BD faites il y a plusieurs années.

Reprends ton projet à zéro en commençant par écrire des règles de gestion claires comme je l'ai fait plus haut puis dessine un bon MCD, de préférence avec un logiciel de modélisation tel que Power Amc ou Open Modelsphere par exemple puis crée ta BDD.

J'ai tenté en m'intéressant à la BD de décrire avec un MCD la BD actuelle, mais je me suis vite laissé dépasser par le nombre de tables à représenter.

Bon courage !

J'en ai bien besoin !

[SQLpro]

Justement, c'est l'objectif que je ne souhaite pas atteindre. La BD actuelle comporte plus 250 tables...

ceci n'est pas un problème. Mieux vaut des milliers de tables bien modélisées, que quelques tables obèses...

On est bien d'accord, les utilisateurs sont dans une unique table, ce sont les groupes d'utilisateurs qui peuvent être dans des tables différentes, car ils ne possèdent pas du tout les même champs.

Il suffit d'utiliser le principe de l'héritage, aussi appelé généralisation ou spécialisation (suivant le sens par lequel on voit l’arborescence

Voilà le problème que je vois : il n'y a pas un unique type d'objet, puisqu'ils sont répartis dans plusieurs tables. C'est en fait ce majeur problème que je dois régler : éviter de créer n tables pour mes n types d'objets.


J'ai tenté en m'intéressant à la BD de décrire avec un MCD la BD actuelle, mais je me suis vite laissé dépasser par le nombre de tables à représenter.


J'en ai bien besoin !

Il faut utiliser un outil de rétro conception, remonter au MPD, puis remodéliser. Exemple : power AMC.

A +