par
sadeq » 06 nov. 2006, 11:53
vicissitudes c'est le mot exact dans ce genre de situation. En fait, cette difficulté pourra être levée si on respecte le concept de base de données relationnelles et on sait que le modèle relationnel est ouvert à ce genre d'astuces.
Je m'explique: En principe la table de base qui contient les données sources doit avoir des relations avec d'autres tables et donc utilise une clé primaire (ID unique) pour ça.
Rien que pour cette raison relationnelle la clé primaire ne doit pas jouer un autre rôle qui nuit à sa fonction relationnelle primaire. Exemple, un rôle qui provoque le changement des valeurs de la clé sans mettre à jour ses relations.
Le fait qu'un champ soit "clé primaire" impose par défaut un tri.
Alors que dans ton cas, tu utilises la clé primaire dans un rôle de tri seulement sans prendre en compte son rôle relationnel.
La solution qui consiste à réaliser ce que tu veux aisément tout en respectant le principe, est de considérer le tri comme un traitement d'organisation dynamique des données sources (filtre ou masque de présentation de données) quitte à stocker les paramètres d’organisation dans une table dans la base de données lorsque le tri est personnalisé et non automatique. Une table qui sera mise en relation avec la table de base. Et qui pourra se mettre à jour dans le temps sans influer sur l’ordre des données de base. Ce principe s’inscrit dans le concept d’index. Car un Index sert à réorganiser dynamiquement des données sources en vue de réaliser une présentation ou faciliter la recherche de données.
Donc ce qu’il te faut est de créer une table « Index » qui recevra les valeurs de la clé primaire dans l’ordre personnalisé déterminé par tes drag&drop.
La présentation ou l’accès aux données se fera donc via cette table puisque les valeurs qui y sont stockées correspondent chacune à une valeur unique de clé primaire dans la table de base (c’est ce qu’on appelle une clé étrangère ou relation)
Exemple :
Table de base : t1 (id (clé primaire), prénom)
Enregistrements dans t1 :
- Id, prénom
1, ‘Marc’
2, ‘Julien’
3, ‘Sébastien’
4, ‘Aline’
5, ‘Pauline’
Table Index : index_t1 (ordre (auto incrémenté)(champ facultatif), id (clé étrangère issue de la table t1 = relation)
Enregistrements dans index_t1 (classement personnalisé et non un tri automatique):
- ordre, id
1, 2
2, 5
3, 4
4, 1
5, 3
Ce qui signifie que l’ordre personnalisé des données de base est le suivant :
- ordre, id, prénom
1, 2, ‘Julien’
2, 5, ‘Pauline’
3, 4, ‘Aline’
4, 1, ‘Marc’
5, 3, ‘Sébastien’
On voit bien que grâce à la clé étrangère (id) on peut retrouver facilement les données de base (ici : le prénom)
La mise à jour de cet ordre est simple comme sa première création, il suffit donc de supprimer un ordre précédent pour le remplacer par un nouvel ordre. Et pour ça deux requêtes SQL suffisent :
- 1. A la création d’un ordre : la requête INSERT (des nouveaux id) dans la table Index
2. Au changement de l’ordre : les requêtes : DELETE (de tous les id anciens) et INSERT (des nouveaux id) dans la table Index
Mais dans l'absolu, le chagement de l'ordre pourra être considéré comme un nouvel ordre, il est donc plus simple de lancer les deux requêtes DELETE/INSERT tout cas confondu: création ou mise à jour.
Et donc le traitement drag&drop fera un DELETE/INSERT dans la table Index.
Ce qui réalise l'objectif sans toucher aux données de bases.
[quote="Anonymous"]non ! je veux effectivement enregistrer le tri dans ma base en modifiant le champ ID dune table en fonction de l'ordre d'affichage..
je suis parvenu à une solution après pas mal de vicissitudes :
http://www.phpfrance.com/forums/voir_sujet-23694-0-asc-0.php[/quote]
[b]vicissitudes[/b] c'est le mot exact dans ce genre de situation. En fait, cette difficulté pourra être levée si on respecte le concept de base de données relationnelles et on sait que le modèle relationnel est ouvert à ce genre d'astuces.
Je m'explique: En principe la table de base qui contient les données sources doit avoir des relations avec d'autres tables et donc utilise une clé primaire (ID unique) pour ça.
Rien que pour cette raison relationnelle la clé primaire ne doit pas jouer un autre rôle qui nuit à sa fonction relationnelle primaire. Exemple, un rôle qui provoque le changement des valeurs de la clé sans mettre à jour ses relations.
Le fait qu'un champ soit "clé primaire" impose par défaut un tri.
Alors que dans ton cas, tu utilises la clé primaire dans un rôle de tri seulement sans prendre en compte son rôle relationnel.
La solution qui consiste à réaliser ce que tu veux aisément tout en respectant le principe, est de considérer le tri comme un traitement d'organisation dynamique des données sources (filtre ou masque de présentation de données) quitte à stocker les paramètres d’organisation dans une table dans la base de données lorsque le tri est personnalisé et non automatique. Une table qui sera mise en relation avec la table de base. Et qui pourra se mettre à jour dans le temps sans influer sur l’ordre des données de base. Ce principe s’inscrit dans le concept d’index. Car un Index sert à réorganiser dynamiquement des données sources en vue de réaliser une présentation ou faciliter la recherche de données.
Donc ce qu’il te faut est de créer une table « Index » qui recevra les valeurs de la clé primaire dans l’ordre personnalisé déterminé par tes drag&drop.
La présentation ou l’accès aux données se fera donc via cette table puisque les valeurs qui y sont stockées correspondent chacune à une valeur unique de clé primaire dans la table de base (c’est ce qu’on appelle une clé étrangère ou relation)
[u][b]
Exemple :[/b][/u]
[b]Table de base[/b] : t1 (id (clé primaire), prénom)
Enregistrements dans t1 :
[list]Id, prénom
1, ‘Marc’
2, ‘Julien’
3, ‘Sébastien’
4, ‘Aline’
5, ‘Pauline’[/list]
[b]Table Index[/b] : index_t1 (ordre (auto incrémenté)(champ facultatif), id (clé étrangère issue de la table t1 = relation)
[b]Enregistrements [/b]dans index_t1 (classement personnalisé et non un tri automatique):
[list]ordre, id
1, 2
2, 5
3, 4
4, 1
5, 3[/list]
Ce qui signifie que l’ordre personnalisé des données de base est le suivant :
[list]ordre, id, prénom
1, 2, ‘Julien’
2, 5, ‘Pauline’
3, 4, ‘Aline’
4, 1, ‘Marc’
5, 3, ‘Sébastien’[/list]
On voit bien que grâce à la clé étrangère (id) on peut retrouver facilement les données de base (ici : le prénom)
La mise à jour de cet ordre est simple comme sa première création, il suffit donc de supprimer un ordre précédent pour le remplacer par un nouvel ordre. Et pour ça deux requêtes SQL suffisent :
[list]1. A la création d’un ordre : la requête INSERT (des nouveaux id) dans la table Index
2. Au changement de l’ordre : les requêtes : DELETE (de tous les id anciens) et INSERT (des nouveaux id) dans la table Index
[/list]
Mais dans l'absolu, le chagement de l'ordre pourra être considéré comme un nouvel ordre, il est donc plus simple de lancer les deux requêtes DELETE/INSERT tout cas confondu: création ou mise à jour.
Et donc le traitement drag&drop fera un DELETE/INSERT dans la table Index.
Ce qui réalise l'objectif sans toucher aux données de bases.