Vous n'êtes pas identifié(e).
Bonjour
Bon, je crois que je crois me faire encore quelques ennemis de plus...
Au sommaire :
1 - Aucune gestion des espaces de stockage.
2 - Une gestion des transactions "curieuse".
3 - Un partitionnement plus que léger
4 - Pas de tag (hint) pour forcer les plans de requête
5 - un optimiseur très limité
6 - Une indexation à la traine
7 - Pas de parallélisme des requêtes
8 - Une administration couteuse
9 - pas de pooling des connexions
10 - Pas de vision d'un plan en cours d'utilisation
11 - Un processus de sauvegarde peu performant
12 - Pas de compression ni de cryptage des données
13 - Pas de réplication des données
14 - PostGreSQL reste un bon SGBDR réellement libre
15 - En conclusion
Merci d'avance pour vos commentaires.
A +
Dernière modification par SQLpro (11/10/2011 22:54:03)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Joli troll...
Guillaume.
Hors ligne
Et si pour changer vous donniez aussi les avantages à ces migrations, ou que écriviez des choses vraiment objectives ?
Je sais, on dit "don't feed the troll" mais je trouve qu'il serait vraiment dommage que des utilisateurs du forum prennent de mauvaises décisions sur de mauvais conseils...
Julien.
https://rjuju.github.io/
En ligne
Et si pour changer vous donniez aussi les avantages à ces migrations, ou que écriviez des choses vraiment objectives ?
Il y a tellement d'article sur les avantages incommensurables de changer d'Oracle à SQL Server que je ne voyais pas l'intérêt d'y ajouter le mien ! ;-)
Le seul véritable avantage est le non paiement de licence.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Il y a une telle quantité d'erreurs factuelles dans cet article que ça donne le vertige. Mais je n'aiderai pas à corriger cette fois-ci. Je crois qu'il y aura deux avantages:
- Ça m'évitera d'être encore récompensé de mes efforts par la grossièreté de sqlpro.
- Ça fait un document à charge, montrant à quel point il ne maîtrise pas PostgreSQL.
Marc.
Hors ligne
*popcorn*
ps: Ce post est un peu près du même niveau que notre cher professeur.
Hors ligne
Ce devient n'importe quoi ...
je ne suis pas administrateur, mais je me demande ce que Mr SQLPro (?!) fait sur ce forum.
Je ne vois pas l’intérêt de venir ici pour dénigrer Postgresql et vendre sa soupe (articles, blog, livres, SQLServer, ...).
Ce forum a pour objectif d'aider les gens, pas de passer son temps à troller sur des moteurs de base de données qui ne nous intéressent pas !
Je ne vais pas lire votre article, car le sommaire sonne déjà comme un appel au troll et est déjà complètement faux.
Y a t'il une option ignorer dans ce forum ? 
Hors ligne
Je me permet de répondre à quelques points.
1 - Aucune gestion des espaces de stockage.
Faux toi pas savoir lire doc.
3 - Un partitionnement plus que léger
Vrai.
8 - Une administration couteuse
On doit passer 100 fois plus de temps sur notre oracle que sur nos pgsql/mysql.
9 - pas de pooling des connexions
Le listener d'oracle qui fait office de pooleur est bien un processus indépendant, conceptuellement c'est la même chose que pg/mysql
11 - Un processus de sauvegarde peu performant
Sauvegarder table par table est un besoin "particulier" qui ne concerne que les élèves de Papouasie de nouvelle guinée.
12 - Pas de compression ni de cryptage des données
Table toast compresser par défaut.
13 - Pas de réplication des données
HAHAHAHAHAHAHAHAHAHAHA ! Encore oublier de lire la doc on dirais.
15 - En conclusion
Plutôt que de l'ignorer le renommer en SQLTroll serait plus pertinent.
Hors ligne
Bonjour,
Dans les posts précédents de SQLPro je trouvais un intérêt, tant j'apprécie les regards extérieurs, parfois très critiques, qui permettent de faire avancer notre communauté.
Les critiques n'étaient pas toujours adroites, mais avaient le mérite d'être formulées.
Avec ce post-ci,je suis très déçu par SQLPro. Son article pue la mauvaise foi et les erreurs.
J'y retrouve pêle-mêle tous les vrais faux arguments des détracteurs de PostgreSQL. Je commence à bien les connaître, je les déments depuis plus de 10 ans à présent.
SQLPro, s'il vous plaît, reprennez-vous, cet article n'est très clairement pas à votre hauteur.
Si vous voulez dénigrer PostgreSQL, faites-le au moins intelligemment.
Bien à vous,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Si vous voulez dénigrer PostgreSQL, faites-le au moins intelligemment.
Mon intention n'est pas de dénigrer PostGreSQL, mais de donner des éléments clefs de choix, même s'ils vous font viscéralement mal.
Il semble que vous n'ayez pas lu jusqu'au bout mon article, car je parle aussi très positivement de PostGreSQL.
je me cite :
"...aucun autre SGBDR dans le libre n'arrive à la hauteur de PostGreSQL en terme de fonctionnalités, de fiabilité et de performances, lorsqu'on le maintient dans certaines limites. Il m'arrive de le préconiser en alternative aux SGBDR des principaux éditeurs lorsque ces derniers veulent ne pas payer de licence. "
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
SQLPro,
Vous me faites rire tant vous êtes ancré dans vos certitudes :-D
Ce qui ne vous ferait pas de mal à vous, c'est de lire et entendre un peu les arguments des autres. Vos "clefs de choix" ... C'est une vaste rigolade.
Quant à lire votre article, je l'ai bien sûr lu, je ne me serais pas permis de vous répondre comme je l'ai fait sans l'avoir lu.
Non seulement vous ne maîtrisez clairement pas PostgreSQL, mais en plus vous êtes grossier...
Nous traiter de "nerd" n'est en effet pas la chose à faire si vous voulez vous faire des amis ici. Au passage, gardez vos "phantasmes" (était-ce pour rappeler l'éléPHant ? :-D) pour vous.
Si la seule chose qu'il vous reste pour attirer l'attention c'est l'agressivité, je vous plains.
Pour ma part, vous n'avez rien de "pro" et je préfère désormais ignorer vos attaques sans intérêt.
Bien à vous,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
1 - Aucune gestion des espaces de stockage.
Faux toi pas savoir lire doc.
Visiblement vous ne maîtrisez pas le sujet. La notion de tablespace PG ne fait qu'indiquer un répertoire. Rien d'autre !
Voici la syntaxe PG (v9.1.1):
CREATE TABLESPACE tablespace_name [ OWNER user_name ] LOCATION 'directory'Ce que vous ne pouvez pas faire avec PostGreSQL :
1) vous ne pouvez pas indiquer une taille minimale de l'espace de stockage
2) vous ne pouvez pas indiquer une taille maximale de l'espace de stockage
3) vous ne pouvez pas indiquer un pas de croissance de l'espace de stockage
4) vous ne pouvez pas ajouter un autre répertoire a un tablespace déja créé
5) vous ne pouvez pas placer un espace de stockage en READ ONLY pour des tables statiques afin d'éviter le verrouillage
Toutes ces possibilités existent sur Oracle, SQL Server, IBM Db2, Sybase ASE...
Indiquez moi comment vous ferez le jour ou votre tablespace placé sur un disque est saturé ?.
8 - Une administration couteuse
On doit passer 100 fois plus de temps sur notre oracle que sur nos pgsql/mysql.
Oui, mais en rapport à quel volumétrie de données et quelle concurrence ?
Là ou vous avez partiellement raison, c'est que l'admin Oracle est plus complexe et donc plus souteuse que celle de MS SQL Server...
9 - pas de pooling des connexions
Le listener d'oracle qui fait office de pooleur est bien un processus indépendant, conceptuellement c'est la même chose que pg/mysql
La différence est qu'il est intégré dans l'offre Oracle. Pour SQL Server il est aussi intégré. Pour PG C'est une installation supplémentaire....
11 - Un processus de sauvegarde peu performant
Sauvegarder table par table est un besoin "particulier" qui ne concerne que les élèves de Papouasie de nouvelle guinée.
Encore une fois vous n'avez pas lu ce que j'ai écrit... Cela n'empêche pas de critiquer ! Et surtout de dire n'importe quoi pour apporter du discrédit...
Effectivement la sauvegarde d'une table est stupide. Elle n'existe d'ailleurs pas ni sous Oracle, ni sous SQL Server tout simplement parce qu'une base est un tout et qu'une table sortie de son contexte de base de données ne veut rien dire...
Je parle de sauvegardes différentielles qui permettent par exemple de ne prendre en compte que les pages de données de la base qui ont été modifiées depuis un précédente sauvegarde. Cela n'existe pas dans PG. C'est évidemment beaucoup plus rapide que de sauvegarder toute la base. Et c'est très utile sur de grosses bases ou le temps de sauvegarde peut commencer à devenir critique.
Je parle de sauvegarde par espace de stockage (fichiers ou filegroup sous SQL Server par exemple) et non par table. Par exemple un espace de stockage en READ ONLY n'a pas besoin d'être sauvegardé plus d'une fois. Alors on sauvegarde quotidiennement que les autres ce qui réduit là encore le temps des sauvegardes.
12 - Pas de compression ni de cryptage des données
Table toast compresser par défaut.
C'est plus que limité... Aucune comparaison avec une compression d'une base entière...
13 - Pas de réplication des données
HAHAHAHAHAHAHAHAHAHAHA ! Encore oublier de lire la doc on dirais.
Vous lisez toujours mal. Je parle de réplication de données, pas de duplication de base. Le mot réplication est utilisé à tort et à travers.
La réplication de données consiste à prendre certaines données de certaines tables et placer ces informations dans une autre base.
La réplication streaming introduite en v9 n'est pas à proprement parle une réplication, mais la duplication d'une base, c'est à dire un mécanisme de haute disponibilité.
C'est l'équivalent du mirroring asynchrone dans SQL Server disponible depuis 2005.
A +
PS : vous n'êtes pas obligé d'utiliser le tutoiement. A moins d'être mon enfant... (je ne savais pas avoir laissé quelques enfant naturels sur la toile....).
Moi, au moins, je vous respecte en employant le vouvoiement de politesse !
Dernière modification par SQLpro (12/10/2011 10:39:34)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
La philosophie du projet Postgres est assez claire en ce qui concerne la gestion de l'espace de stockage: vous devez superviser l'espace disque vous même. Et effectivement, cet espace de stockage ne se gère pas de la même façon qu'Oracle ou SQL Server. Je le vois comme une faiblesse et une force de Postgres: vous êtes plus limité mais le SGBD est bien moins complexe.
Donc à vous de mettre en œuvre une supervision pour que la saturation de l'espace disque n'arrive pas.
Je rejoints Frédéric sur l'absence de tablespace READ ONLY. J'aimerai bien que Postgres puisse disposer d'une telle fonctionnalité.
Et concernant le dernier point, c'est encore la philosophie de Postgres qui entre en jeu. Les développeurs vous fournissent un noyau, le SGBD lui-même, et vous laisse la possibilité de l'enrichir à votre guise. Ainsi sont nés un certain nombre de projets annexes, et notamment Slony et Londiste qui répondent au besoin de réplication des données.
Cdt,
Thomas
Thomas Reiss
Hors ligne
La philosophie du projet Postgres est assez claire en ce qui concerne la gestion de l'espace de stockage: vous devez superviser l'espace disque vous même. Et effectivement, cet espace de stockage ne se gère pas de la même façon qu'Oracle ou SQL Server. Je le vois comme une faiblesse et une force de Postgres: vous êtes plus limité mais le SGBD est bien moins complexe.
Donc à vous de mettre en œuvre une supervision pour que la saturation de l'espace disque n'arrive pas.
Je rejoints Frédéric sur l'absence de tablespace READ ONLY. J'aimerai bien que Postgres puisse disposer d'une telle fonctionnalité.Et concernant le dernier point, c'est encore la philosophie de Postgres qui entre en jeu. Les développeurs vous fournissent un noyau, le SGBD lui-même, et vous laisse la possibilité de l'enrichir à votre guise. Ainsi sont nés un certain nombre de projets annexes, et notamment Slony et Londiste qui répondent au besoin de réplication des données.
Cdt,
Thomas
Merci de vos commentaires.
Certains me prennent pour un affreux jojo anti PostGreSQL. Ce que bien évidemment je ne suis pas.
Mais connaître ses faiblesses c'est permettre le choix et surtout, comme c'est possible dans le monde libre, rajouter une contribution qui enrichit le système.
Je regrette par exemple qu'il faille payer pour mettre des tags (hint) de requêtes dans PostGreSQL par une pseudo philosophie obscure, alors que dans une version payante (EnterpriseDB) cela existe !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Certains me prennent pour un affreux jojo anti PostGreSQL. Ce que bien évidemment je ne suis pas.
Mais connaître ses faiblesses c'est permettre le choix et surtout, comme c'est possible dans le monde libre, rajouter une contribution qui enrichit le système.
Au vu de vos articles, ce qu'il en ressort selon vous est qu'il ne faut jamais choisir postgresql, en donnant une argumentation plus que partiale. Si vous donniez toutes les informations et non celles qui vous arrangent, là effectivement cela enrichirait la discussion.
Ainsi, poster un article presque entièrement erroné, montrant votre méconnaissance de postgresql et un certain acharnement à le critiquer, sur un forum d'entraide pousse effectivement les gens à vous prendre pour "un affreux jojo anti Postgresql".
Je regrette par exemple qu'il faille payer pour mettre des tags (hint) de requêtes dans PostGreSQL par une pseudo philosophie obscure, alors que dans une version payante (EnterpriseDB) cela existe !
Je peux me tromper la dessus mais il me semble que c'est un choix des développeurs, motivés par le fait que :
1- Le SGBD est en grande majorité plus au courant que le développeur de la viabilité d'un plan d'exécution qu'un autre
2- Forcer l'utilisation d'un index peut se révéler quelques temps plus tard un mal plus qu'un bien selon l'évolution de la base, un index n'étant pas non plus une solution magique.
Au final, bien paramétrer sa base de donnée et s'assurer de bonnes statistiques n'a à ma connaissance jamais empêcher la résolution d'un problème de non utilisation d'un index sur postgresql.
Si cela ne vous convient toujours pas, libre à vous de proposer un patch proposant cette fonctionnalité, et ainsi enrichir le système, ou d'entamer des discussions avec les développeurs, chose beaucoup plus constructive.
Dernière modification par rjuju (12/10/2011 12:59:22)
Julien.
https://rjuju.github.io/
En ligne
SQLpro a écrit :Certains me prennent pour un affreux jojo anti PostGreSQL. Ce que bien évidemment je ne suis pas.
Mais connaître ses faiblesses c'est permettre le choix et surtout, comme c'est possible dans le monde libre, rajouter une contribution qui enrichit le système.Au vu de vos articles, ce qu'il en ressort selon vous est qu'il ne faut jamais choisir postgresql, en donnant une argumentation plus que partiale. Si vous donniez toutes les informations et non celles qui vous arrangent, là effectivement cela enrichirait la discussion.
Ainsi, poster un article presque entièrement erroné, montrant votre méconnaissance de postgresql et un certain acharnement à le critiquer, sur un forum d'entraide pousse effectivement les gens à vous prendre pour "un affreux jojo anti Postgresql".
Montre moi les erreurs que j'ai commise. Donnez moi vos argument. Vos précédents arguments était faux. Montrez moi simplement un bout de code qui infirme ce que j'ai écrit... Ou bien des exemples concrets sur des sites crédibles...
Moi je m’intéresse aux faits. pas aux paroles partisanes.
SQLpro a écrit :Je regrette par exemple qu'il faille payer pour mettre des tags (hint) de requêtes dans PostGreSQL par une pseudo philosophie obscure, alors que dans une version payante (EnterpriseDB) cela existe !
Je peux me tromper la dessus mais il me semble que c'est un choix des développeurs, motivés par le fait que :
1- Le SGBD est en grande majorité plus au courant que le développeur de la viabilité d'un plan d'exécution qu'un autre
2- Forcer l'utilisation d'un index peut se révéler quelques temps plus tard un mal plus qu'un bien selon l'évolution de la base, un index n'étant pas non plus une solution magique.
Pour un développeur lambda oui. Mais pour un DBA il en va tout autrement. Un bon DBA sait qu'aucun optimiseur au monde n'est parfait et qu'il faut de temps à autre intervenir sur un plan de requête. Il y a des dizaines d'ouvrages très sérieux sur ce sujet et des dizaines de milliers d'articles pour voir et comprendre pourquoi c'est utile.
Je vous en donne quelques références pour votre culture personnelle :
SQL Tuning
Principles of Database Query Processing for Advanced Applications
SQL Server Execution Plans
Cost-Based Oracle Fundamentals
Inside the SQL Server Query Optimizer
Au final, bien paramétrer sa base de donnée et s'assurer de bonnes statistiques n'a à ma connaissance jamais empêcher la résolution d'un problème de non utilisation d'un index sur postgresql.
Si j'ai même donné un exemple ou cela pourrait être utile dans mon article. Visiblement vous ne lisez toujours pas correctement.
Donc, rappel :
Les 13 grandes lacunes de PostGreSQL ou comment une migration Oracle PG peut s'avérer cauchemardesque !
Paragraphe 4 - Pas de tag (hint) pour forcer les plans de requête
Exemple avec la table T
Si cela ne vous convient toujours pas, libre à vous de proposer un patch proposant cette fonctionnalité, et ainsi enrichir le système, ou d'entamer des discussions avec les développeurs, chose beaucoup plus constructive.
Je ne suis pas développeur. C'est un autre métier que le mien. Je suis architecte de données et à ce titre je m'intéresse aux bases de données sous toutes les coutures, avant et après l'exploitation :
Modélisation, création, structuration, optimisation, tuning, administration, monitoring...
C'est un vrai métier, dont visiblement vous n'avez pas entendu parlé !
Pour votre culture personnelle : Wikipedia : Administrateur de bases de données
C'est même un métier très rémunérateur, puisque les salaires sont en général plus élevés que ceux des responsables systèmes...
A +
Dernière modification par SQLpro (12/10/2011 13:42:13)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
La seule conclusion à tirer de ce glorieux échange, c'est que tu mérite bien le surnom SQLTroll.
Hors ligne
Quel plaisir trouvez vous à venir critiquer en permanence (et depuis très longtemps : tout le monde peut rechercher votre nom sur les newsgroups) tout ce qui n'est pas conforme à votre choix ?
Monsieur SQLPro, étant donnée votre avis (ridicule) sur le monde du libre (http://blog.developpez.com/sqlpro/p1032 … u-comment/) et votre avis concernant Postgresql (tout aussi ridicule), ne serait-il pas plus simple de fermer votre compte sur ce forum et de rester avec votre windows et votre SQLServer loin de nous ?
Hors ligne
Un seul exemple me suffira, puisqu'ensuite je suppose que vous viendrez jouer de mauvaise foi ou répondrez à coté :
Il n'est pas non plus possible de savoir comment sont utilisés les index de la base et donc de supprimer les index inutilisés. Par exemple SQL Server propose la vue sys.dm_db_index_usage_stats pour connaitre l'utilisation de tous les index du serveur.
Il existe la même chose sur postgres, par exemple la vue pg_stat_user_indexes.
Pour votre "culture personnelle" également : http://docs.postgresqlfr.org/9.0/monitoring-stats.html
Maintenant, libre à vous de continuer votre arrogance et condescendance envers moi, cela me conforte (et apparemment je ne suis pas le seul) dans mon opinion sur votre crédibilité, et n'y répondrais plus.
Dernière modification par rjuju (12/10/2011 13:57:38)
Julien.
https://rjuju.github.io/
En ligne
Pour le point 6, la vue pg_stat_all_indexes sert à quoi ?
Thomas Reiss
Hors ligne
Un seul exemple me suffira, puisqu'ensuite je suppose que vous viendrez jouer de mauvaise foi ou répondrez à coté :
Il n'est pas non plus possible de savoir comment sont utilisés les index de la base et donc de supprimer les index inutilisés. Par exemple SQL Server propose la vue sys.dm_db_index_usage_stats pour connaitre l'utilisation de tous les index du serveur.
Il existe la même chose sur postgres, par exemple la vue pg_stat_user_indexes.
Pour votre "culture personnelle" également : http://docs.postgresqlfr.org/9.0/monitoring-stats.html
Là j'avoue que je n'ai effectivement pas vu cela.
Ce qui est dommage c'est que dans ces vues il n'y a pas le nombre de mises à jour d'index que l'on obtient par approximation au niveau table (un index n'est pas forcément mis à jour lors d'un update), ce qui serait très pratique pour décider de retirer ou non l'index.
Malgré cela il n'existe rien pour savoir quels index sont à poser !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pour le point 6, la vue pg_stat_all_indexes sert à quoi ?
Mea culpa, j'ai rectifié le tir !
Merci
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ce devient n'importe quoi ...
je ne suis pas administrateur, mais je me demande ce que Mr SQLPro (?!) fait sur ce forum.
Je ne vois pas l’intérêt de venir ici pour dénigrer Postgresql et vendre sa soupe (articles, blog, livres, SQLServer, ...).
Ce forum a pour objectif d'aider les gens, pas de passer son temps à troller sur des moteurs de base de données qui ne nous intéressent pas !
Je ne vais pas lire votre article, car le sommaire sonne déjà comme un appel au troll et est déjà complètement faux.Y a t'il une option ignorer dans ce forum ?
C'est bien de critiquer sans avoir lu ! Cela montre le niveau des intégristes de PostGreSQL...
A +
Dernière modification par SQLpro (16/10/2011 08:55:58)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
À propos des Hints, je vous propose d'aller en discuter avec les développeurs. Vous ne serez que le n-ième "DBA" Oracle qui sera venu les importuner à ce propos. Et pensez bien à les titiller avec les mêmes types de remarques que vous faites ici, histoire de pimenter un peu la discussion.
Moi, je vais m'installer confortablement devant ma mailing-list pgsql-hackers, prendre des popcorn et regarder si vous aurez des arguments différents de tous ces autres. À moins qu'ils vous balaient avec dédains en vous renvoyant à un simple lien [1] comme n'importe quel quidam...
En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.
Si je prends l'exemple des tablespaces, contrairement à Oracle, les développeurs de PostgreSQL ont décidés de ne pas ré-implémenter la roue. Il y a bien mieux à faire ailleurs. Ça vous demandera d'ôter vos œillères et aller voir coté système les solutions qui existent pour assurer le même type de souplesse...
Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.
Hors ligne
SQLPro,
Vous vous entêtez dans l'erreur, continuez votre dénigrement et assénez des contre-vérités plus vite que votre ombre, ce qui soit dit en passant, me faisait plutôt rire.
Mais là, vous dépassez clairement les bornes avec des propos islamophobes. Ça ne me fait plus rire du tout.
Sachez que de les propos xénophobes ne sont pas acceptables, ni sur ce forum public, ni ailleurs. Ils sont purement et simplement condamnables.
Autant vous pouvez dire toutes les bêtises sur PostgreSQL que vous voulez, car nous serons là pour les démentir, autant ces propos xénophobes vous font passer directement de la case "amuseur public" à la case "utilisateur à bannir".
Je vous conseille d'éviter ce genre de propos à l'avenir sur internet, en particulier sur des forums publics comme celui-ci, car cela pourrait vous amener directement à la case "Prison".
J'ai sollicité par mail l'ensemble des administrateurs du forum pour que nous puissions prendre une décision d'exclusion à votre encontre. Comprenez bien que nous devons assurer la bonne tenue de ce forum d'entraide, et que cela passe par des décisions radicales lorsque cela est justifié, comme c'est le cas aujourd'hui.
Bien que nous soyons d'ardents défenseurs de la liberté d'expression, ne nous pouvons tolérer de tels propos.
Au revoir,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne