PHP et SQL : La gestion des relations/clés étrangères

[rachids]

Hello,

Je suis présentement un tuto sur Laravel car je me rends compte que je suis parfois à l'ouest avec ce framework.

Dans ce tuto, le monsieur nous suggère de créer une table "tickets" et une table "commentaires". Sauf que dans ses migrations il ne déclare jamais les champs comme clés étrangères avec le fameux ($table->foreign() ).
Mais c'est géré au niveau des modèles.

Je me pose donc une question car c'est un problème que j'ai rencontré et je suis vraiment tenté de faire comme le monsieur.

Est ce bien important de déclarer nos clés étrangères dans mySQL si on les gère côté PHP ?
J'ai rencontré un problème assez chiant qui est hautement dû à mon incapacité à utiliser SQL correctement. Lorsque je déclare mes clés étrangères en SQL, et que je souhaite vider une table qui comporte des clés étrangères, je me bute toujours à la fameuse erreur "foreign key constraint" et il faut jongler entre pas mal de trucs pour pouvoir arriver à mes fins.

Je parle de Laravel dans mon post, mais plus globalement ça s'appliquerait à n'importe quel application PHP.
D'ailleurs, quand je débutais et que je créais mes tables via phpMyAdmin, je ne déclarais jamais mes clés étrangères dans l'outil, par contre dans mes scripts c'était géré. Et j'ai jamais eu de problème.

Merci pour vos avis éclairés.

[Xenos]

Salut,

les tables à clefs étrangères ne peuvent effectivement pas être vidées via TRUNCATE (c'est un peu dommage), mais il me semble qu'elles peuvent l'être via DELETE (à condition que les contraintes de clef soient respectées par ce DELETE). A voir aussi si la contrainte "ON DELETE CASCADE" contourne le problème du truncate (mais c'est le genre de contrainte risquée qui peut faire sauter une base entière si elle est trop et mal utilisée).

Sinon, la méthode consiste simplement à dire à MySQL de ne pas vérifier les contraintes de clef pour cette session (SET FOREIGN_KEY_CHECKS=0), de faire ses truncates, puis de remettre la vérification des contraintes (si on a d'autres requêtes à faire dans cette session, cette variable ainsi définie étant par session).

Perso, je les fais vérifier par le SQL et surtout pas par le PHP. Le SQL est en effet plus véloce à ce genre de chose, et surtout, suppose qu'on ait deux langages qui requêtent la même BDD, alors les checks devraient être fait dans les 2 langages (et au taff, on a 2 langages). En plus, c'est natif MySQL: pas de framework ni rien.

[niahoo]

j'utilise laravel et je mets le foreign keys. je ne suis pas sur que laravel supprime en cascade automatiquement, mais dans tous les cas c'est plus propre.

[rachids]

Oui je conçois que ce soit plus propre sinon ça n'existerait pas et que ça centralise les choses si on utilise plus d'un langage pour la même base, ce qui n'est quand même pas fréquent (je n'avais jamais pensé à ça en fait, mais je peux l'imaginer).

Mais je me demandais, si je ne le fais pas en SQL, globalement mes problèmes seront uniquement liés aux conventions (ie. ce ne sera pas propre), mais techniquement l'application roulerait pareil.

Au taff, je travailles sur un projet où j'ai 3 bases de données (une en mySQL, deux en SQL Server) et je dois pouvoir lier mes tables entre elles (ce qui est impossible côté SQL), du coup c'est le PHP qui fait le travail et ça fonctionne plutôt bien, mais je ne me suis jamais interrogé sur les risques liés à cette pratique.

[Xenos]

Il y a peut-être des soucis possibles niveau transactions, mais le principal problème que je vois est la maintenabilité du code PHP: un jour, lors de l'ajout d'une feature, tu vas oublier de passer par ton code PHP et tu vas faire l'insert en BDD direct, sans passer par la phase de check. Là, ça coincera.
D'autant que ces checks rajoutés en PHP alourdissent le code (sans avoir forcément de sens véritable niveau code métier). Enfin, MySQL peut zapper les checks sur les contraintes ou supprimer une contrainte en moins de 2 secondes: le code PHP après les multiples évolutions indispensables à venir sera-t-il capable de faire de même, avec un coût en design/achi/conception limité (celui de MySQL étant de 0, puisque c'est fait par le MySQL qu'on ne développe pas nous-même)?

[niahoo]

Puis bon c'est une ligne de code à rajouter par relation, c'est pas non plus un travail de malade, et ça assure que si un jour ton code a une erreur (ce qui va arriver) alors ça sécurise tes données.

[Roworll]

je dois pouvoir lier mes tables entre elles (ce qui est impossible côté SQL)

Tu peux développer ? Il est impossible de lier quoi avec SQL Server?

[niahoo]

lier une table mySQL et une table SQL server. Doit y avoir moyen avec des trucs genre ODBC ou truc du style. Mais bon moi le premier dans ces circonstances je me contenterai du code ; en tenant compte du fait que les clés étrangères peuvent avoir des références vers des entrées qui n'existent pas et le prendre en compte.

[rachids]

Ok merci pour vos éclaircissements, je vais continuer à déclarer mes clés étrangères côté SQL là où je le peux.

Et oui je parlais de liaisons entre 2 tables qui ne proviennent pas de la même source de données.

[Roworll]

Et oui je parlais de liaisons entre 2 tables qui ne proviennent pas de la même source de données.

Même si tu ne peux pas créer de clés étrangère qui relient deux moteurs de base de données différentes, SQL Server, via les requêtes distribuées, te permet de récupérer le contenu d'une BDD externe (MySQL, Oracle, DB2, fichier texte, XML, excel ...) et de le lier avec le contenu de tes tables locales.

Il te faut un driver OLEDB ou une source de données ODBC correctement configurée.
Ensuite, tu peux t'appuyer sur OPENROWSET()/OPENQUERY() pour récuperer tes données MySQL dans SQL Server et même faire des jointures entre tes tables MySQL et SQL Server.

Petit lien avec un exemple presque complet

Dans un environnement multi systèmes, c'est le genre de truc qui te sauve pas mal de temps quand tu dois transférer des données d'une DB à une autre