MySQL / PostgreSQL / MariaDB

Bonjour à vous,

Je travaille sur un projet perso de serveur de jeu, pour cela je dois gérer les joueurs (Grade, Permissions, Préférences, Statistiques...) via une BDD. Ces informations devront être accessibles facilement depuis un site Web (PHP), mais surtout en jeu (Java).

Pour ce faire j'utilisais jusqu'à maintenant une BDD MySQL (hébergée chez alwaysdata.com). Pour l'instant je n'en suis qu'aux tests, mais j'ai beaucoup de soucis avec MySQL:
- lenteur des requêtes (dans mon code en Java, j'insère les données sur la BDD et je souhaite les récupérer tout juste après (dans une autre classe par exemple), mais problème, les données n'ont pas eu le temps d'être ajoutées). Ceci dit le problème vient certainement de l'hébergement gratos :)
- erreurs à gogo (colonne inconnue alors qu'elle existe, je renvoie la requête et ça fonctionne)
- déconnexions intempestives (le programme en Java tourne sur un serveur et se la connexion à la BDD s'effectue au démarrage, et n'est fermée qu'à l'arrêt, si il n'y a pas transfert de données pendant un certains temps, la connexion se ferme. Problème, si à chaque fois que j'effectue une requête je dois vérifier que la connexion est ouverte, cela est extrêmement long!)

Bref, pour mes premiers pas avec un base de données, ça n'a pas été une grande réussite. J'ai donc cherché une alternative à MySQL, et je suis tombé sur PostgreSQL (certes plus complexe, mais d'après certains, plus évolué).
Voilà donc mon problème: pour une infrastructure d'environ 500 joueurs connectés en même temps (100 au début, mais on espère arriver à 1000 constant, et par conséquent une table "globale" recensant tous les joueurs, qui pourra dépasser les 50 000 / 100 000 joueurs à l'avenir), pensez-vous que PostgreSQL est intéressant (j'ai lu que pour les petites bases de données, MySQL est plus rapide) ? Je veux miser sur la rapidité des requêtes qui seront nombreuses, et sur la fiabilité (une erreur SQL est tout le programme foire, et les tous les joueurs sont déconnectés), et moins sur la complexité des tables. Quel est également votre avis sur MariaDB, est-ce une alternative convenable?

Désolé pour toutes ces questions, et merci de m'avoir lu jusqu'ici! :D

Oxore

Si les données sont principalement à vocation de partage entre joueurs, sans que leur stockage physique soit une priorité (par exemple si 90% des données sont volatiles) alors privilégiez un SGBD qui propose des fonctionnalités InMemory.

Cela résoudra les problèmes de vitesse d'insertion/restitution puisque les données ne transiteront pas sur le disque, mais resteront en mémoire.
Attention, en contrepartie, suite à un arrêt brutal du serveur, toutes les données ne seront pas forcément retrouvées/synchrones. Il faut donc user sans abuser de cette fonctionnalité.

Salut
J'ai pas encore travaillé dans ce genre de projet mais je pense que trop solliciter la BD n'est pas la meilleur façon.
Je m'explique.

• La BD enregistre les paramètres du jeu, les joueurs et leurs étapes.
• lorsqu’un joueur se connecte, il charge son statut sur le client
• lorsqu'un joueur atteint in niveau on enregistre son statut et on le charge au besoin
• lorsqu’un joueur quitte, son statut est enregistrer dans la BD

Avec ce schéma c'est le client qui est beaucoup sollicité et le SGBD sur le serveur n'enregistre que les états. Pour ce qui est de la vérification de la connexion je pense que c'est bon ainsi, cela réduit l'utilisation des ressources.
@+

Bonjour, je vous propose ici un sondage global sur les SGBD SQL ?

Citation:

---

Envoyé par Oxore

Bonjour à vous,

Je travaille sur un projet perso de serveur de jeu, pour cela je dois gérer les joueurs (Grade, Permissions, Préférences, Statistiques...) via une BDD. Ces informations devront être accessibles facilement depuis un site Web (PHP), mais surtout en jeu (Java).

Pour ce faire j'utilisais jusqu'à maintenant une BDD MySQL (hébergée chez alwaysdata.com). Pour l'instant je n'en suis qu'aux tests, mais j'ai beaucoup de soucis avec MySQL:
- lenteur des requêtes (dans mon code en Java, j'insère les données sur la BDD et je souhaite les récupérer tout juste après (dans une autre classe par exemple), mais problème, les données n'ont pas eu le temps d'être ajoutées). Ceci dit le problème vient certainement de l'hébergement gratos :)
- erreurs à gogo (colonne inconnue alors qu'elle existe, je renvoie la requête et ça fonctionne)
- déconnexions intempestives (le programme en Java tourne sur un serveur et se la connexion à la BDD s'effectue au démarrage, et n'est fermée qu'à l'arrêt, si il n'y a pas transfert de données pendant un certains temps, la connexion se ferme. Problème, si à chaque fois que j'effectue une requête je dois vérifier que la connexion est ouverte, cela est extrêmement long!)

---

la grande joie de MySQmerde... A lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

Citation:

---

Bref, pour mes premiers pas avec un base de données, ça n'a pas été une grande réussite. J'ai donc cherché une alternative à MySQL, et je suis tombé sur PostgreSQL (certes plus complexe, mais d'après certains, plus évolué).
Voilà donc mon problème: pour une infrastructure d'environ 500 joueurs connectés en même temps (100 au début, mais on espère arriver à 1000 constant, et par conséquent une table "globale" recensant tous les joueurs, qui pourra dépasser les 50 000 / 100 000 joueurs à l'avenir), pensez-vous que PostgreSQL est intéressant (j'ai lu que pour les petites bases de données, MySQL est plus rapide) ? Je veux miser sur la rapidité des requêtes qui seront nombreuses, et sur la fiabilité (une erreur SQL est tout le programme foire, et les tous les joueurs sont déconnectés), et moins sur la complexité des tables. Quel est également votre avis sur MariaDB, est-ce une alternative convenable?

---

MariaDB c'est la même merde que MySQL mais en plus libre....

Citation:

---

Désolé pour toutes ces questions, et merci de m'avoir lu jusqu'ici! :D

Oxore

---

PostGreSQL est sans acun doute le meilleur SGBDR libre open source.

Mais tous ces outils OpenSource ont le même inconvénient majeur : leur incapacité en pratique de fonctionner 24h/24 7j/7.
Par exemple leboncoin utilise un batterie de plus de 100 serveurs PostGreSQL pour satisfaire la charge là ou un seul Serveur Oracle ou SQL Server suffit et malgré cela ils arrêtent les serveurs la nuit pour faire la maintenance courante.
Cela n'existe pas sur les serveurs comme oracle ou SQL Server ou tout est fait à chaud et en pleine production...

Donc ta question est : tes utilisateurs vont-ils jouer la nuit ?

Si oui, alors oriente toi vers SQL Server qui est 24 fois moins cher qu'Oracle et présente différentes éditions pour la montée en charge :

• EXPRESS gratuite pour démarrer
• WEB dès qu'il y a quelques dizaines d'utilisateurs (cout : 30 euros par mois)
• AZURE, standard ou Enterprise si la montée en charge est forte

A +


l

en bref j'arrive de DB2 IPOWER 2500 user en web 150 user interactif. réponse 3 nanoseconde sur AS400 natif 40 job (instance) a dispos pour le web et je n'arrive pas à saturer.

j'ai fait un bascule de site web de DB2 sur PostgreSql Sur un serveur Linux je n'ai eu aucun problème je tourne avec la 9.5 ---> en attente de validation

je me suis attelé pour tester MariaDB 10.2 j'ai retrouvé tout mes petits , toujours sur le même type de serveur , dans mes testes je n'ai pas remarqué de problème , sauf la doc , elle n'ai pas en français , mais un livre vient de sortir chez eyrolles pour aller beaucoup plus loin. pour mon compte faire de la multi-instance.....

l'un comme l'autre pour passer à un niveau supérieur il faut prendre la version entreprise.

mais pour du gratuits opensource je ne vois pas la différence .

pour moi j'avais besoin de confirmer la possibilité de basculer sur un serveur Linux un site web a grande disponibilité, et des temps de réponse honorable. il n'était pas question de rivaliser avec l'AS400,
mais de répondre a un cahier des charges . c'est du CGI c++ avec tout cela comporte templates... etc ... de plus nous voulons faire du temps réel et l'on s'attaque avec les nouvelles technologies websockets a rendre ("libwebsockets dans Linux mais il y a pendant sur win" puisque c'est un accords de l'ensemble des grands acteurs depuis janvier 2016) pour le moment avec des testes simples cela commence à fonctionner.

donc mon jugement est qu'il faut utiliser avec l'un comme avec l'autre c'est en rentrant vraiment dans le code faire vos lib d'accès et remonter avec des macros afin de n'avoir que le metier dans vos applications . pour C++ PGSQL une interface de programmation très structurer et opérationnel ou la libconnect pour Mariadb en c++ les deux en mode interactif font le même travail. en mode asynchrone avec Apache aussi .
l'un comme l'autre il vous faudra retrousser les manches. aujourd'hui condamnée MariaDB est une erreur pour preuve l'ensemble des distributions on fait le pari sur MariaDB non pas qu'il rejette Posrgresql mais on lâché Mysql et MariaDB s'en vas rejoindre les grands acteurs de base de données . pour cela regarder l'évolution 10.2 --> et allez constater les notes.

des bugs l'un comme l'autre mais n'ont attraits qu'a des chose mineurs souvent sur les betas .... de toutes façons ils y aura toujours un patch soit pour corriger soit pour améliorer.

je ne pense pas qu'il y ai un match entre les deux .

après si vous voulez travailler sur des milliards de données en pathroug ou avec des réplications peut-être si j'ose me permettre avec un Ipower qui incorpore as400 et( Linux et win qui ne sont que des carte dédier) là vous aborder un autre monde par exemple celui de la finances ou la sécurité maximum est exiger la vitesse ... et le prix aussi .....

supérieure fonctionnalités richesse et de soutien pour SQL complexe Postgres est seulement utile lorsque vous déplacez une grande partie de votre logique d'application à la base de données. Ceci est un anti-modèle, dans le monde d'aujourd'hui. Cela a été utile à un moment où la plupart de la logique d'application résidait dans la base de données, emballés comme les procédures stockées et les fonctions et les déclencheurs et tout ce que la base de données particulière a été soutenu, et les clients et les serveurs d'applications étaient une couche mince sur le dessus de la base de données. A cette époque, était postgres ans avant toute autre chose, y compris la plupart des offres commerciales.

Mais ce n'est plus le cas. En règle générale, une grande partie de la logique d'application est le code destiné à être exécuté en dehors de la base de données. Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer, conduisant à un désordre ingérable. Une raison de plus pour aller avec MariaDB - les limites de la base de données agissent vers votre intérêt, ce qui est de garder toute logique liée à un seul endroit - le code source.

Citation:

---

Envoyé par JPLAROCHE

supérieure fonctionnalités richesse et de soutien pour SQL complexe Postgres est seulement utile lorsque vous déplacez une grande partie de votre logique d'application à la base de données. Ceci est un anti-modèle, dans le monde d'aujourd'hui. Cela a été utile à un moment où la plupart de la logique d'application résidait dans la base de données, emballés comme les procédures stockées et les fonctions et les déclencheurs et tout ce que la base de données particulière a été soutenu, et les clients et les serveurs d'applications étaient une couche mince sur le dessus de la base de données. A cette époque, était postgres ans avant toute autre chose, y compris la plupart des offres commerciales.

Mais ce n'est plus le cas. En règle générale, une grande partie de la logique d'application est le code destiné à être exécuté en dehors de la base de données. Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer, conduisant à un désordre ingérable. Une raison de plus pour aller avec MariaDB - les limites de la base de données agissent vers votre intérêt, ce qui est de garder toute logique liée à un seul endroit - le code source.

---

Autant de bétise en si peu de mots, il y a longtemps que je n'avais vu cela...

Expliquez moi donc pourquoi les SGBD relationnels comme SQL Server ont une croissance positive largement supérieure en nombre d'installation aux autres formes de SGDB ???

Pour info (état du marché 2016) étude gartner :
"
The DBMS market had strong growth of 8.1% in 2016, driven by organizations expanding their data management portfolios. The semi-structured DBMS segment continued its strong above-market-rate growth at 76.6%, while RDBMS grew 6.4%. Pre-relational era DBMS continued its decline
"

En nombre d'installation les SGBD relationnels restent en tête devant les "noSQL".

A +

Citation:

---

Envoyé par JPLAROCHE

En règle générale, une grande partie de la logique d'application est le code destiné à être exécuté en dehors de la base de données. Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer, conduisant à un désordre ingérable. Une raison de plus pour aller avec MariaDB - les limites de la base de données agissent vers votre intérêt, ce qui est de garder toute logique liée à un seul endroit - le code source.

---

Vos propos sont pour le moins confus.
Quoi qu'il en soit, affirmer que les limites d'une base de données sont un atout est plus que surprenant !
Aucun code source n'est capable de garantir l'intégrité d'une base de données multi-utilisateurs, seul le SGBD peut le faire, voilà déjà une bonne raison s'il n'en fallait qu'une, de choisir une BDD moderne et performante, or Maria DB a environ 15 ans de retard sur bien des sujets (gestion des verrous, partitionnement, collations, fonctions OLAP, requêtes récursives, normes SQL...)

Citation:

---

Envoyé par JPLAROCHE

Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer,

---

Non, c'est tout l'inverse. Avoir la logique métier dans le code applicatif, ça oblige parfois (souvent) à dupliquer la même logique métier dans différents langages, en différents endroits, voire par différentes équipes.
Donc plus de code, donc plus de bugs, donc plus de maintenance.

Tout n'est pas cependant binaire, et il faut trouver le bon compromis, mais c'est pour cela que les architectes existent, enfin... quand ils existent...

merci d'avoir repondu,

je ne pense pas que vous pouvez me juger ne me connaissant pas. mais pas grave .... quand à écrire des applications je n'ai plus de leçon a recevoir , et je maintiens que la base de données pour moi ce limite a géré des datas , je n'en fait pas un sous langage dans le quel je code des règles , c'est déporter les problèmes, une base de données doit être rapide et fiable ou plus de 2000 connections peuvent être consécutive et des temps de réponse en dessous de la seconde , venant du monde IBM avec DB2 . les cagasses de réglage pour géré les cluster moi ca me gave ou les buffer , sans parler des vacum.
une base de données doit être disponible point barre, lors d'un projet je me concentre sur quel est le besoin pour l'entreprise , comment y répondre tout en restant le plus simple possible et en tenant compte de la maintenance, si je doit aussi inclure un temps non négligeable sur la maintenance d'un serveur ( service ).... par contre je préfère me concentrer sur comment articuler autour de mon dictionnaire de définition et comment attribuer les tables et logique (vue) voir les joins (vue) de tel manières que cela soit le plus rentable dans les applications. Un model de référentiel basé sur la théorie des ensembles .
alors si le gestionnaire de base de données est fiable et reconnue comme tel , et surtout ne me demandez pas de mettre une ou deux personnes pour gérés ce service , le prix n'est pas un problème , le problème est que lorsqu'une base de données finit par invalidé ses tables ??? choses pour moi inadmissible. et par la casse la cohérence avec l'ensemble du transactionnel , qu'il faut passez plus de temps a récupérer (si c'est encore possible) les datas .... pour ça j' invalide le service proposé.

je me fou de savoir si PostgrEsql ou MariaDB est le meilleurs , si je veux confier une taches sur PC (serveur type PC) je me contenterais du solide bien gras.

quand a MariaDB , Amazone , Google , les éditions Linux, l'on pris alors vous pouvez me dire n'importe quoi mais ce sont des références. et si j'ai Défendu MariaDB ce n'est pas pour convaincre qu'il est le meilleurs mais bien pour voir si vous alliez parlez de compétitivité de fiabilité , de simplification de maintenance .... et en tout honnêteté. si vous êtes convaincue et aveugle sur vos choix, moi pas , je n'ai pas d'action chez MariaDB ni de rancune sur PostgrEsql , j'ai pratiqué les deux .

quand à MSsql c'est pareil j'ai été aussi obligé de travaillé avec quand je vois tous le bastring qu'il faut mettre en œuvre.....

bref dans tout cela sans parler des problèmes de dérégulation dut au matériel.... vous m'auriez intéressés si vous m'aviez dit que ACID était un sujet clos aujourd'hui les problème sont réglés, mais vous aviez abordé autre chose.... ce n'est pas la cas.

quand à la déportation de la programmation dans la base de données , sur des applications qui comporte plus d'un millions de lignes , c'est bannis ce genre de trucs .

par contre je conçois parfaitement que l'on puisse ce servir d'un base de données sql avec des regles ou procedure pour bâtir un L4G avec un langage fondamental. mais là c'est une autre histoire.

et encore SQL n'est qu'un moteur . rien d'autre. soit il tourne soit il ne tourne pas. et pourquoi on s'en sert et surtout comment on s'en sert.

@bientôt

Citation:

---

Envoyé par SQLpro

Autant de bétise en si peu de mots, il y a longtemps que je n'avais vu cela...

Expliquez moi donc pourquoi les SGBD relationnels comme SQL Server ont une croissance positive largement supérieure en nombre d'installation aux autres formes de SGDB ???

Pour info (état du marché 2016) étude gartner :
"
The DBMS market had strong growth of 8.1% in 2016, driven by organizations expanding their data management portfolios. The semi-structured DBMS segment continued its strong above-market-rate growth at 76.6%, while RDBMS grew 6.4%. Pre-relational era DBMS continued its decline
"

En nombre d'installation les SGBD relationnels restent en tête devant les "noSQL".

A +

---

votre jugement ????
parce que sur pc il faut des services qui savent géré des données . afin de permettre de faire des études aux grands utilisateurs. (pour cela que noSQL prend du galon)
mais pour les applicatifs fermer (aux utilisateurs) c'est une autre chose.

demain certainement prendre le meilleurs de SQL et de noSQL pour faire une autre approche , ce qui eviterait les exportations .....
@bientôt

Citation:

---

Envoyé par aieeeuuuuu

Non, c'est tout l'inverse. Avoir la logique métier dans le code applicatif, ça oblige parfois (souvent) à dupliquer la même logique métier dans différents langages, en différents endroits, voire par différentes équipes.
Donc plus de code, donc plus de bugs, donc plus de maintenance.

Tout n'est pas cependant binaire, et il faut trouver le bon compromis, mais c'est pour cela que les architectes existent, enfin... quand ils existent...

---

oui si vous travaillez sur pc et que avez plein de langage .... (moi perso je ne suis pas pour avoir plein de langage).

je suis d'accords avec votre dernière phrase tout n'est pas binaire ....

nous avons utiliser une Méthode AXIAL combiné à Merise c'est une méthode américaine qui permettait de raisonné en introduisant la théorie des ensembles tant sur la définition de la granulation de la base de donnée que sur les modules (programme) et d'avoir une interaction entre eux.

ce qui permettait de n'avoir pas de duplication de logique de métier. ce que je trouve de dommage c'est qu'IBM n'est pas diffusé et gardé jalousement ( puisque propriétaire ) ... bref on peut pas refaire le monde.
merci d'avoir répondu.

Citation:

---

Envoyé par escartefigue

Vos propos sont pour le moins confus.
Quoi qu'il en soit, affirmer que les limites d'une base de données sont un atout est plus que surprenant !
Aucun code source n'est capable de garantir l'intégrité d'une base de données multi-utilisateurs, seul le SGBD peut le faire, voilà déjà une bonne raison s'il n'en fallait qu'une, de choisir une BDD moderne et performante, or Maria DB a environ 15 ans de retard sur bien des sujets (gestion des verrous, partitionnement, collations, fonctions OLAP, requêtes récursives, normes SQL...)

---

bonjour,
la contrainte référentiel fait partie intégrante d'une BDD . enfin à mon humble avis. sinon ce n'est plus une BDD
mais la logique de programmation ne doit en pâtir sous prétexte de la BD vas tout résoudre.
je ne sais pas mais dans le service tout était testés , et même plus . je ne vends pas à l'entreprise qui m’emploie un service finit a 90% .

vous devriez aller voir MariaDB et leurs dire que cela a quinze ans et que rien n'a été réécrit ni repensé , ni apporté de nouvelle fonction et fonctionnalité,
D'autre part ce n'est pas parce-que vous gardez des mêmes nom de fonctions qu'elle ne peuvent pas être réécrite. dans ma vie d’informaticien j'ai dut reprendre mon métier plusieurs fois pour introduire de fiabilité , de vitesse , de souplesse... , mettre du nouveau code pour améliorer la lisibilité etc....
vous avez la réponse tout est en ligne sur les sujets dont vous abordez.

ces articles sont sur le web
"MariaDB AX est une solution de stockage de données source moderne, ouvert extensible pour les grandes données d' analyse / OLAP : pas besoin de matériel complexe et coûteux"
"Récursivité avec les CTE Afin de parcourir un arbre ... mais cette technique est opérationnelle depuis Maria DB 10.2.2"
"possède de manière native des verrous. Ces verrous sont associés à des connexions à la base de données"
"En MariaDB , le jeu de caractères par défaut est latin1, et la valeur par défaut collation est latin1_swedish_ci (mais cela peut varier dans certains distros, voir par exemple les différences....) mais doit être définis UTF8 enfin sur arche c'est comme ça qu'ils le pensent", d'ailleurs comment ne pas mettre sa DB autrement quand UTF-8 ??? ...
allez sur l'onglet de mariadb "SQL Conformance" ou " Partitioning Overview"

encore une fois tout cela c'est pas le problème ..... aujourd'hui . bien-sur je parle de dernière versions avant cela ne m' intéressait pas .
@bientôt

Citation:

---

Envoyé par SQLpro

Autant de bétise en si peu de mots, il y a longtemps que je n'avais vu cela...

Expliquez moi donc pourquoi les SGBD relationnels comme SQL Server ont une croissance positive largement supérieure en nombre d'installation aux autres formes de SGDB ???

Pour info (état du marché 2016) étude gartner :
"
The DBMS market had strong growth of 8.1% in 2016, driven by organizations expanding their data management portfolios. The semi-structured DBMS segment continued its strong above-market-rate growth at 76.6%, while RDBMS grew 6.4%. Pre-relational era DBMS continued its decline
"

En nombre d'installation les SGBD relationnels restent en tête devant les "noSQL".

A +

---

il n'y a pas que vous qui avez un CV

vos articles sont bien conçu, mais et oui il y a un mais il commence à dater.... ( cela ne remet pas la valeurs de votre implications dans la mise à disposition d'une tel documentation (volumineuse) )
https://eng.uber.com/mysql-migration/ une explication mais remarquez que je ne me suis pas permis de critiquer PostgrEsql car c'est un produit qui pour moi est correct.
ça c'est des sujets intéressant qui aujourd'hui peuvent faire pencher la balance. (ps je n'ai jamais travailler pour UBER) et quand il parle de Mysql il sous entends MariaDB je ne peut pas vous données l'ensemble de l'article

entre autre je comprends pas que l'on ne puisse débattre à bâton rompu sans que les querelles de clochers ce mettent à sonner à tout vas.
car si il y a un lieu pour en discuter et faire avancé le schmilblick c'est bien sur ce forum
et pourquoi pas répondre à un problème bien souvent posé.(pour un temps car tout évolue )

dans votre article il fut un temps ou je vous ne vous aurais pas contredit sur le choix .... mais aujourd'hui on a le droit de ce poser des questions non sans importances

a+

Citation:

---

Envoyé par JPLAROCHE

https://eng.uber.com/mysql-migration/ une explication mais remarquez que je ne me suis pas permis de critiquer PostgrEsql car c'est un produit qui pour moi est correct.

---

Tout d'abord il y a extrêmement peu de migration de PG vers MySQL; En sus la société Uber n'a pas le monopole de la vérité et n'est pas en odeur de sainteté c'est le moins que l'on puisse dire et financièrement dans une situation dangereuse...
Mais l'article soulève quelques points que j'ai de nombreuses fois mentionnés : multiples versions de lignes dans les mêmes pages (donc augmentation artificielle du volume de la base), travail du VACCUM réellement bloquant... Ce qui le rend inapte à des base 24h/24 et 7j/7. Mais je dirais que c'est pire dans MySQL parce qu'il ne supporte pas la charge !
À me lire :
https://blog.developpez.com/sqlpro/f...PostGreSQL.pdf
§ 7 – Versions des lignes (MVCC)

Pour info dans SQL Server les versions de lignes sont conservées dans la tempdb (une base particulière d'objets transitoires et optimisée pour cela) et nettoyées automatiquement sans aucun blocage. La base elle même n'ayant jamais qu'une seule version de ligne, tout comme dans Oracle.

Ils parlent aussi de la réplication a des fins de Load Balancing en lecture.... Effectivement les mécanismes de réplications de PG sont orientés crash recovery et non pour faire de la lecture... Il y a même pire, ils n'ont pas été réellement étudiés pour faire de la réplication de données... Par exemple dans SQL Server, la réplication de données basée sur les transaction doit éviter de répliquer certaines transactions, comme par exemple les déclencheurs, les auto incréments ou les UUID/GUID...
Mais là encore la mauvaise qualité globale de MySQL fait que c'est jute pire !
Par exemple les mécanismes de verrouillage de MySQL sont très pauvres et assez bloquant, bien plus que sous PG...

Citation:

---

ça c'est des sujets intéressant qui aujourd'hui peuvent faire pencher la balance. (ps je n'ai jamais travailler pour UBER) et quand il parle de Mysql il sous entends MariaDB je ne peut pas vous données l'ensemble de l'article

entre autre je comprends pas que l'on ne puisse débattre à bâton rompu sans que les querelles de clochers ce mettent à sonner à tout vas.
car si il y a un lieu pour en discuter et faire avancé le schmilblick c'est bien sur ce forum
et pourquoi pas répondre à un problème bien souvent posé.(pour un temps car tout évolue )

---

Il ne faut jamais oublier que ces forums sont à l'origine des forums de discussion... C'est donc un peu comme au café et l'on ne demande pas le pédigrée de chaque intervenant avant qu'il ne prenne la parole. On trouve donc de tout, du mauvais, du très mauvais et même du bon ! Mais il convient de se faire sa propre opinion, et surtout d'aller lire des articles de fond, comme celui que vous venez de mentionner.

Citation:

---

dans votre article il fut un temps ou je vous ne vous aurais pas contredit sur le choix .... mais aujourd'hui on a le droit de ce poser des questions non sans importances

a+

---

J'en rajouterais même, je trouve désolant que PG alors qu'il a été longtemps et le chantre du normatif, commence à en dériver sérieusement... Quelques exemples parmi d'autres :

• Toujours pas de MERGE qui est la norme mais un imbitable "UPSERT" (alors que c'est une des principales demande des utilisateurs).
• Toujours pas de table temporaire globales
• Des CTE qui font deux choses à la fois (écrire et lire des tables)
• Pas de tables temporelles
• Pas d'IDENTITY ni de SEQUENCE
• Des déclencheurs toujours incapable de faire du FOR EACH ROW
• Toujours pas d'opérateur COLLATE
• Toujours pas de DATALINK
• Toujours pas les niveaux d'isolation READ UNCOMMITTED
• Impossible de changer le niveau d'isolation en cours de transaction
• ...

Pour ne parler que des aspects normatifs.....

mais c'est évidemment bien pire avec MySQL qui ne respecte rien de la norme et sort des résultats de requête totalement faux(les NULL transformés en blanc ou 0 par défaut, la date 0-0-0 !, le GROUP BY imbécile, la sauvegarde à chaud incohérent...) et passe sous silence la plupart de ces erreurs corrompant ainsi les données sans que personne ne s'en aperçoive, y compris pour les restaurations !

A +

Citation:

---

Envoyé par JPLAROCHE

demain certainement prendre le meilleurs de SQL et de noSQL pour faire une autre approche , ce qui eviterait les exportations .....
@bientôt

---

C'est déjà fait... Depuis longtemps !

• le In memory est arrivé dans les gros SGBDR,
• les bases documentaires sont aussi vieille que le DATALINK de la norme SQL implémenté sous oracle via BFILE et SQL Server via FILESTREAM/FILETABLE. Ceci combiné au "Full text Search" et pour certains SGBDR aux recherches sémantiques (SQL Server par exemple)
• Les objets peuvent être incorporées dans oracle ou SQL Server (l'un en java, l'autre en.net)
• Et SQL Server 2017 intègre désormais une module "graph database" au sein du moteur relationnel....

A +

je vous remercie d'abords d'avoir répondu, je trouve très constructif .

Citation:

---

Frédéric Brouard - SQLpro

---

il est exacte qu'il manque un bon nombre de chose à MariaDb (malgré que la dernière version de mariaDb à évolué dans votre sens, ce n'est plus InnoDB le moteur new XtraDB) ,c'est comme cela que j'aime les discutions, comme vous dites souvent les messages laissé ne vole pas toujours très haut ....

quand à SQL Server j'avoue ne pas avoir été dans l'étude jusque là .(mais intéressant a prendre en compte quand aux choix sur windows)

juste un mot sur noSql:
pour moi le NoSql pour moi c'est ni plus ni moins que d'avoir repris les fichiers a plats et permis de faire des tries ainsi que merge et de choisir les colonnes .. chose que l'on faisait déjà avant 1980 l'on permettait de choisir les colonnes et de faire des tries et comparaison plus fusion sur gros system ainsi remonter la sélection dans un csv sous lotus ... déjà on abordait le problème du cube.. 1985. bien-sur c'est un grand raccourcie ma façon d'expliquer NoSQL .
je préfère le terme « NoRel » (« not only relational »)



pour ma part la décision de choix d'un SGBD ne peut pas sur quelques lignes être prise. cela nécessite une vrais études. surtout si cela met en danger l'entreprise.
Maintenant si c'est pour géré un site avancé mais perso .... c'est de la discutions pour rien. sauf pour étudier les mécanismes.

comparaison:
(https://db-engines.com/en/system/Mar...r%3BPostgreSQL)
qui pour moi n'est pas une études constructive mais une approche je dit bien une approche . mais donne de grande lignes.


je développe pour ma retraite un moteur une couche au dessus de SQL afin de rendre la programmation lisible comme le journal tel un L4G (pour faire de la gestion d'entreprise), c'est mon os à ronger et je me sers de postgresql en ECPG) pour faire du CGI (c++) en temps réel avec la nouvelle norme Websoket (validé janvier 2016).

@bientôt

un article mais s'appuyant sur mariaDB 5.xxx dommage http://insights.dice.com/2015/03/19/...-mysqlmariadb/
et une difference entre Mysql et mariaDB http://insights.dice.com/2013/05/22/..._JS_AV_OG_RA_2

un autre article: reflétant les deux choix .

Citation:

---

Quelles sont les différences ?

Les deux projets sont profondément différents dans toute comparaison technique, et apportent leurs solutions à des problèmes différents.

PostgreSQL se concentre traditionnellement sur la robustesse et la fiabilité, l'intégrité des données et les fonctionnalités destinées aux développeurs d'applications. PostgreSQL dispose d'un planificateur de requêtes sophistiqué, capable de joindre efficacement un assez grand nombre de tables.

MySQL, d'un autre côté, s'est traditionnellement focalisé sur les applications web faisant surtout des lectures, souvent écrites en PHP, et dont le soucis principal est d'optimiser des requêtes très simples.

Si les deux projets se sont considérablement améliorés depuis que ces choix ont été pris, et si une comparaison objective est plus complexe que ce texte ne le laisse envisager, les bases techniques et l'esprit dans lequel travaillent les développeurs continuent de refléter ces choix du passé, au sein les deux projets.

---

@bientôt et merci d'avoir répondu.

Citation:

---

Envoyé par JPLAROCHE

j
quand à SQL Server j'avoue ne pas avoir été dans l'étude jusque là .(mais intéressant a prendre en compte quand aux choix sur windows)

---

C'est plus franchement vrai ça...

Citation:

---

Run SQL Server on your favorite platform
It's all about choice. Now, you can get SQL Server 2017's industry-leading performance and security on Windows, Linux, and Docker containers.

---

https://www.microsoft.com/en-us/sql-...ql-server-2017

Salut
Il faut vraiment être ignorant pour reprocher ces points...

Citation:

---

Envoyé par SQLpro

• Pas d'IDENTITY ni de SEQUENCE
• Des déclencheurs toujours incapable de faire du FOR EACH ROW

---

à PostgreSQL.
@+