Trigger sql unlink() ? [Résolu]

[Pymento]

Bonjour à tous, je suis assez prolifique en post en ce moment car je commence un grand projet, mais j'essai de compenser en aidant dès que j'en suis capable.

Bref, j'ai une architecture de bdd tel:

table1: id,blabla, url
table2: id, blabla, url, #id_table1

et j'ai Xprofondeurs (ce sont des fichiers et dossiers) quand je supprime un dossier, il faudrait que tous ses fils de supprime, ça j'ai pu remarquer qu'on peut le faire en spécifiant à la table que si la clef étrangère n'existe plus l'entrée se supprime. ( arrêtez moi si je me trompe).
Par contre par exemple dans l'url, ça pointe sur un fichier ou dossier qu'il faudrait que je supprime aussi.
Alors j'ai pensé à un trigger qui ferait une sorte de "unlink()" mais sincèrement je ne sais pas comment m'y prendre sachant que l'un est sur du sql et l'autre sur du php.

Merci de m'éclairer de vos précieux conseils !

[Benjamin Delespierre]

Hello

Les deux aspects sont effet séparés. Il faut d'abord détruire l'entrée correspondant au fichier dans SQL (et ses fils, voir delete en cascade sur les table InnoDB) et si la suppression s'est faite correctement, supprimer le fichier qui correspondait à cette entrée (et ses fils) sur le système de fichier via PHP.

En tout cas, même s'il est théoriquement possible d'exécuter des unlink via MySQL (voir la commande system: http://dev.mysql.com/doc/refman/5.0/...-commands.html) en utilisant un trigger (je doute de la faisabilité là) ou une procédure stockée, je te le déconseille fortement car, contrairement au comportement de PHP, MySQL ne dispose pas de fonctions natives pour faire ça et donc il sera impossible de savoir si un fichier à été correctement supprimé ou non (et je ne parle pas des problèmes de droits).

Pour ce qui est de ta structure de base de données, tes tables sont incorrectes car la relation qui lie la table 2 à la table 1 devrait en réalité s'exprimer sous forme d'une relation 1-n de la table 1 sur elle-même. Voici un article qui fait le tour de la manipulation des arbres sur des bases de données relationnelles: http://dev.mysql.com/tech-resources/...ical-data.html

[grunk]

Le même article (enfin le même concept) en français : http://sqlpro.developpez.com/cours/arborescence/

[Pymento]

Salut, merci de ta réponse.
Je vois ce que tu veux dire, mais étant donné que j'ai en fait une table fichier et une table dossier, que les champs ne sont foncièrement pas les mêmes et que ça peut m'éviter certains traitement lors d'un display. J'ai trouvé plus judicieux de séparer les deux. Ai je tort ?

Pour ce qui est de la suppression, je veux bien supprimer avec php, le seul soucis c'est que php n'est pas au couran de qui se supprime en cascade !

je supprime un dossier contenant un dossier contenant deux dossier contenant deux fichiers et trois dossiers etc....
La seule solution serait-elle de faire un parcours récursif de tout les fils et petits fils de mon noeud dossier, de stocker ça dans un tableau php et supprimer ligne par ligne ?

[grunk]

Je vois ce que tu veux dire, mais étant donné que j'ai en fait une table fichier et une table dossier, que les champs ne sont foncièrement pas les mêmes et que ça peut m'éviter certains traitement lors d'un display. J'ai trouvé plus judicieux de séparer les deux. Ai je tort ?

Pour moi un dossier ou un fichier c'est la même chose , en tout cas dans une arborescence.
En revanche tu peux avoir une seconde table contenant des infos supplémentaires pour les fichiers.
Le problème de ta méthode actuelle c'est que plus ton arborescence va se complexifier plus ton système va ralentir. Si tu atteint de grande profondeur tu vas te retrouver avec des successions de requête assez violente.

Pour ce qui est de la suppression, je veux bien supprimer avec php, le seul soucis c'est que php n'est pas au couran de qui se supprime en cascade !

Pour lancer la suppression tu va bien à un moment donner cliquer sur quelques chose. C'est ce quelque chose qui va dire à PHP ce qui est supprimé.

--edit --
Pour la suppression lit l'article que j'ai linké (ou celui en anglais) tu verras qu'en une seule requête on peut supprimer un sous arbre (donc tous les fils d'un noeud)

[Pymento]

J'ai tout lu avec attention, cette méthode est vraiment séduisante, j'aimerai quand même me passer des procédures stockées que je ne maîtrise absolument pas et faire tout ça dans un objet sur mon php.

Le seul soucis c'est que ne vois pas le déplacement d'un fils/nœud dans un autre nœud sur les requête en exemple.
----edit----
Suis je bête...un insert et un delete feront forcément l'affaire non ?

et si je comprend bien une suppression ou un ajout vers la racine, donneront systématiquement lieu à un accès à l'ensemble des entrées de la table... c'est pas trop gourmand ? sachant que je vais sans doute avec des milliers d'entrées.
-----

Après pour mon soucis de suppression le problème reste le même, sauf que la récupération des url à supprimer sera plus rapide.

[Benjamin Delespierre]

j'ai en fait une table fichier et une table dossier

Sous unix, les dossiers sont des fichiers.

@Grunk: En revanche tu peux avoir une seconde table contenant des infos supplémentaires pour les fichiers

Les méta-inf sont en DF avec la clé de la table des fichiers... Ces infos doivent donc être dans cette table.

Suis je bête...un insert et un delete feront forcément l'affaire non ?

Le déplacement d'un noeud dans un arbre passe par le changement du noeud parent, donc avec une requête update.

et si je comprend bien une suppression ou un ajout vers la racine, donneront systématiquement lieu à un accès à l'ensemble des entrées de la table

Non. Encore une fois, regarde le mécanisme de suppression en cascade sur les tables InnoDB.

[Pymento]

Envoyé par Benjamin Delespierre

Sous unix, les dossiers sont des fichiers.


Les méta-inf sont en DF avec la clé de la table des fichiers... Ces infos doivent donc être dans cette table.


Le déplacement d'un noeud dans un arbre passe par le changement du noeud parent, donc avec une requête update.


Non. Encore une fois, regarde le mécanisme de suppression en cascade sur les tables InnoDB.

Avec les arborescence intervallaires les suppressions ne se font pas en "cascade" à proprement parler, ou bien alors j'ai pas compris.

D'après ce que je vois, ça supprime une par une les entrées qui correspondent à l'intervale donné, puis ça accède à toute les entrées voisines au noeud pour leur affecter un nouvel intervale.

[Benjamin Delespierre]

En mysql, si tu utilise InnoDB, tu peux avoir des clés étrangères sous forme de références. Ces références peuvent avoir un impact sur la suppression d'un tuple comme SET NULL, CASCADE ou NO ACTION.

Doc: http://dev.mysql.com/doc/refman/5.5/...nstraints.html

Code :

1
2
3
4
5
6
7
8
9
 
[CONSTRAINT [symbol]] FOREIGN KEY
    [index_name] (index_col_name, ...)
    REFERENCES tbl_name (index_col_name,...)
    [ON DELETE reference_option]
    [ON UPDATE reference_option]
 
reference_option:
    RESTRICT | CASCADE | SET NULL | NO ACTION

Un exemple:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
CREATE TABLE table_a ( 
  id BIGINT(25) NOT NULL AUTO_INCREMENT,
  name VARCHAR(45) NOT NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB;
 
CREATE TABLE table_b ( 
  id BIGINT(25) NOT NULL AUTO_INCREMENT,
  name VARCHAR(45) NOT NULL,
  table_a_id BIGINT(25) NOT NULL,
  PRIMARY KEY (id),
  CONSTRAINT `c_table_a_id` FOREIGN KEY `fk_table_a_id` (table_a_id) REFERENCES table_a (id) ON DELETE CASCADE
) ENGINE=InnoDB;

Essaie ensuite avec:

Code :

1
2
3
4
5
 
INSERT INTO `test`.`table_a` (`id`, `name`) VALUES (NULL, 'test a');
INSERT INTO `test`.`table_b` (`id`, `name`, `table_a_id`) VALUES (NULL, 'test b', '1');
 
DELETE FROM table_a WHERE name="test a";

Les deux entrées disparaissent en raison de la contrainte sur la clé étrangère.

[grunk]

Envoyé par Benjamin Delespierre

Les méta-inf sont en DF avec la clé de la table des fichiers... Ces infos doivent donc être dans cette table.

Pas compris

Avec les arborescence intervallaires les suppressions ne se font pas en "cascade" à proprement parler, ou bien alors j'ai pas compris.

Avec une représentation intervallaire tu peux travailler avec une table unique , donc effectivement les suppression en cascade via clé étrangère n'ont pas lieux d'être.

et si je comprend bien une suppression ou un ajout vers la racine, donneront systématiquement lieu à un accès à l'ensemble des entrées de la table... c'est pas trop gourmand ?

La représentation intervallaire est très intéressante sur un système ayant beaucoup plus de select que d'insert/update. En gros si ton arbre est plus consulté qu'il n'est modifié c'est intéressant , sinon c'est sans doute discutable.

[Benjamin Delespierre]

DF: Dépendance Fonctionnelle. http://en.wikipedia.org/wiki/Functional_dependency

[Pymento]

Ok merci les gars, donc pou récapituler et répondre à ma question du début pour peut être d'autres personne plus tard.

Modélisation intervallaire.
Pour la suppression d'un élément je fais d'abord un select sur son intervalle pour récupérer toutes les url à supprimer en destination de php, puis je fais un delete de ce même intervalle, puis j'update les bords droit et gauche du reste de l'arbre.

Si jamais y'a une incohérence n'hésitez pas.


Je le passe en résolu

[Benjamin Delespierre]

Pour la suppression d'un élément je fais d'abord un select sur son intervalle pour récupérer toutes les url à supprimer en destination de php

Pas la peine, le fichier parent doit pouvoir supprimer ses fichiers fils dans PHP, tu n'as donc que le parent à réccupérer.

[grunk]

Pour la suppression d'un élément je fais d'abord un select sur son intervalle pour récupérer toutes les url à supprimer en destination de php, puis je fais un delete de ce même intervalle, puis j'update les bords

Si tu as l'élément parent à supprimer , tu peux faire simplement une suppression récursive en php :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
public static function remove($dir)
{
	$folder = new RecursiveDirectoryIterator($dir);
	while($folder->valid())
	{
		if($folder->isDir() && !$folder->isDot())
		{
			if($folder->hasChildren())
				self::remove($folder->getPathName());
 
		}
		elseif($folder->isFile() && !$folder->isDot())
		{
			unlink($folder->getPathname());
		}
		$folder->next();
	}
	$folder = null;
	rmdir($dir);
}

C'est peut êter pas utilisable comme ça mais l'idée général est là

[Pymento]

...
Enfait je suis complètement idiot! Evidemment ! bon même si ça m'as permis de réfléchir et trouver une solution plus adéquate pour ma bdd.
Une suppression récursive à partir du dossier cible directement en php...
Le truc tout simple... parfois on cherche trop compliqué pour rien..

Merci encore