Design & Développement web - Le topic des canards qui mangent des cookies

[deathdigger]

En fait t'as deux façons de voir les choses : soit tu vois ta base de données comme une vraie base de données avec une structure bien propre, soit tu vois ta base de données comme un endroit où stocker tout et n'importe quoi sans se prendre la tête et qui sert juste à conserver les infos (et à ce moment là le NoSQL est peut être plus approprié d'ailleurs).

Une BDD bien faite, c'est 90% de galères en moins au niveau du code.

[tenshu]

Surtout si on utilise des clés externes ... enfin si les comportements en cascade sont bien réglé au départ.

"heu pourquoi j'ai plus rien en base là ?"

[Nattefrost]

clef externe = foreign key ?
Dans les docs je vois rien qui se nomme clef externe.

[tenshu]

clef externe = foreign key ?

Oui.

[Fastela]

Les clés externe, le truc qui fait rager au max dès qu'il y a une pétouille qui déconne

[tenshu]

haha
MAIS BORDEL QUI A COLLE UN DELETE CASCADE ICI?! non mais ho!

[Awake]

Mais y'a encore des gens qui dev en mysql sans clefs externes Mer ils sont fou

[Nattefrost]

J'ai appris les bases de mysql que cette année mais je vois pas comment c'est possible en fait. Ca se passe comment sans les foreign keys? On bazarde tout dans une table en disant "BALEKOUILLES" ?

Sans foreign keys, pas de jointures ? Incompréhension du monde qui m'entoure, perte de repères, vertiges.

[Awake]

Sans foreign keys, pas de jointures ? Incompréhension du monde qui m'entoure, j'ai des vertiges.

Ben si mais sans garantie de l'intégrité de la base. Donc potentiellement avec des clefs qui pointent vers des entrées supprimées. Topitop.

[GrandFather]

Ah, on peut développer avec MySQL ?

Les clés étrangères, avec l'intégrité référentielle (les mises à jour en cascade) et les transactions, c'est vraiment le B.-A.BA de la base de données. Quand on voit le nombre de gros projets Web, dont des CMS, qui tournent encore avec le MyISAM de base, y'a de quoi prendre peur...

[Fastela]

Je suis pas ultra balaise en MySQL, mais globalement, les Foreign Keys ça te permet de créer un lien entre deux clés. Donc admettons que dans une première table j'ai des genres de jeux vidéo :

1 - FPS
2 - Plateformes
3 - Gestion

Et j'ai une autre table avec des jeux, dont un champ "genre" avec comme type INT et une relation externe vers l'ID de la table genre.

Quand tu crées une fiche d'un jeu, tu ne peux pas avoir une valeur autre qu'un des ID spécifié dans ta table genre.

C'est qu'un exemple, et certainement pas le plus représentatif, mais ça peut t'aider à comprendre un peu mieux

Et honnêtement, j'utilise jamais de FK (honte sur moi), et ça gêne en rien pour les jointures.

Edit: wé en deux minutes deux personnes ont mieux expliqué que moi :D

[Nattefrost]

Oui mais justement j'ai appris avec les foreign keys et je trouvais bizarre de ne pas en utiliser.

Mais du coup si on les utilise pas ça veut dire qu'on peut supprimer n'importe quoi sans se taper le message "cannot delete foreign key constraint" (un truc du style) et qu'une colonne peut pointer sur du "vide" dans une autre table, et tu t'en rends compte qu'au moment de faire une jointure qui retourne que dalle ?

Ca semble pas très safe, quand même.

[Akajouman]

J'ai appris les bases de mysql que cette année mais je vois pas comment c'est possible en fait. Ca se passe comment sans les foreign keys? On bazarde tout dans une table en disant "BALEKOUILLES" ?

Sans foreign keys, pas de jointures ? Incompréhension du monde qui m'entoure, perte de repères, vertiges.

J'ai toujours appris avec les clés étrangères aussi, je ne me vois pas faire sans...

[Sekigo Le Magnifique]

Oui mais justement j'ai appris avec les foreign keys et je trouvais bizarre de ne pas en utiliser.

Mais du coup si on les utilise pas ça veut dire qu'on peut supprimer n'importe quoi sans se taper le message "cannot delete foreign key constraint" (un truc du style) et qu'une colonne peut pointer sur du "vide" dans une autre table, et tu t'en rends compte qu'au moment de faire une jointure qui retourne que dalle ?

Ca semble pas très safe, quand même.

Avec MySql, le moteur de BDD par défaut jusqu'en 2013 a été MyISAM, qui ne gère pas les clés étrangères.
Dans 70% des cas (chiffre au pif), on laisse le truc par défaut et on va pas chercher plus loin, faut que ça marche, point. Ajoutes à ça qu'une base de donnée est un des composant à la plus longue durée de vie, et qu'une modification mineure sur celle-ci peut avoir des conséquences désastreuses. Moins on touche à la structure, mieux on se porte, quitte à faire des trucs tordus et dégueulasse.

Je bosse principalement sur une base de donnée avec 40 tables sans clés étrangères. C'est le boxon, faut faire des tonnes de vérif' dans tout les sens, être constamment en mode parano, mais ça fonctionne. On peut toujours faire sans. Et il faut impérativement apprendre à faire sans si on va dans une entreprise ayant plus de 5 ans.

[Nattefrost]

Encore un an et demi (si tout se passe bien inch allah) avant stage et alternance, je sens que ça réserve des surprise et qu'une partie des 'bonnes pratiques' ou simplement usages appris à l'école vont passer à l'as .

[Awake]

Je bosse principalement sur une base de donnée avec 40 tables sans clés étrangères. C'est le boxon, faut faire des tonnes de vérif' dans tout les sens, être constamment en mode parano, mais ça fonctionne. On peut toujours faire sans. Et il faut impérativement apprendre à faire sans si on va dans une entreprise ayant plus de 5 ans.

T'es sûr que sur le moyen terme vous y gagneriez pas à faire un bon refactoring de la bdd plutôt que de passer votre vie à faire de la chips ? Surtout que bon 40 tables c'est rien.

[tenshu]

Faut pas psychoter, l'immense majorité des projets web utilisant mysql n'utilisent pas de Fk pour des raisons de compatibilité.
D'ailleurs les développeurs suffisamment parfumés utilisent des ORM qui abstraient cette gestion en mimant le comportement si besoin.

L'intégrité plus garantie au delete ... mais c'est souvent pas gravé par ce que l'entrée principale est celle que l'on vire correctement. Et l'update...vous changez souvent l'identifiant d'un objet vous?

C'est bien pour ça que beaucoup de projet ne les utilisent pas.
Et je dis ça en haïssant le model de Drupal qui est un putain d'outrage au bon sens depuis bien 10 ans. (Chaque champs d'une entité créé une table à part et une deuxième pour stocker les révisions qu'on utilise presque jamais, on se retrouve rapidement avec 400 500 tables)

[war-p]

Utilisez mongodb si vous voulez pas être embêtés par des FK...

[deathdigger]

Avec MySql, le moteur de BDD par défaut jusqu'en 2013 a été MyISAM, qui ne gère pas les clés étrangères.
Dans 70% des cas (chiffre au pif), on laisse le truc par défaut et on va pas chercher plus loin, faut que ça marche, point. Ajoutes à ça qu'une base de donnée est un des composant à la plus longue durée de vie, et qu'une modification mineure sur celle-ci peut avoir des conséquences désastreuses. Moins on touche à la structure, mieux on se porte, quitte à faire des trucs tordus et dégueulasse.

Je bosse principalement sur une base de donnée avec 40 tables sans clés étrangères. C'est le boxon, faut faire des tonnes de vérif' dans tout les sens, être constamment en mode parano, mais ça fonctionne. On peut toujours faire sans. Et il faut impérativement apprendre à faire sans si on va dans une entreprise ayant plus de 5 ans.

A ça tu peux rajouter tous les logiciels basés sur une base db2, pas de clef du tout, pas d'auto-increment, aucune contrainte. Donc toute la consolidation doit se faire en manuel, avec des compteurs et des contraintes calculées niveau logiciel. Et je ne te parle pas de petites bases, l'ERP sur lequel je bosse, c'est un truc comme 300 tables avec chacune plus d'une centaine de champs.

[GrandFather]

Faut pas psychoter, l'immense majorité des projets web utilisant mysql n'utilisent pas de Fk pour des raisons de compatibilité.
D'ailleurs les développeurs suffisamment parfumés utilisent des ORM qui abstraient cette gestion en mimant le comportement si besoin.

Déporter ces mécanismes dans le code client de la BDD, ça a un coût, en performance et en maintenance, alors qu'un SGBDR est optimisé pour. Et puis, ça n'est pas une garantie totale, il y aura toujours le moment de galère, celui où il faudra intervenir directement sur la base, dans l'urgence, pour récupérer d'une connerie saisie ou même pour une opération bénigne de purge et d'archivage, et là tu te retrouves à travailler sans filet. T'as intérêt à être concentré et à avoir des sauvegardes, sinon c'est le drame...

Dans ma boîte, lorsqu'on s'est mis au client léger et à l'appli web il y a environ 10 ans, on a écarté d'emblée MySQL, trop pauvre fonctionnellement, pour adopter PostgreSQL. Quand je vois le peu de progrès accompli depuis par MySQL pour rattraper son retard, je me félicite sincèrement de cette décision.

[Awake]

Faut pas psychoter, l'immense majorité des projets web utilisant mysql n'utilisent pas de Fk pour des raisons de compatibilité.
D'ailleurs les développeurs suffisamment parfumés utilisent des ORM qui abstraient cette gestion en mimant le comportement si besoin.

L'intégrité plus garantie au delete ... mais c'est souvent pas gravé par ce que l'entrée principale est celle que l'on vire correctement. Et l'update...vous changez souvent l'identifiant d'un objet vous?

C'est bien pour ça que beaucoup de projet ne les utilisent pas.
Et je dis ça en haïssant le model de Drupal qui est un putain d'outrage au bon sens depuis bien 10 ans. (Chaque champs d'une entité créé une table à part et une deuxième pour stocker les révisions qu'on utilise presque jamais, on se retrouve rapidement avec 400 500 tables)

Non désolé, utiliser une ORM n'empêche pas d'utiliser les FK. Déjà parce que toutes les requêtes ne se font pas via les objects, par exemple les mass delete ou mass update. D'autre part parce que les FK te permettent une garantie quand à l'intégrité de ta base, c'est comme les tests unitaires, on peut s'en passer dans l'absolu mais au final il ne vaut mieux pas. Et pour "la plupart des projets n'utilisent pas de FK" c'est une fausse excuse, ce n'est pas parce que tout le monde fait de la merde qu'il faut faire pareil.

[Sekigo Le Magnifique]

il y aura toujours le moment de galère, celui où il faudra intervenir directement sur la base, dans l'urgence, pour récupérer d'une connerie saisie ou même pour une opération bénigne de purge et d'archivage, et là tu te retrouves à travailler sans filet. T'as intérêt à être concentré et à avoir des sauvegardes, sinon c'est le drame...

Aaaah, ces moments de grâce, où tu lances ton code en serrant les fesses bien fort. Où tu crains que malgré tes innombrables tests en amont, il y ait une couille. Où dans 95% des cas, ça rentre comme dans du beurre. Et dans 5% des cas, tu t'es planté, et dans les 10 minutes qui suivent, tu vois ta boite mail se remplir de plaintes utilisateurs (parfois virulente). et tu arrêtes le programme en urgence et tu lances la sauvegarde d'urgence, qui n'est jamais assez rapide. Et ta boite mail continue de se remplir, tu as ton patron qui vient te hurler dessus et tes collègues qui essaient d'en profiter pour rejeter toute la merde sur toi.

[Nattefrost]

J'ai déjà hâte d'y être

[tenshu]

Non désolé, utiliser une ORM n'empêche pas d'utiliser les FK. Déjà parce que toutes les requêtes ne se font pas via les objects, par exemple les mass delete ou mass update. D'autre part parce que les FK te permettent une garantie quand à l'intégrité de ta base, c'est comme les tests unitaires, on peut s'en passer dans l'absolu mais au final il ne vaut mieux pas. Et pour "la plupart des projets n'utilisent pas de FK" c'est une fausse excuse, ce n'est pas parce que tout le monde fait de la merde qu'il faut faire pareil.

Je pense que tu devrais lire les messages autrement qu'en diagonale.

[Teocali]

J'ai appris les bases de mysql que cette année mais je vois pas comment c'est possible en fait. Ca se passe comment sans les foreign keys? On bazarde tout dans une table en disant "BALEKOUILLES" ?

Exactement. enfin, generalement, comme dit plus bas, t'as un ORM qui s'en ocupe a ta place. Mais quand cet ORM est un ORM maison, construit au dessus d'Hibernate, et qui n'offre pas le quart des fonctionnalites de celui-ci, ca devient complique :vecu:

[Gillete]

Je bosse pour la première fois avec AngularJS. J'avais pour habitude de cracher sur le JavaScript, ce framework me fait changer d'avis.
C'est très simple à utiliser et accélère vraiment mes développements. Je suis plutôt spécialisé back en .NET et j'arrive enfin à donner une bonne bouille à mes applications web.

[Teocali]

Je bosse pour la première fois avec AngularJS. J'avais pour habitude de cracher sur le JavaScript, ce framework me fait changer d'avis.

Javascript, ca reste de la merde. AngularJS est tres bien, mais pas grace a JS. Plutot en depit de.

:my2cent:

Et accessoirement je suis en train de me pencher dessus aussi, c'est vraiment pas mal, effectivement. Tu couples ca avec Wamp, et y'a moyen de sortir des trucs sympa, je pense.

[Skiant]

J'fais de l'Angular au taf depuis décembre, avant ça on utilisait un framework JS fait maison qu'était vraiment relou.
C'est effectivement très sympa mais on attendra la version 2.0 pour avoir enfin des performances dignes de ce nom grâce à object.observe() qui arrive dans ES6. Ça et les components, on va avoir quelque chose de bien.

Pour ceux que ça intéressent, j'ai pécho le ng-book et c'est bien foutu. Ça part du niveau zéro ou presque et ça t'explique toutes les features dont tu auras besoin pour bosser sereinement.


PS : Javascript c'est autant de la merde que celui qui l'utilise.

[Teocali]

PS : Javascript c'est autant de la merde que celui qui l'utilise.

Ah non non, pas d'accord. Le JS est objectivement un language de merde. et puisque ca sert a rien de refaire un trol qui a deja ete fait : http://sametmax.com/un-gros-troll-de...r-javacscript/

[Tomaka17]

C'est très simple à utiliser et accélère vraiment mes développements. Je suis plutôt spécialisé back en .NET et j'arrive enfin à donner une bonne bouille à mes applications web.

Les joies de la programmation déclarative.
C'est LE paradigme de programmation géniallissime dans les situations précises où tu n'as pas besoin d'un degré de liberté fou-fou.

Il ne reste plus qu'à faire un angular-like server-side (peu importe le langage) et que tout le monde s'extasie dessus en disant que c'est une révolution et une idée jamais vue auparavant.