Il manque une ligne non?

L'application web appelle le serveur A, alors que la base de donnée est sur le serveur B?

edit : pour ceux qui on compris, quand c'est un auto pebkac on vote BEDP, et pour ceux qui n'ont rien compris, on s'abstient en attendant es explications.

Lapin compris.

Visiblement il regardait l'application serveur d'un serveur A mais l'application web d'un serveur B. C'est un auto-pebkac.

c'est comme ca que je le comprends aussi. il faudrait que clem puisse demander une réécriture des PEBKAC avant publication...

On retente les trolls SGBD ( http://www.pebkac.fr/pebkac/6565/#comment_71052 ) ou ça ne vous plait pas ? ( Je ne suis pas super inspire...)

Vaut mieux pas les inviter, les trolls SGBD ont en général des griffes plutôt acérées :)

(oui, ceci est un jeu de mot pourri et tarabiscoté!)

Cette remarque acide n'est pas digne de toi.

@Laocoon je ne sais pas si tu avais compris, je faisais un jeu de mot entre inspire-aspire-ACER...

"PostgreSQL c'est lent" => CTLP Quand on ne sait pas gérer un SGBD on fait autre chose, du tricot par exemple...

Ça fait quoi « lapin compris » au passé ? Ça résumerait bien ma vision des commentaires de ROB…
« Civet compris » ?

Tant que ce n'est pas du tricot avec des pointeurs ou des merges git :p

Non, Civet compris, c'est du futur.
Au passé, ça fait Lapereau compris ^^

Oracle tue des ours ! First blood !

J'allais le dire.. PostgreSQL n'est pas lent : il est scalable.

C'est à dire qu'il est très légèrement plus lent qu'un MySQL dans un environnement de test, mais ses performances ne se dégradent pas sous la charge, et donc il est en vérité effroyablement plus rapide qu'un MySQL en environnement de production.

J'ai aussi trop souvent vu des développeurs râler contre la lenteur du SGBD... avec aucun index (ou inutiles)... ou avec des transactions qui bloquent tout plusieurs secondes.

Et quand c'est mal expliqué ou que ça trolle, on peut voter CTLP :)

Pour ceux qui n'ont pas compris, la majorité de problème a été expliqué.
J'avais 2 applications qui doivent partager une même base de données, si l'un va chercher sur un serveur A et l'autre sur un serveur B, elles n'arriveront à rien et ça causera confusion auprès du développeur (ici, c'est moi...).

Pour ceux qui pensent que c'est un Troll, le choix entre MySQL et PostgreSQL est uniquement établi sur les performances, pas sur les fonctionnalités d'un SGBD.
PostgreSQL propose un bon nombre de concepts intéressants, mais qui ne me sont pas utiles ici.

L'autre PEBKAC auquel je fais référence (non posté il me semble) est celui dans lequel je suis entièrement convaincu que PostgreSQL est 10 fois plus rapide que MySQL mais en faisant récemment quelques benchmarks, il s'avère que c'est plutôt l'inverse... donc j'avais m*rdé quelque part.
Je peux aussi me tromper sur ce PEBKAC si PostgreSQL est suffisamment optimisable pour arriver aux perfs de MySQL/MyISAM, mais mes recherches ne m'ont rien donné de convaincant.

Mais voter ici CTLP revient à dire que 2 applications peuvent utiliser 2 base de données différentes en tant que même base de données sans configuration spécifique (donc sans synchronisation, réplication ou toute autre système du genre).

Pour ceux qui trouvent que c'est mal expliqué, je suis d'accord, attendez de voir les suivants...

@OzoneGrif Merci pour ces précisions, je ne suis pas sûr que ça me fera changer d'avis car ce n'est pas prouvé et dire que ça fonctionne mieux en production est très subjectif. Cependant, ta remarque est pertinente et je la retiens.
C'est toujours mieux quand vous sortez des arguments...

Je demande à voir tes benchs moi...
Car c'est pas bien compliqué de montrer avec un bon schéma de table et un jeu de données que PostgreSQL n'a rien à envier à MySQL.

On arrive à récupérer un peu de performance sous MySQL sur certains traitements en privilégiant les mots-clés propre à ce SGBD, mais on est encore loin de pouvoir tenir la charge.
Une bonne base MySQL, j'entends bien conçue et entretenue, peut tenir jusqu'à environ 800-900mio de données. Au delà c'est un calvaire pour exécuter des requêtes en un temps convenable.
Avec PostgreSQL on est plutôt dans une courbe de performance entre 200mio et 3gio.

PostgreSQL c'est le bien car il y a PostGIS

> Pour ceux qui pensent que c'est un Troll, le choix entre MySQL et PostgreSQL est uniquement établi sur les performances.

Un de mes anciens responsables refusait de passer à un SGBD relationnel car d'après lui DBase est beaucoup plus performant que MySQL, SQL Server et PostGr... Il avait fait des benchmarks et donc son choix scientifique était indiscutable.

Oui... effectivement, sur une simple table et sans calculs, DBase s'en sort plutôt bien... c'est du fichier à plat indexé. Mais ajoutez lui des jointures, des groupements, des conditions complexes, et quelques milliers d'enregistrements : au revoir les performances !

Une base de données est une mécanique précise. Et quand on est pas expert de cette mécanique, il est quasi-impossible d'en faire un benchmark reflétant la réalité. C'est pour cette raison que le rôle de DBA est respecté dans les grosses sociétés.

Dans ma société les DBA servent a rien !!!

Je suis parfaitement d'accord avec OzoneGrif sur le benchmarking des bases, il faut parfaitement connaitre leur fonctionnement et leurs subtilités pour faire un bon benchmark.

Je me contenterai de rappeler pour les râleurs de MySQL, que c'est la solution BD que YouTube a choisie !!! Enfin, je dis ca, je dis rien !!!