Reprise du message précédent :

vu la tronche d'Oracle et son ergonomie, ça se tient

ben faut faire un "grant connect" à la database sur ton user "internal"...

nan mais "connect as internal" c'est la version 8i du très contemporain "connect sys as sysdba" hein

ah ok
 
ben format c:

(sinon, plus sérieusement, t'as essayé en utilisant le compte admin de l'os ?)

Postgres > Ingres
 
(postgresql a démarré comme un fork d'Ingres)

Euh non, relationnel signifie relations, pas transactions, et encore moins atomic transactions, et c'est un modèle/une base de modélisation théorique, pas juste une question d'implémentation.

je parle de SGBDR, pas de BDR
 
le SGBDR se doit de garantir l'intégrité de tes données à tout moment, y compris quand tu es en train de modifier tes données. ceci implique obligatoirement la présence de transactions, qu'elles soient atomic ou non.
 
lorsque du fais un "delete pere cascade constraints", si ça prends 4 heures à tourner, il ne faut pas que ni le père ni ses fils ne soient visibles durant l'instruction de suppression. seule une gestion des transactions le permet.

Pourquoi cet article de mauvaise qualité, sans source et sans doute écrit par des ignares ne parle pas de transactions ou d'atomicité comme caractéristiques d'une base de données relationnelle ?

t'es bouché ou quoi ?
 
SGBD c'est pas une base de données.
 
C'est un SYSTEME DE GESTION de bases de données.
 
Evidement que ta base de données tout pourrie d'un forum avec deux pauvres relations entre topic, post et user y'a pas besoin de mettre la mondre transaction.
 
Mais ton SGBD, t'en fait pas qu'il en fait à chaque instruction des micro-transactions, même si c'est MySQL 3

On te reprend sur le fait que RELATIONNEL ne signifie pas TRANSACTION.
Puis toi qui vient dire à quelqu'un qu'il est bouché, vu ton passif de malcomprenant chronique sur ce forum, mouarf quoi

 
A la base, c'est parti de là :
 

 
Il est question de SGBDR et de confusion sur définition du R.
 
Si c'est effectivement "relationnel", je répète, cela implique tout de même qu'il est transactionnel. Et donc dire "un SGBDR est comme son nom l'indique, transactionnel", pas une erreur, même si c'est effectivement un simple effet de bord.
 
Et si tu tiens temps à parler de la définition du mot relationnel, alors pour ta gouverne, ça n'a rien à voir avec les bases de données

PS : à noter que c'est pas moi qui ai fait la confusion hein.
 
Relis ce topic. En, fait, t'es pas bouché, tu sais pas lire, c'est tout

Puisque tu sais d'ailleurs pas lire, et que Masklinn n'a quoté que la première ligne de mon poste, voici pour tes beaux yeux, la suite.
Alors tu peux parler en ce qui concerne la comprenette pas facile hein...
 

T'iras éditer cet ignoble d'article très très faux de Wikipedia par la même occasion

Non, et c'est bien pour ça qu'il existe une catégorie "transactional databases" dans le lexique

 
TAY BOUCHE OU QUOI /FOU/ /FOU/

attention les amis, notez bien :

dès qu'un topic passe en lien sur bla² ça devient un troll ambulant

...
 
un semi-remorque, c'est un poids lourd.
un poids-lourd n'est pas forcément un semi-remorque.
 
c'est que que le cerveau humain est capable de comprendre à partir du 36° mois.
 
apparement y'en a ici qui n'ont pas dépassé ce stade.
 
ensuite, un autobus est un poids-lourd. Et pourtant, un semi-remoque n'est pas un autobus, et inversement.
 
un SGBDR, pour mériter son nom de relationnel, doit être capable de garantir la cohérence des données à tout instant, et pour tout utilisateur, ceci implique de facto la présence de transactions. c'est pas pour autant effectivement qu'un SGBDR est forcément transactionnel, et encore moins l'inverse.
ceci n'empêche pas qu'un SGBDR comporte obligatoirement des fonctionnalitée transactionnelles, même si elles sont insuffisantes pour être élevé au statu de SGBD transactionnel. capige ?

ben de toute façon, pour voir douleur anale déboucher sur un topic, ça ne peut que vouloir dire que le topic est passé dans bla², il est bien trop occupé à déblatérer ses conneries sur bla² pour aller de lui-même sur un topic.

Non, on peut faire un SGBDR sans transaction.
On parle de définition, pas d'état de l'art. Sors un peu de ton carcan.

 
Et ta gueule pour voir dugland ?

stop ou je ferme

suce

t'as raison, ça vaut pas la peine de se prendre le choux pour ça...
 
anyway, analfabete n'est même pas revenu dans ce topic, donc depuis deux pages (même sans compter ce hors topic), on parle certainement de tout sauf ce qu'il voulait savoir...

Je tiens quand même à ajouter que... http://martinfowler.com/bliki/Transactionless.html

Désolé, mais eBay n'utilise pas un SGBDR
 

 
(deplus, une fois de plus, il faut faire la distinction entre transaction utilisateur, et transaction atomique, gérée uniquement par le SGBD...)
 
"delete pere where id = 1 cascade contraints" <= moi je vois pas de trasaction ici. et pourtant, le SGBDR en effectue bien une : il est hors de question que le pere ou les fils soient visibles des autres sessions tant que l'instruction n'a pas terminé, pas plus que les données doivent rester dans un état incohérent en cas de plantage de l'appli durant l'instruction. je ne parle pas non plus de ce qu'il doit se passer si une ligne de père ou de fils est lockée durant la requête, et qu'un timeout est levé en plein millieu. si le sgbd ne fait pas ça, il ne peut pas être candidat au nom de SGBDR. point barre.

Ils n'utilisent pas les transactions offertes par le SGBDR, nuance:

effectivement, ils n'utilise pas les éventuelles fonctionnalités du SGBD, c'est une nuance qu'il est juste de souligner

Et je pense que c'est là ce que Masklinn, Chaos... cherchaient à t'expliquer

Et c'est justement ce que je leur explique depuis le départ : c'est pas parceque ton SGBDR ne dispose pas des instruction "begin tran / commit / rollback / savepoint et autres" qu'il ne fait pas en interne les transactions nécessaires pour garantir l'intégrité des données relationnelles.
 
Alors après, si on s'en sert pas, c'est encore une autre histoire.
Si on ne veut pas que le SGBDR fasse de micro-transactions, on enlève aussi toutes les FK de la base, et fourre des table hints sur toutes les instructions DELETE/UPDATE.INSERT de façon à empêcher les locks/transactions atomiques.
 
Ensuite, on peut tout à fait stocker une base relationnelle dans un SGBD qui n'est pas relationel (DBase par exemple, c'est un peu vieux comme le monde, et y'a plein de bases relationnelles qui l'utilisent), mais DBase n'est en aucun cas un SGBDR : il ne permet même pas l'intégrité référencielle, ce qui est un peu de minimum syndical pour un SGBDR.

bon je viens soudainement de me rappeler pourquoi j'ai magicbuzz en liste noire

 
C'est ce que je disais.    
 
Si tu as besoin des transactions pour un système bancaire (ca serais domage qu'un "virement" soit fait incomplêtement le débit et pas le crédit par exemple) , tu as pas forcément besoin des transactions pour un forum. Si ton forum sature, ca t'intéresse plus de servir un max de requetes sans transactions pour que le forum soit plus fluide, et MySQL fait cela à merveille. En fait les accidents sont plutot rares, si le serveur ne tombe pas en panne souvent. Pas de transactions ca veu dire quoi s'il y à une panne ? le dernier message à disparu du forum ? pas très grave...
 
Donc qui dit besoins différents, dit solutions différentes...
 
Enfin si on on reviens à la question initiale, le fait est que s'il s'agit d'une application professionnelle, il serais sans doute judicieux d'utiliser les transactions...
 

On s'en fout de ça, le débat avec MagicBuzz était sur ce qui constitue un RDBMS, une DB non transactionnelle c'est stupide et MySQL est le WhiteSpace des dbms

Ca n'est pas du tout le sujet de discussion initiale, et c'est un hors sujet, et ce genre de propos, c'est la différence entre des personnes qui placent tout sur la théorie et d'autres qui doivent trouver des solutions pratiques aux problemes. Je ne voi pas tellement l'interêt de vomir systèmatiquement sur MySQL, si MySQL ne répondait pas à un besoin précis (comme par exemple servir un très grand nombre de requetes sans prendre trop de ressources sur les serveurs), il ne serais pas utilisé...
 
Moi les discussions "académiques" ca m'intéresse pas du tout, ca fait très longtemps que j'ai quitté l'école et je ne suis pas prês de rentrer à l'academie française...  
 
Je croyais qu'il y à avais un topic "blabla" pour les trolls, je voi que tous le forum semble est devenu un 'forum blabla', avec 90% de trolls, tout cela est certainement très divertissant...    

Dans un monde parfait ce serait effectivement le cas, malheureusement nous sommes ici dans ce qu'on appelle la réalité, et il est extrèmement rare que les choix optimums y soient faits.

Choix selon tes critères. (Théorique)
 
Si tu doit par exemple administrer une batterie de serveurs pour les forums massivement fréquentés (meme cas de figure pour Ebay qui ont une batterie de serveurs qui doivent servir une application dynamique très similaire à une application forum), vaut il mieux etre en mode non transactionel avec +50% de débit, ou payer 50% de serveur, en plus, donc de cout en plus, pour éviter le risque de perdre 1 message une fois par an ????  
 
Rassure moi, tu es prof ? étudiant ? ou tu vie au Pays des téletobbies ?  

La prochaine fois je te prierais de lire les posts avant de répondre à côté

Non j'ai bien lu
 
Dans certain cas, utiliser MySQL sans les transaction peu être un choix "optimum"
 
Evidement ca dépend de ce que tu appelle "Optimum", ca ne veux pas dire la meme chose si tu es étudiant, ou directeur en entreprise.
 
-> Etudiant/Prof/Amateur : "Tous ceux qui utilisent un SGBD sans les transactions sont des ignares proche de la débilité mentale"
 
-> Patron de Ebay : "L'utilisation de MySQL sans les transactions nous à fait économiser 50% de nos couts d'hébergements, soit environ 1 Million de Dollars par an", que nous avons pu réinvestir dans le Marketing et donc écrabouiller tous les autres concurents qui eux utilisent les transactions, mais n'ont pas de budget Marketing, d'ailleurs tous nos concurrents on déposés le bilan faute de visiteurs, et Ebay à désormais le quasi monopole. Merci MySQL."
 
Tout est relatif...

Le problème ici c'est que tu considères MySQL/MyISAM comme étant le plus rapide en absolu (sans considérer la validité/sécurité des données) dans toutes les situations...

• MySQL n'est pas le seul DBMS existant, au delà des classiques Oracle, SQLServer et PostgreSQL on trouve Firebird, DB2 et Teradata par exemple.
• Les DBMS évoluent, MySQL est parti de la vitesse et commence enfin à ajouter des fonctionalités, les autres (Postgres principalement) ont pris le chemin inverse, et ça se sent lourdement sur les dernières versions.
• Il faut bien étudier le besoin de performance, des DBs plus fournies en fonctionalités permettent d'avoir de meilleures vélocités de développement et plus de sûreté (via une meilleure validation des contraintes)
• Il faut également étudier les potentiels problèmes de scalabilité, MySQL monte très mal en puissance tant en augmentant le nombre de CPUs d'un serveur qu'en partitionnant, et c'est encore plus visible face à un DBMS spécialisés dans le hautement parallèle comme Teradata.
• Les types de requêtes influencent également grandement les performances des DBMS, MySQL/MyISAM a des perfs abysmales quand on a un grand nombre de deletes par exemple.

En bref, contrairement à ce que tu impliques depuis le début même quand on se fout de la sécurité des données MySQL/MyISAM n'est pas nécessairement la bonne réponse, tout simplement parce qu'il n'y a pas de "bonne réponse" absolue dans ce cas.

Tu es encore dans la théorie la plus totale, la preuve est est que tu cite FirebirdSQL, que je connais très trés bien depuis nombre d'années (à l'époque InterBase), qui est un excellent SGBD (spécialement bien adapté pour les applications embarquées par exemple), mais qui se trouve être un des produits le plus lent du marché sur les transactions simples d'une part, et qui ne sait certainement pas fonctionner sans transactions, parce que il gère non seulement les transactions mais aussi les "génération' , ce qui est une technologie extrémement intéréssante dans certains cas (l'OLCP par exemple) mais sans aucun intéret pour les transaction simples sans tolérance de pannes.
 
Pour le reste de tes affirmations tu continue d'ignorer totalement les problêmes de "couts" (licence, materiel, humain...) , comme par exemple en citant Teradata.
 
Tu aura beau tourner le probleme dans tous les sens, fait des tests et tu verra qu'en mode non transactionnel MySQL est quasiment imbatable sur des petites machines en batteries, sachant que les petites machines en batteries coutent beaucoup moins cher que des grosses machines avec de gros SGBD très très cher.
 
Les hébergeurs ont déjà fait tout ces tests, il ont conclus que le moins cher pour servir des tonnes de requetes le moins cher possible c'est mysql.
Tu peux trouver des hébergements avec d'autres SGBD, mais il faudra payer pour cela, parce que soit il faudra payer la licence du SGBD, soit parce que le SGBD prendra beaucoup plus de ressources sur le serveur, et il faudra un serveur beaucoup plus cher.
 
Et la situation à effectivement évoluée, en version 5 avec sa gestion évoluée du cache, et son exploitation en mono process multi utilisateurs (meme technologie que Sybase) en fait un monstre capable de servir un nombre colossal de requetes pour une consomation mémoire et CPU proche du ridicule
 
J'ai du moi meme faire des tests récement sur une très grosse application en production avec une très grosse charge utilisateurs (une tonne, donc quand on me dit que MySQL ne tiens pas la charge soit disant ca me fait bien rigoler), et on s'est rendu compte que MySQL était devenu tellement performant en version 5 que le SGBD consomait désormais non plus jusqu'à 50% du temps CPU total Appli + SGBD confondu mais environ 5% !!!!.
 
 
 
 
 

bon, masklinn, tu retrouves le lien où des tests montrent que postgre est plus rapide que mysql dans bien des cas (plutôt que dire "oui mais toi tu parles en théorie" "ah mais nan gnagnagna" "miroir magique qui renvoie tout" ), et on en parle plus, mais arrêtez, sans déconner