Bonjour a tous,
    je parlais de MySQL avec un pote, parce que je connais pas du tout. Il m'a affirmé que ça ne gerait pas gd chose, ni trigger ou meme ni cle etrangere ??? àa serait vraiment limité alors ?
 
merci de m'eclaircir  

Oui, c'est très limité. Ca offre un service minimal de SGBDR, en faisant l'hypothèse que toutes les opérations avancées sont gérées au niveau applicatif. Si tu cherche une BD plus puissante, oriente toi vers postgersql.
 
Quoi que je me suis laissé dire que la dernière version supportait les sessions... C'est un début

En effet, ils commencent seulement a intégrer les jointures...

A quoi çà sert les clefs étrangères, à part ralentir le SGBD et à garantir une relative sécurité pour les applis mal écrites ?
 
Quand aux triggers, y'a pas pire pour rendre une appli impossible à maintenir ou à debugger ?

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

je suis assez de l'avis de mara's dad ...
 
les fonctions avancées de certains sgbds sont surtout la pour décorer et rendre le produit plus attrayant, mais mysql est suffisant pour 99% des besoins, et grace a la replication et le support des transactions il est utilisable dans un environnement de production ...

 
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!

ce qui manque le + je trouve c'est les subqueries, mais apparement ca devrait arriver dans la v4

Ouai, c'est vrai que ca manque un peu, mais on arrive quasi a tout faire sans cela, grace au LEFT OUTER JOIN par exemple qui sont d'ailleurs plus performants :-o
 
Et puis y a les tables temporaires si tu vois vraiment pas comment faire sans subqueries, tout est une question de volonté.

Salut, je viens dire mon mot...
Mara's Dad a écrit

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...

euh, c quoi une jointure?  
(pas taper, newbie en bdd...)

buitoni a écrit a écrit :     Benh tiens, et le SELECT, on sait faire qu'un SELECT *... Tssss... Tu t'es mal exprimé la

 
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.

 
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 ...

 
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 ...)

pis les requetes imbriquées, aussi...

 
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.

Ca supporte pas non plus les insert à partir d'une requete sur une autre table, ni le delete sur requete etc..
 
Ceux qui disent que les triggers ne servent a rien, faudra pas prendre votre utilisation des bdd pour une generaalité tout de même

 
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 ...

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 ;-)

 
   
Les règles d'intégrité, tu considères ça comme faisant partie du code    
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 !!

Je ne peux qu'abonder dans le sens d'Irulan
 
Une contrainte d'integrite, c'est du meme niveau qu'un singleton en langage objet : tu te vois ne pas implementer de singleton et faire confiance au developeur pour ne creer qu'une instance d'un objet ?

oui et puis les triggers c qd meme super pratique pour justement permettre l'integrité TOTALE (si les triggers sont bien pensés ...) de la BD.
 
Moi j'ai le souvenir de BD enoooorme avec pleins de contraintes, et les triggers ça aide

c'est quoi un trigger ? c'est quoi un trigger "bien pensé" ? "mal pensé" ?  

Ah ben ça faut pas confondre : y'a les bons triggers et les mauvais triggers.
C'est comme les bons et les mauvais chasseurs !!
 
Non sinon, un trigger, c'est une action qui se déclenche quand un certain évènement survient : par exemple quand tu insères un nouvelle ligne, tu peux faire des contrôles supplémentaires en plus des contraintes d'intégrité.
Cela dit c'est délicat à manier, je sais que j'évite d'utiliser la plupart du temps...

irulan a écrit a écrit :         Les règles d'intégrité, tu considères ça comme faisant partie du code     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).

 
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 ?

 
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

 
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]