Le MySQL est il si limité que ça ?

 
Ton exemple n'est pas vraiment bien choisi : ce cas ne doit pas apparaître !! Normalement, tu conçois l'architecture de ta BDD AVANT de commencer ton appli. Et là tu es forcé au cours du dev de tenir compte des contraintes mises en place.
 
Dans le cas où tu développes une appli qui doit accéder à une BDD déjà existante, je suis désolé mais il vaudra mieux pour le développeur que des contraintes existent : au moins pendant le dev et les tests, les problèmes apparaîtront tout de suite, et pas après 3 mois de mise en prod où là on s'apercevra que des enregistrements font référence à des codes qui sont supprimés, ou sont présents en double.
 
Une BDD ce n'est pas seulement un espace de stockage, c'est également tout un ensemble de règles et de contraintes qui régissent l'organisation des données, et sont les garantes de l'intégrité de ta base ( ce qui est le plus important, parce que sinon une fois que ta base est vérolée, tu peux t'accrocher pour la remettre à jour).
 
Dans un ensemble BDD + appli, la référence, c'est la BDD, et l'appli doit se plier à ce qui existe dans la base en terme de contraintes, sinon tu es à la merci d'un bug ou d'une incohérence de ton appli...
 
Pour reprendre ton exemple, la qestion à se poser n'est pas 'Ne vaut-il pas mieux supprimer les contraintes BDD', mais 'Pourquoi cela peut-il se produire ?'. En effet si une contrainte a été mise en place, c'est pour une raison précise (il peut arriver que des contraintes soient mal définies, mais de là à dire qu'il faut ramener tous les contrôles au niveau applicatif, il y a une grande différence !!)

[edtdd]--Message édité par irulan--[/edtdd]

 
C'est tout le probleme des applis qui contiennent des acces DB : jusqu'ou faire le boulot, et a partir d'ou laisser la DB faire ce pour quoi elle est faite ? En poussant le raisonnement, c'est ca qui conduit des applis Java a loader des tables entieres, pour faire des jointures elles-memes en memoire. Personnellement, sur ton exemple (effacer des donnees), je verifie au niveau applicatif ET base ... apres tout, aucune des couches n'est censee faire confiance a celles qui l'entourent: vive l'encapsulation :)

 
Oui, les contraintes, c'est du code ! De la logique en tout cas. Pas du stockage.
 
Les contraites, çà va beaucoup plus loins que çà. Contrairement à ce que tu peux penser, je connais d'autres bases de données, et les contraintes, quand j'ai le choix, je m'en sert effectivement pour débugger (je parle de ici uniquement de clef étrangères), pas en prod ! Parce-ce que pour faire évoluer une appli avec des tests pleins la base sur tel champ qui ne peut prendre que telle ou telle valeur, merçi, mais c'est une vraie galère !
 
T'as essayé de migrer une base SQL 6.5 en 2000 avec par exemple des cléfs étrangères sur des champs de types différents !Merci du Kado !Bon ok c'est une appli pourrie, même que des clefs étrangères, ont est Obligé d'en virrer de temps en temps pour des problèmes de performance ! Quand on voie celles qui restent ...
 
Pour finir, je ne supporte pas les applis qui proposent à l'utilisateur de supprimer un enregistrement, te demande de confirmer et qui ensuite te disent que c'est pas possible parceque la base a refusée !
Puisque l'appli est obligée de traiter le cas, autant le faire proprement AVANT, non ?

 
 :ouch:  
Les règles d'intégrité, tu considères ça comme faisant partie du code  :sweat:  
Je ne voudrais pas dire, mais comme disait Gonzoide, dès que tu sors de l'utilisation de PHP / MySQL pour un forum, et que tu vas vers une utilisation professionnelle, les contraintes d'intégrité font partie de la structure de la base au même titre qu'une colonne, ou qu'une table.
Non seulement ça permet de centraliser l'intégrité de la base à un même endroit, mais en plus ça te permet de débugger une appli beaucoup plus vite (effectivement quand le SGBD renvoie une erreur, tu sais tout de suite qu'il y a un truc qui ne va pas).
 
Les triggers éventuellement je t'accorde que ça peut être considéré comme une incursion du code dans la structure de ta base de données (et encore), mais les contraintes NON !!

Pour les triggers, je ne dis pas que çà sert à rien ! C'est juste que je trouve pas çà propre. Cà fait un mélange entre le code et les données, tout comme les règles d'intégrité (au sens général).  
Celà dit, que ces fonctionnalité existent ne me gènent pas tant que le SGBD reste efficace. Après tout rien ne m'oblige à les utiliser ;-)

 
Autre breve de comptoir du meme niveau : "En Java, a quoi ca sert les variables privees ? Elles ont qu'a etre toutes publiques, c'est au developpeur de bien les acceder"
 
Faut vous dire que parmi les utilisateurs de SGBD (au sens large), y'a quand meme autre chose que les petits crapauds qui pondent 3 bouts sur MySQL pour gerer le forum de leur site web ...

 
parce que jusqu'a cette dernière version, la syntaxe existait, mais cela revenait exactement au meme qu'une concaténation complete des 2 tables. Maintenant ils commencent a implémenter les jointures gauches mais toujours pas les droites.

 
y a un truc que je pige pas, pourquoi tu dis que les jointures sont pas supoprtées ?
 
tu peux très bien trier tes éléments et faire la jointure après... (j'imagine comme ça : SELECT ... where ... as bidule LEFT JOIN ... where ..=... as ...)

 
Oui oui bien sur. Les triggers personnes s'en sert, noooooon, ça sert juste a maintenir une BD propre et sans aucune erreur (qd c bien fait) ...
Faut pas dire n'imp' non plus ...

 
Pour moi select n'est pas une jointure, ca fait que concaténer les tables. une jointure permet de faire le tri des élément a concaténer AVANT et donc d'être plus performant.

je suis pas d'accord du tout...
Ca sert à garantir l'intégrité de la base indépendamment des applis clientes. Intérêt : l'intégrité est assurée en un seul endroit, documentable et facilement maintenable.
Ca sert à quoi un langage de programmation du style  ou pascal, puis q'uon a l'assembleur ?
Ca sert à quoi l'asembleur, puisqu'on pourrait programmer directement en binaire ?
La vérification syntaxique d'un compilateur, ça sert à quoi ? sûrement pour les programmes mal écrits...

 
Benh tiens, et le SELECT, on sait faire qu'un SELECT *... Tssss... Tu t'es mal exprimé la :)
 
MySQL ne supporte pas les clés étrangères et le seul truc vraiment chiant, c'est de devoir donc faire le DELETE en cascade a la main... Et l'autre truc crucial qu'il me manque c'est le vues.
 
A part ca, MySQL est suffisant pour la plupart des applications, et sa légereté en fait un des plus rapide!

 :ouch: c vrai???
putain alors SQL Server c vraiment de la dynamite a coté!!!