Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Ca va être un bon amas de bullshit. Quand tu arrives à un rapport 1 pour 300k de performances sur deux technologies concurrentes avec un degré de maturité équivalent, c'est que soit tu es le messie qui a vu la lumière et le reste du monde est complètement stupide de ne pas l'avoir adoptée, soit tu ne sais te servir que l'une des deux et tu es totalement incompétent sur l'autre. Et je ne sais pas pourquoi mais mon instinct va plutôt en direction de la seconde possibilité
Et bien la meilleure façon de contrer ses arguments sera de faire un contre-test. Installer un serveur postgres, faire son parametrage et faire les tests. Debugger pour comprendre pourquoi la requete est longue ... etcEnvoyé par Sodium
Ca va être un bon amas de bullshit. Quand tu arrives à un rapport 1 pour 300k de performances sur deux technologies concurrentes avec un degré de maturité équivalent, c'est que soit tu es le messie qui a vu la lumière et le reste du monde est complètement stupide de ne pas l'avoir adoptée, soit tu ne sais te servir que l'une des deux et tu es totalement incompétent sur l'autre. Et je ne sais pas pourquoi mais mon instinct va plutôt en direction de la seconde possibilité
Note: clavier querty
le problème se serait pas plutôt qu'il y'a trop de SGBD sur le marché ?
entre du MariaDB, PostgresSQL, MongoDB, Cassandra...etc. Le pire c'est que dans la majorité des cas un simple sqlite répondrais au besoin de l'entreprise,
tout le monde ne cherche pas les meilleurs performances possible et vont déployer un cassandra sur 10 datacenter.
Dans tous les cas, si demain MongoDB ne me plait plus, je vais pas payer un support, Je suis un bon développeur donc mes requêtes mongo passe par une interface que j'ai codé, la migration vers un autre SGBD me prendrais que 2 jours max. je vais aller chez le concurrent et installer un cassandra ou un postgres.
Si des éditeurs de SGBD font faillite ce n'est pas l'open source le problème, c'est juste que le marché du SGBD sature. Pourquoi payer alors que le concurrent est gratuit et offre le même service ?
Je n'ai pas les compétences et je n'ai franchement pas que ça à faire. J'ai fait quelques fouilles et les seules sources indiquant un net avantage de SQL server sur Postgres sont des articles de SQLPro, auxquels je fais autant confiance qu'en la bible pour ce qui est d'expliquer l'apparition de la vie sur terre.
Bonjour,
Je ne comprends pas ces critiques autour de l'Open source.
En effet, moi même utilisateur de la DB MySql. J'ai dû faute d'avoir toutes les compétences utiliser les services tiers. J'ai donc payé. Je ne vois pas en quoi cela pose un problème.
L'importance de mes besoins ne justifie pas un contrat avec l'éditer. Mais si besoin, je ne vois pas non plus le problème. Il n'y a rien de caché, pas de surprise. Je sais ce que je demande en cas de besoin et quel en sera le coût. Je sais également ce qu'apporte un contrat avec les éditeurs.
Sincèrement, c'est quoi le problème. Je ne me sens pas volé, trompé ou escroqué.
Qui plus est : Il y a toujours un comparatif entre libre d'utilisation et version payante, mais aussi entre niveau de contrat. Il convient juste de lire...
Non ?
Bio Bio
Si on revient à la question de départ, vous versez quel pourcentage de votre chiffre d'affaire à PostgreSQL pour assurer son développement et sa pérennité ?
Si tu ne fais pas confiance à SQLPro et comme tu es Belge, tu peux te référer à J-Luc Hainaut de l'UNamur, qui est la référence en DB pour la Belgique francophone, tout comme Bersini est la référence OO en Belgique.
Ils ont monté une spinoff qui s’appelle ReveR, boite spécialisé dans le monde de la DB et leurs standards est MsSQL.
Et je dis ceci, en sachant que PostgreSQL est mon core bussiness.
Il faut toujours viser la lune, car même en cas d'échec on arrive dans les étoiles. O.Wilde
Mes Articles/Critiques :
Merise - Guide pratique
PHPExcel
PostgreSQL : Administration et exploitation d'une base de données
PostgreSQL : Entraînez-vous à créer et programmer une base de données relationnelle
Ce que je voulais dire, c'était que si tu as toute ta compétence sur une technos en interne sans support commerciale, tu es 100% dépendante d'elle. Si les personnes la détenant (quand ce n'est pas une seule ) se barre tu es tout seul. Autrement dis, d'un point de vue "gestion de risque" le risque est plus important. Hors il s'avère qu'une partie du boulot de ceux qui gèrent les projets c'est de maîtriser ces risques. A noter que je ne dis pas que les décision qu'ils prennent sont toujours d'un point de vue "gestion des risques" la bonne, mais c'est leur façon de pensée.
Mais... zéro o0
On a un serveur Postgres, l'hébergeur a fait l'install et on administre nous-même.
Je suis prête à parier très cher que l'utilisation de MsSQL vient principalement de l'habitude du monde Windows et de la présence commerciale très forte de Microsoft dans le monde professionnel
Ouaip !
Sans compter qu'il faut 5 admin windows pour faire le même travail qu'un seul admin Redhat ou Debian pour la même taille de parc. Troll mis à part, la boîte où j'ai fait ma mission précédente utilisait du AIX (cher), du Redhat (et payait le support annuel mais moins cher que AIX) et du Microsoft. Et je reviens sur le logiciel privateur. Je m'occupais de la centralisation des logs. Une ligne de logs windows, c'est 3ko à peu près, la moitié d'informations intéressantes et l'autre moitié un commentaire. Malgré la consultation du support MS +++ à plusieurs dizaines de milliers d'euros / an, l'ingénieur m'a répondu qu'il était impossible de supprimer la partie commentaire des logs à moins de modifier le code de windows, ce qui n'est pas possible non plus... Tant pis, j'ai doublé le nombre de relais et le volume du SAN de stockage des données, un coût en engendrant un autre... C'est ça, un logiciel privateur.
Mon cher Bio, tu es simplement le témoin de l'une de ces guerres de religions dont l'informatique a le secret: "Le produit X est génial, tout le reste c'est de la m... Et vice-versa"
S'il y a autant d'alternatives à disposition qui subsistent, c'est simplement que chacune d'elles répond parfaitement aux besoins spécifiques de certains.
Il va de l'informatique comme de la voiture: Un Ferrari rouge est une merde pour labourer son champ; Un tracteur est une merde pour faire du 0-100 km/h en moins de 4 secondes!
Trop de sgbd?
SQLite est parfait pour une base locale accédée par une seule application. C'est aussi l'idéal pour une base embarquée, là où les ressources sont très limitées. Mais outre qu'il n'existe pas vraiment de serveur SQLite (même si on peut en bricoler un avec n'importe quel framework REST) dès que tu as plusieurs applications qui accèdent en même temps, ce n'est pas l'idéal.
MariaDB, c'est parfait pour un client-serveur dans lequel les lectures sont beaucoup plus fréquentes que les écritures. C'est notamment le cas quand tu crées un site web avec un CMS. Dans ce cas MariaDB est plus rapide que PostgreSQL parce que le moteur de transactions peut être désactivé (quand tu as un CMS c'est quand même assez rare que plusieurs personnes modifient la même page au même moment)
PostgreSQL, c'est un bon moteur quand tu as besoin de transactions mais que tu ne veux pas avoir quelque chose de trop lourd ou dépenser des milliers d'euros avant d'avoir écrit la première ligne de code. Après je veux bien croire qu'il manque des fonctions par rapport à Oracle, mais ça s'améliore (par exemple le partitionnement a été complètement refait récemment) mais combien de personnes ont besoin de tout ça?
Maintenant, la nouvelle tendance est de considérer que les applications type "commerce en ligne" ont le vent en poupe et les nouveaux serveurs comme MongoDB ou Cassandra sont plutôt conçus pour ce genre de besoins:
- limiter l'usage de SQL au profit de modèles alternatifs (colonnes, documents, ...) à choisir au cas par cas
- permettre la répartition des données sans nuire aux performances (avec une base SQL, même Oracle, le modèle de commit répliqué, qui impose que toutes les copies soient validées avant de considérer la transaction comme aboutie peut faire fuire le consommateur qui ne voit pas sa page de confirmation après plusieurs minutes...)
Comme tu peux le voir, il y a plusieurs moteurs (serveur ou non, SQL ou non, etc.) parce qu'il y a plusieurs besoins. Mais c'est vrai qu'on lit partout que la concurrence libre et non faussée c'est bien, mais tout de même tout le monde doit utiliser le leader du marché. Allez comprendre...
Attention, quand j'ai écrit que les admin Debian seraient plus chers que les admin Windows, ce n'était pas le reflet de mon opinion mais de ce que j'entends souvent en entreprise. Désolé, j'aurais dû mettre un conditionnel ça aurait rendu les choses plus claires.Sans compter qu'il faut 5 admin windows pour faire le même travail qu'un seul admin Redhat ou Debian pour la même taille de parc.
Il me semblait avoir lu (il y a longtemps) que la différence de performances entre Oracle, SQL Server & co. et PostgreSQL MySQL & co. est principalement due au fait que les uns codent des accès disques sur mesure et les autres utilisent les fonctions de l'OS sous-jacent ce qui est bien plus lent. N'étant pas un expert en BDD et vu qu'il y a des gens qui ont l'air de savoir de quoi ils parlent ici c'est info ou intox ?
Oracle permet en effet (SQL Server, je ne suis pas sûr) d'avoir des partitions dédiées, à son propre format. L'avantage que je vois, un peu comme les partitions swap sous Linux, c'est qu'il y a moins de fragmentation. De là à ce que ça permette un énorme gain de performances, je demande à voir.
Du coup, je ne suis pas réticent à lire l'article de SQL Pro mais à condition qu'il livre suffisamment de détails pour que son expérience soit reproductible rien qu'en lisant l'article. Mais prendra-t-il le risque de voir quelqu'un optimiser la version PostgreSQL ou MariaDB pour finalement obtenir les mêmes chiffres que lui sous Oracle?
Non mais attend, le mec c'est pas n'importe qui tout de même. Y a marqué 15 fois EXPERT dans sa signature web, comment oses-tu émettre des doutes
Globalement en phase.
Les entreprises ont une équation à résoudre, avec trois facteurs qui me viennent à l'esprit (j'en exclu tout ce qui est dogme ou politique) :
- les services attendus du SGBD - front <> back <> dwh <> lac <> ...
- le risque qu'on est prêt à courir - si le site de veepee.com tombe pendant 2h c'est pas le même impact que si c'est jaimelestulipes.com
- l'argent qu'on a a disposition - pour le matos, les logiciels et les équipes
Tout le monde n'utilise pas le leader du marché car il n'y a pas un leader - il y a au mieux un leader pour un ensemble d'équations.
Et comme il y a autant d'équations que de sociétés, il existe beaucoup de solutions, certaines favorisant le libre et d'autres les solutions propriétaires.
Principe de Peter: l'expert, c'est celui qui en sait de plus en plus sur de moins en moins. Ce gars devrait changer son pseudo en "SQL non libre Pro", ça serait déjà un peu moins hypocrite.Non mais attend, le mec c'est pas n'importe qui tout de même. Y a marqué 15 fois EXPERT dans sa signature web, comment oses-tu émettre des doutes
Non c'est vrai, seulement toutes les entreprises ou institutions suffisamment grosses pour vouloir toujours passer par une SSII. Donc tous ceux dont le coeur de métier n'est pas l'informatique en fait
Un collègue m'avait dit une fois qu'il avait choisi Oracle non pas sur des critères techniques, mais seulement parce qu'il savait qu'en cas de pépin, personne ne pourrait lui reprocher d'avoir choisi le leader du marché, alors que choisir n'importe quel autre serveur, c'est engager sa responsabilité. Et bien sûr cette logique est valable aussi bien pour le blog interne d'entreprise que pour le site de vente en ligne.
Moui enfin, dans les casseroles du monsieur tu as également le fait qu'il soutient mordicus que générer des requêtes SQL depuis une application cliente d'un SGBD est une hérésie et qu'elles ne devraient que faire appel à des vues ou des procédures stockées écrites par un dba, donc son incompétences ne se limite pas aux dbs autres que Sql server, y a des sérieuses lacunes dans le développement applicatif aussi.
Trop fort, j'en ai eu un comme ça au boulot, le mec mettait 3 semaines à te sortir une vue avec trois jointures, parce qu'il ne la livrait pas avant d'avoir testé toutes les formes d'optimisation possibles et imaginables (et tant pis pour les développeurs qui ne pouvaient rien faire entre temps).
Par contre je ne soutiens pas pour autant l'usage des ORM, qui génèrent un code SQL qui, même pour moi qui ne suis pas un DBA, paraît franchement peu optimisé. C'est vraiment dommage que les serveurs SGBD orientés objet aient été détruits par des gars comme SQL Pro qui les jugeaient peu performants parce qu'ils comparaient une appli Oracle ultra-optimisée avec un simple programme de test sur l'autre serveur. C'est pour ça que j'espère qu'il aura au moins la décence de donner assez de détails pour qu'on puisse refaire le test...
Le souci du libre dans les bases de données (mais aussi pour bien d'autres logiciels) c'est qu'il existe généralement deux versions :
- Une version "libre / gratuite / enculelesmouches.org" limitée, parfois carrément avec une ou deux version de retard
- Une version absolument pas libre du tout, totalement payante, qui est celle qui est maintenue et qui tiens la route
En fait, c'est exactement la même chose que pour les applications propriétaires qui offrent une version "Lite" ou "Express" gratuite... à quelques détails près :
- En général les versions "lite" sont de la même version que la version commerciale et proposent le même niveau de qualité, avec des restrictions par fonctionnalité (et non pas des altérations du fonctionnement de certaines fonctionnalité, qu'on peut avoir lorsque les deux produits ne sont pas de la même version
- Proposent un support "basique", à savoir la garantie de la mise ne place de correctifs de sécurité notamment, au même titre que la version payante
Rien qu'à ce niveau, il y a de grosses différences entre "libre" et "propriétaire"... mais c'est avant tout car tous les projets "libres" ont été détournés de leur esprit d'origine.
En effet, pour les produits qui n'ont pas été détournés de leur esprit initial (par exemple, Firefox ou Linux) des offres payant n'apportent en réalité que des services complémentaires (notamment un support) et sont parfaitement dispensables.
Le gars qui n'y connais rien, ça fait peur.
On ne parle pas de système de fichier Oracle ou autre... et la fragmentation (sur un SGBD digne de ce nom) n'a rien à voir avec le système de fichier support !
1) Quand on crée une base de données, on dimensionne ses fichiers en prévoyant son exploitation future. Ainsi, on crée non pas un fichier de 2 Mo dans un coin et on verra bien comment ça grossira plus tard, mais on va créer des fichiers d'une taille "cible" de façon à ce que d'ici 2 ans on n'ait pas besoin de les faire grossir.
=> Ainsi, quel que soit le système de fichier, il n'y aura (ou extrêmement peu) pas de fragmentation, puisqu'on a créé le fichier en une seule fois plutôt que d'en ajouter un morceau de temps en temps (ou plein de petits morceaux sans arrêt)
2) Oracle et SQL Server ne passent pas par l'OS pour accéder au disque. Ainsi, ils peuvent se réserver une priorité suppérieur à cette de l'OS pour travailler.
=> Ceci permet par exemple d'éviter de foutre à plat un serveur si soudainement un process se met à swapper. Ça n'a rien à voir avec le système de fichier, ça peut être du EXT3, de la FAT16 ou du HPFS ça changera rien ni au but recherché ni au résultat obtenu.
Répondre avec citation
Partager