Vous n'êtes pas identifié(e).
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 !
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 +
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 +
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 +
L'ordre de visualisation des lignes correspond à l'ordre d'utilisation du compteur associé lors de l'insertion. Sur postgresql, le résultat sera équivalent car les séquences n'ont aucune contrainte de transaction pour assurer leur unicité, et peuvent ainsi se "mélanger" lors de plusieurs appels concurrents.
Plusieurs choses à dire :
1) la démo de transaction DDL est mauvaise car sans la transaction ça marche aussi. Elle aurait été plus probante si vous aviez fait un ROLLBACK et montré que la table avait disparue.
2) le fait qu'une fonction soit en elle même une transaction est un choix plus que discutable. En effet que se passe t-il si vous avez lancé une transaction qui lance une procédure ? (transactions imbriquées)
Le cas des transactions imbriquées est toujours complexe, mais sans méthode de résolution, il est difficile de savoir ce qui se passe.
En sus ce n'est pas parce que il y a une erreur que l'on doit considérer automatiquement que la transaction doit être annulé. C'est en principe l'utilisateur et lui seul qui devrait décider.
Considérant par exemple, une gestion de stocke, on peut essayer de déstocker du matériel et partir en erreur dans une table car on dépasse le seuil. Mais on peut alors décider en cas d'erreur de lancer une commande. Ce que visiblement PG ne sais pas faire au sein d'une même fonction.
Dans ce sens, PG n'est pas conforme à la norme SQL qui précise que les transactions survivent au niveau de la session.
3) "mélange"
Dans une base de données, par nature ensembliste il n'y a pas d'ordre de données. pas plus que dans un sac. A lire : "les données des bases sont des ensembles"
A +
C'est une décision tout à fait sage et PG commence à avoir un bon mécanisme pour ce faire... mais attention en 9.1 c'est encore en béta :
« Transaction-controlled Synchronous Commit ».
Mea culpa... La version finale 9.1 est sortit depuis le 13/9... Désolé
A +
J'en profite pour vous poser moi-aussi une question, cette fois sur SQL Server. Est-il possible d'exécuter des CREATE TABLE, CREATE INDEX et autres dans une transaction avec SQL Server ?
Oui. D'après la norme SQL les transcation portent sur tout l'étendue des ordres SSL à l’exception de la gestion des privilèges, qui pour des raison de sécurité doit être immédiat et non "révocable" par la transaction.
Donc les ordre DDL CREATE, ALTER, DROP... doivent être transactionné, ce que SQL Server gère depuis l'origine. En revanche Oracle ne sait pas faire cela...
A +
De plus passer par des déclencheurs ne réduit pas la complexité, il l'augmente vu qu'au lieu d'une règle il faut deux commandes :
- la création de la fonction trigger
- la création du trigger association la table et son événement et la fonction trigger.
Mais l'ajout d'un trigger permet de remplacer toutes les règles. Donc c'est moindre en nombre de commandes.
reste que le nombre de commande SQL est toujours le même, donc aucun gain !
Mais c'est bien dommage car l'intérêt majeur du partitionnement c'est le stockage physique !
PostgreSQL propose autant au niveau du stockage. Le seul point qui n'est pas là, c'est les quotas. Qui est plutôt système, et non pas bases de données. Ça ne me dérange pas personnellement.
Vous ne maîtrisez visiblement pas le sujet... Rien à voir avec les quota. le quota c'est informer le système qu'un fichier va croitre de n et donc demander au système de prévoir l'espace pour l'expansion du fichier, qui s'il croit va être fragmenté. La gestion des espaces de stockage des bases de données, c'est de créer un fichier NON FRAGMENTÉ d'un volume donné par exemple 80 Go, avec des granules choisit pour être situées aux endroit des disques les plus rapide d'accès pour optimiser les accès disques. Lisez par exemple le cours de Rigaux du cnam pour comprendre cette chose là, aux moins vous aurez appris quelque chose que les SGBDR comme Oracle, DB2 ou SQL Server savent faire depuis plus de 15 ans !
Il est d'ailleurs curieux de constater que la propagation des contraintes des tables en héritage est tantôt effectives pour certaines, tantôt non effectives pour d'autres.
Les seules contraintes qui ne peuvent pas être héritées sont les contraintes qui dépendent d'un index (donc contrainte unique et clé primaire). C'est logique, ces contraintes sont forcées grâce à un index, or un index ne peut pas être créé sur plusieurs tables.
Et pourquoi ce choix, car c'est un choix de conception tordu de PostGreSQL... ! En matière d'héritage la norme indique que l'héritage doit se faire sur toutes les contraintes... Il n'y a aucune logique la dedans, si ce n'est l'incapacité de PG a faire des choses claires !
À moins d'être idiot, je pense que vous vous trompez...
Je ne me trompe pas, je parlais à la création de la table fille. Je ne parlais pas après création. Il est évident qu'après création d'une table héritant d'une autre table, les nouvelles colonnes ne sont pas automatiquements ajoutées comme les nouveaux attributs ne sont pas non plus ajoutées.
La encore je ne vous comprend pas. Une nouvelle colonne ajoutée à la table mère par ALTER TABLE de la table mère est bien propagée, dans les tables fille. Je crois que ous vous embrouiller pour ne pas reconnaître que sur ce coup vous avez tort !
Mon article compare les deux solutions (SQL Server vs PostGreSQL) et montre à l'évidence que le coût induit par la complexité de mise en œuvre est très largement en défaveur de PostGreSQL.
Je ne conteste pas que SQL Server fait beaucoup mieux dans ce domaine. Je le dis même à mes clients en formation. Cependant, encore une fois, PostgreSQL ne propose pas cette fonctionnalité. Il propose juste un contournement, ce qui en explique ses limitations. D'où le fait que je ne pense pas qu'il soit fair-play de comparer les deux.
Soyez adulte, il n'y a pas de fair play à avoir dans le domaine de l'entreprise, de l’industrie ou de l'économie. Il y a des choses qui marchent bien, d'autres moins bien, et d'autres pas du tout. Il s'agit d'être informé pour choisir. A l'évidence vous confondez marketing, coup de cœur et réalités techniques.
Peut être pouvez-vous vous en occuper chez Dalibo.
Je ne crois pas aux benchmarks sur des bases de tests. Je ne perdrais donc pas de temps à faire ça.
Teins, là quand ça vous arrange vous vous défilez... Amusant !
Vous m'indiquerez comment vous pouvez rajouter une borne de partitionnement et scinder les lignes en deux espaces de stockage avec une seule commande ALTER TABLE. Je suis curieux de lire votre solution.
Je ne parlais pas de borne de partitionnement, mais de tablespace.
L'un étant intimement lié à l'autre, vous prenez encore une fois ce qui vous arrange pour vous défiler !
Visiblement vous ne lisez que les propos négatifs et les articles à décharge que j'écris. Ne seriez vous pas un tantinet partisan ???
Il est évident que je suis partisan de PostgreSQL. Ça ne veut pas dire pour autant que je ne suis pas objectif. J'avoue que je vois beaucoup de propos négatif dans ce que vous dites et que, évidemment, ça m'énerve beaucoup. Participer à un forum PostgreSQL et le critiquer en permanence pour couronner SQL Server comme seul SGBD intéressant, c'est limite et il ne faut pas vous étonner à récupérer des critiques.
Moi j'essaye modestement d'être objectif et de parler de ce que je constate. Malheureusement mes journées, n'ayant comme tout le monde que 24 h, je ne peut pas consacrer autant de temps que je le voudrais à tout constater sur tout et je me limite donc volontairement à mon domaine de connaissance afin d'éviter d'affirmer n'importe quoi, comme je le vois trop souvent sur des blog de benêts. Je constate d'ailleurs qu'aucun des propos tenu dans cet article n'a été invalidé par une preuve de code un tant soit peu sérieuses, ce qui fait qu’involontairement vous confirmez tout mes dires, et par là même je vous en remercie !
A +
En fait je veux que la charge (cpu, memoire...) se répartisse automatiquement sur plusieurs serveurs postgres. Un peu comme ça existe pour des applis tomcats ou les requetes vont sur l'un ou l'autre des serveurs tomcats.
Je fais déjà de la réplication mais ça ne sert que pour gérer un éventuel crash serveur ou disque.
Maintenant je veux avoir 2 serveurs postgres qui prennent chacun des requetes afin de diminuer la charge systeme de chaque machine et de la répartir équitablement entre eux deux. Les requetes pouvant etre en lecture et en ecriture...
Je pense que c'est ce qu'on appelle de la scalabilité.
Est ce plus clair ?A+
G.
De manière général, les SGBDR ne peuvent en aucun cas reproduire les mécanisme de répartition de charge des serveur Web, et cela pour une raison toute simple : il faudrait que les données soient simultanément présente sur tous les serveur. Autrement dit une insertion d'une ligne dans une table doit être envoyé à tous les serveurs...
Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1038 … #more10383
A +
Bonjour,
dès que l'on commence à parler volumétrie et en particulier tables avec beaucoup de lignes (plusieurs millions, voire beaucoup plus), il faut penser à différentes techniques, parmis lesquelles :
1) hypernormaliser sa base : cela peut être fait quelque soit le choix du SGBDR. A lire : Base de données et performances... petites tables et tables obèses !
2) le partitionnement des données : vous pouvez stocker toutes vos données dans une seule et même table et faire vivre différemment vos partitions. La PostGreSQL n'est pas le plus adéquat notamment en terme de souplesse de mise en œuvre. A lire Partitionner une table. Comparaison PostGreSQL / MS SQL Server(Oracle, DB2, SQL Server le font proprement)
3) la mise en place de vues matérialisées ou indexées. Là c'est clair, cela n'existe pas sous PostGreSQL ou il faut tout faire à la main. Ce genre de technique est très intéressante sur des calcules d'agrégats (SUM, COUNT, AVG...) (Oracle ou SQL Server le fait)
4) une gestion efficaces des espaces de stockage. Là non plus PostGreSQL ne sait pas faire : pas de pré allocation, pas de parallélisme d'accès pour les IO... (Oracle, SQL Server, SYbase et DB2 le font).
En sus, si vous voulez faire des rapports avec du drill down et de présenter des données sous forme de tableaux croisés multidimensionnel et que vous voulez que vos utilisateurs puissent à leur gréé modifier les croisements de données, il faut vous orienter vers un SGBDD (décisionnel) plutôt que R. Et là PostGreSQL n'est pas du tout adapté à des forts volumes car il ne sait faire que du ROLAP. Avec un fort volume de données à brasser, il faut un stockage spécifique au décisionnel donc une base MOLAP en passant éventuellement par un DataWarehouse.
Si en sus vous voulez envoyer vos rapport de manière automatique il faut un gestionnaire de reporting permettant les abonnement et probablement une gestion des droits associés (n'importe qui ne peut pas s'abonner à n'importe quoi).
Bref, je pense que vous devriez vous orienter plus sur une solution de BI intégrant DW + cube décisionnel avec l'attirail serveur de rapport, outils de forage, ETL.... Et dans ce cas MS SQL Server est l'une des solutions les plus complète et les moins cher...http://www.legrandbi.com/2011/01/gartne … t-bi-2011/
Quelques remarques :
NON les recherches ne sont pas plus rapide dans un flat file. elle le sont beaucoup moins. L'indexation, le partitioneemnt et les vues indexeées sont l'apanage des SGBDR !
En revanche les insertions dans des fichiers plats sont plus rapide, sauf si les fichiers de la base sont multiplexés et en particulier le journal de transactions (point de passage obligé de toute mise à jour) => RAID 10 avec plus ou moins de disque...
Pour l'agrégation par vues indexées/matérialisées Oracle fonctionne en mode asynchrone tandis que SQL Server le fait en mode synchrone.
Pour les IO oui, vous pouvez gagner énormément en organisant correctement vos fichiers et vos disques si le SGBDR sait gérer correctement les storages. C'est le cas d'Oracle et SQL Server. A lire sur le sujet : Question sur les fichiers et le stockage des données dans les SGBDR C/S
Les SGBDR fonctionnent exclusivement en RAM. Toutes les manipulations de données se font en mémoire. Le disques n'étant en fait qu'un épiphénomène, car on ne sait toujours pas fabriquer des RAM non volatile. Les SGBDR commencent par travailler d'abord en mémoire et écrivent le minimum de données de manière synchrone (transaction uniquement en mode WAL) et repoussent l'écriture des données en rafales par sessions de manière optimisées (recherches du trajet minimal pour la tête de lecture du disque lorsque c'est possible - DB2, Oracle, SQL Server par exemple - pas PostGreSQL).
La mise en RAM se faisant en mode LRU (Last Recent Use) : plus une données à été récemment utilisée, plus il est probable qu'elle soit rapidement réutilisées. Pour cela les SGBDR (PG compris) maintiennent des statistiques d'exécution.
Le parallélisme des SGBDR par "scaling out" est une illusion, car il faudrait faire en sorte que les données soient simultanément écrites sur tous les serveurs. Et ce travail pénaliserait de beaucoup les lectures. La duplication des données doit donc être réservée à des cas précis et particulier...
L'utilisation des ORM est le plus sur moyen d'avoir les performances les plus catastrophiques possible. Lisez ce que j'ai écrit à ce sujet : Darwinisme et informatique : les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse
Enfin, lorsque l'on doit travailler sur des masses de données importantes il faut qu'une même requête puisse être multithraadée. Ce n'est pas le cas de PG qui ne sait pas faire.
A +
Veuillez m'excuser pour cette erreur de copier/coller de RAISE NOTICE, le problème persiste toujours :
Pour une explication détaillée, lire :
http://blog.developpez.com/sqlpro/p1006 … fonctions/
Notamment § 9 - GESTION D'ERREUR
Cet article compare les implémentations d'UDF sous PostGreSQL et MS SQL Server.
Anecdote : d'après ce forum, personne ne s'intéresse aux comparaisons entre SQL Server et PostGreSQL, votre demande est un réel démenti....
A +
Un exemple :
CREATE TABLE T1 (A INT, B INT, C INT);
CREATE TABLE T2 (A INT, B INT, D INT);
INSERT INTO T1 VALUES (10, 20, 99), (11, 21, 33);
INSERT INTO T2 VALUES (10, 20, 0), (11, 21, 0);
UPDATE T1
SET C = T2.D
FROM T2
WHERE T1.A = T2.A
AND T1.B = T2.B
AND C < 50
SELECT * FROM T1
A B C
----- ----- -----
10 20 99
11 21 0la principe est le même que dans SQL Server, mais comme la norme SQL interdit l'utilisation d'un alias pour la table cible d'une mise à jour et que PostGreSQL respecte ceci à la lettre, il faut tout simplement reprendre intégralement le nom de la table cible.
A +
Juste pour info pourquoi s'obstiner à comparer mssql et postgresql ?
De mon point de vue, je connais bcp de dba mssql et aucun ne passera sur postgresql.
Donc je trouve ces comparaisons complètement useless, comparer postgresql et oracle à du sens mais mssql....
Ben voyons... Serait-ce interdit ?
D'après vous SQL Server est une grosse merde tout juste bonne à remplacer Acces ???
Il est amusant de constater parfois des propos d'une flagrante incongruité pour ne pas dire plus !
De plus si je compare MS SQL Server et PostGreSQL c'est parce que :
1) je travaille avec ces deux solutions
2) peu de gens font ce travail
3) cela rend services à de nombreux utilisateurs qui connaissent l'un des système et cherchent à savoir comment l'implémenter dans l'autre...
À part cela, voulez-vous que je supprime cet article ?
En quoi cela vous gène t-il ?
Avez vous peur que SQL Server ne supplante PostGreSQL ?
J'en reste pantois... Je croyais le monde libre ouvert... Me fais-je des illusions ???
A +
Drôle d'idée que de créer des règles. Il vaudrait mieux passer par des triggers, ce qui diminuerait très fortement le nombre de requêtes SQL à exécuter. Ça vous éviterait aussi de lancer quatre DELETE quand un seul suffit. De plus, l'UPDATE que vous faite n'a aucun intérête. Votre règle (par exemple R_U_MSR_AN2008) ne devrait avoir qu'un DELETE et un INSERT.
C'est ce qui est montré dans l'aide en ligne à ce sujet : http://docs.postgresql.fr/8.2/ddl-partitioning.html
De plus passer par des déclencheurs ne réduit pas la complexité, il l'augmente vu qu'au lieu d'une règle il faut deux commandes :
- la création de la fonction trigger
- la création du trigger association la table et son événement et la fonction trigger.
tablespace... sous PostGreSQL ou elle est embryonnaire
C'est voulu ainsi. PostgreSQL se base fortement sur le système qui l'héberge.
Mais c'est bien dommage car l'intérêt majeur du partitionnement c'est le stockage physique ! Oracle qui s'installe sur de multiples plateformes propose une bonne gestion des espaces de stockage...
Depuis uelques moments déjà (la 8.4, soit plus de trois ans), le constraint_exclusion faut 'partition' par défaut, ce qui fait qu'il n'y a rien à faire. À se demander quelle version de PostgreSQL vous testez.
Petite erreur de ma part, c'est corrigé.
Rappelons pour information que cette table ne peut contenir aucune ligne puisqu'un trigger l'y empêche. La scrutation de cette table est donc parfaitement inutile et fait perdre du temps de traitement !
Pour le savoir, il faudrait qu'il puisse comprendre le code du trigger, ce qui n'est pas possible. De plus, la scrutation d'une table vide est nulle.
Oui, mais il aurait été plus simple de concevoir le système en permettant que les contraintes se propagent ou non de la table mère aux tables filles.
Il est d'ailleurs curieux de constater que la propagation des contraintes des tables en héritage est tantôt effectives pour certaines, tantôt non effectives pour d'autres.
Il aurait été plus intelligente soit de tout propager, soit de ne rien propager, soit de rajouter une option pour forcer la propagation au coup par coup ou globalement... Encore un point critique !
À nouveau PostGreSQL semble perdu alors qu'il n'a qu'une seule partition à scruter. Le plan graphique est encore plus immonde :
Merci de ne pas confondre PostgreSQL et pgAdmin. pgAdmin est un outil d'administration graphique qui va afficher le plan graphique, PostgreSQL est le serveur. Et PostgreSQL n'est pas perdu.
Certes, mais la complexité du plan textuel parle d'elle même !
Dans PostGreSQL, la nouvelle contrainte CHECK se propage dans les tables filles.
Vous voulez certainement dire qu'elle ne se propage pas.
À moins d'être idiot, je pense que vous vous trompez...
Démonstration :
CREATE TABLE T (C INT);
CREATE TABLE T1 () INHERITS (T);
ALTER TABLE T ADD CONSTRAINT K CHECK (C >= 0);
SELECT TABLE_NAME, CONSTRAINT_NAME, CONSTRAINT_TYPE
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE table_name IN ('t', 't1');
TABLE_NAME CONSTRAINT_NAME CONSTRAINT_TYPE
------------ ----------------- -----------------
t1 k CHECK
t k CHECK
INSERT INTO T1 VALUES (-1);
ERREUR: la nouvelle ligne viole la contrainte de vérification « t1 » de la relation « k »Il faut bien constater que la mise en œuvre du partitionnement sous PostGreSQL est très complexe et quasi infaisable en production
C'est très loin d'être le cas. J'ai plusieurs clients qui les utilisent avec bonheur. Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.
Si le critère de partition est immuable (ce qui en pratique est souvent le cas, mais s'il y a des erreurs de saisie....) cela simplifie les choses.
Mon article compare les deux solutions (SQL Server vs PostGreSQL) et montre à l'évidence que le coût induit par la complexité de mise en œuvre est très largement en défaveur de PostGreSQL... Pour 5 partitions, 28 créations d'objets et plus de 50 requêtes SQL et cela sans une gestion des espaces de stockage efficace. Je pense que c'est un record. Même MySQL parait plus simples et plus avancé sur ce coup là. D'ailleurs les développeurs de PostGreSQL sont très conscient que cette méthode est mal foutue.. A lire : http://wiki.postgresql.org/wiki/Table_partitioning
Je ne conteste pas l'utilisation intéressante du partitionnement, j'y ai même consacré un papier : Partitionner vos tables pour améliorer les performances
Je ne doute pas non plus du bonheur de vos clients... Reste que la facture est élevée ! C'est d'ailleurs tout à votre avantage pour vendre du service...
Je trouve très adroit de votre part de comparer une fonctionnalité qui existe dans SQLServer et qui n'existe pas en natif dans PostgreSQL. Très fair-play.
Je ne suis pas adepte du consensus mou ni du politiquement correct. Lorsque je compare c'est sur le plan technique et fonctionnel. Que cela vous chagrine, je le conçoit, mais là on est dans les émotions et non plus dans le discours technique. Ma volonté n'est pas de démolir PG qui reste un bon SGBDR adapté à des bases de moyennes et grande tailles. PG possède même certaines avancées qui dépassent SQL Server. Je n'en citerais que quelques unes : l'héritage des tables, les fonctions de fenêtrage avec la gestion des fenêtres (Rows / Range), un SIG à la hauteur... Et SQL Server possède aussi quelques défaut comme cet horrible contrainte UNIQUE qui ne permet qu'un seul NULL !
Autre chose, vous dites ne pas avoir eu de réponses sur les forums où vous avez posé des questions sur le partitionnement. Je ne sais pas sur combien de forums vous avez posé la question mais 1. ce n'était pas ici, et 2. sur pgsql-sql, vous avez eu deux réponses, mais vu comment vous accueillez les réponses, ce n'est guère étonnant que vous n'ayez pas de réponses. Pour les curieux, voir http://archives.postgresql.org/pgsql-sq … g00006.php
Sauf que vous ne m'avez toujours pas montré d'exemple !
Concernant les performances à la baisse, je ne vois aucun test de performance sur votre article. Uniquement (et c'est déjà bien) un test de la mise en place de cette fonctionnalité sur PostgreSQL et SQL Server.
C'était le but : montrer la mise en œuvre. Mais on ne peut pas douter de performances moindre à la lecture de certains plans de requête. Attention : j'ai volontairement choisit l'angle mise en œuvre, pas celui de l'exploitation.
La plupart des requêtes bénéficieront du gain du partitionnement et il est extrêmement difficile de réaliser un benchmark comparatif au niveau des performances. Moi je n'en ais pas les moyens. Mon entreprise, [url=http://www.sqlspot.com/]SQL spot[url]n'a qu'un seul acteur, moi même ! Peut être pouvez-vous vous en occuper chez Dalibo. Je serais heureux de vous y aider, car j’apprécie les show PostGreSQL que vous faites et auquel je tente de participer régulièrement...
Pour terminer il est extrêmement difficile de gérer les partitions au niveau du stockage.
Marrant ça, moi je fais un ALTER TABLE pour indiquer à la table fille son nouveau tablespace et c'est terminé.
Vous m'indiquerez comment vous pouvez rajouter une borne de partitionnement et scinder les lignes en deux espaces de stockage avec une seule commande ALTER TABLE. Je suis curieux de lire votre solution.
Bref, encore un article à charge de la part de SQLpro, rien de bien nouveau sous le soleil.
Visiblement vous ne lisez que les propos négatifs et les articles à décharge que j'écris. Ne seriez vous pas un tantinet partisan ???
Sachez que si je me suis intéressé à ce sujet, c'est parce que j'y ai été confronté pour une solution applicative écrite à l'origine avec PostGreSQL. Il s'agissait d'un système de gestion de données très critique (prévention des catastrophe naturelle) pour une collectivité territoriale. À l'origine le système était sous PG, mais compte tenu de la complexité du partitionnement, des performances médiocre des mises à jours lorsque le critère change et de l'impossibilité d'avoir une haute dispo en temps réel, le choix à basculé sous SQL Server en dépit des préconisations d'utilisation du "free" dans les sphères étatiques.
Aujourd'hui ce système qui gère le plus important réseau hydraulique de France est repris par de nombreuses autres collectivités et intéresse l'étranger. Ce n'est hélas pas avec PG que nous avons pu le concevoir.... (sinon, cela aurait sans doute coûter moins cher en licences, et en impôts !).
A +
A lire : http://blog.developpez.com/sqlpro/p1037 … son-postg/
Contenu :
1 - LE PRINCIPE DU PARTITIONNEMENT
2 - L'EXEMPLE
3 - TECHNIQUE DU PARTITIONNEMENT
3 - LA SOLUTION POSTGRESQL
PARTITIONNEMENT DE TABLE version PostGreSQL - PREMIÈRE CONCLUSION
4 - LA SOLUTION MS SQL SERVER
PARTITIONNEMENT DE TABLE version MS SQL Server - PREMIÈRE CONCLUSION
5 - MANIPULER LES DONNÉES D'UNE TABLE PARTITIONNÉE
5.1 - les insertions
5.2 - Les extractions
5.3 - Les suppressions
5.4 - les modifications
6 - LA VIE D'UNE TABLE PARTITIONNÉE
6.1 - ajouter un index
6.2 - Ajouter une colonne
6.3 - Ajout d'une clef
6.4 - Ajout d'une contrainte de validation
6.5 - Ajout d'une contrainte d'intégrité
7 - PARTITIONNEMENT MULTICOLONNE
8 - CONCLUSION PARTITIONNEMENT PostGreSQL vs MS SQL Server
Vos avis, vos commentaires seront appréciés.
Merci
Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.A+
Il est dommage que PostGreSQL n'implémente d'ailleurs pas toute la norme, car par exemple DEPTH FIRST est prévu dans la norme SQL. En sus, sachez que toutes les requêtes dans un SGBDR sont faites en mémoire, avec en sus l'optimisation, ce qui conduit dans les cas de fort volume à des performances au dessus de ce que vous feriez en codage C.
Il est aussi dommage que PostGreSQL contrairement à SQL Server ou Oracle ne soit pas capable de parallélisé une seule et même requête, car là encore les performances du SGBDR deviennent sans communes mesure à ce que l'on peut faire en C, à moins d'avoir prévu de lancer des threads en //
A +
D'ailleurs je n'ai pas trouvé un tableau de synthèse des fonctionnalités en fonction des versions de postgresql. Sais tu si cela existe ?
A +
Vous pouvez commencez par ceci :
Une analyse étant une suite de n processus enchaînés.
A +
J'aurais bien aimé pouvoir le faire avec postgres, mais je n'ai pas une connaissance suffisante de ses mécanismes internes pour faire ce que j'ai pu réaliser avec berkeleyDb. Ce sont des tables temporaires dont la durée de vie se limite à la requête postgres, qui me permettent de parcourir très rapidement le graphe des offres, et appliquer plusieurs algo de recherche. ...
Les parcours de graphes peuvent être réalisés avec de simples requêtes SQL récursives. La syntaxe normalisée depuis la version 1999 du langage SQL permettant ce type de requête est implémenté depuis la version 8 de PG.
Lisez l'exemple de recherche du plus court chemin que j'ai donnée dans cet article :
http://sqlpro.developpez.com/cours/sqls … ecursives/
A +
Une transaction se termine toujours soit par un COMMIT soit par un ROLLBACK. Il n'y a pas d'intermédiaire.
Nous avons tous les deux raison en ce sens qu'au moment de la coupure les transactions en cours sont dans un état "pendant" (de verbe pendre) c'est à dire non finalisées (le SGBRD ne peut pas savoir à l'avance quand aura lieu la coupure !!!! il n'est pas voyant extra lucide...)
Au moment de la reprise du service, le SGBDR interdit l'utilisation des bases de données tant qu'il n'a pas vérifié s'il y avait des transactions en cours.
Si ce n'est pas le cas il rend immédiatement la main et les utilisateurs peuvent travailler. La base est intègre.
S'il y a des transactions non finalisées, elles vont être annulées par un ROLLBACK forcé, et tant que ces ROLLBACK ne sont pas finalisés, alors les utilisateurs ne peuvent pas travailler car la base n'est pas intègre (certaines données sont incohérente). Une fois les ROLLBACK achevés, la basez devient de nouveau intègre et les utilisateurs peuvent désormais s'en servir.
Le mécanisme qui permet ceci est le journal de transaction qui enregistre tous les changements d'état de la base et les images avant et/ou après des données manipulées. Ceci permet donc de revenir à un état antérieur intègre de la base. Pour ce faire le journal de transaction enregistre les données dans le journal avec un marquage à base de LSN (Log Segment Number) et répercute ce LSN dans les fichiers de données afin de contrôler la cohérence. S'il y a différence dans les LSN entre les données et le JT, alors on revient sur une version intègre antérieure en se calant sur un LSN "stable"... (j'ai beaucoup simplifié...)
Ceci a été mis au point dans les années 70 par les travaux de Gray et Bernstein et l'algorithme utilisé pour ce faire est basé sur ARIES dans la plupart des SGBDR (PG compris) avec quelques variantes spécifiques.
Pour en savoir plus :
Les transactions : http://sqlpro.developpez.com/cours/sqlaz/techniques/
ARIES : http://www.sai.msu.su/~megera/postgres/ … -mohan.pdf
A +
Il n'y a pas de temps maximum (ni time out d'aucune sorte) et la durée d'une transaction peut être de plusieurs jours si nécessaire.
En cas de coupure de courant, si une transaction est en cours, elle est annulée par un ROLLBACK qui s'effectuera lorsque le serveur sera remis en marche (phase de RECOVERY).
Toutes les autres transactions sont validées.
A +
Que vous soyez avec des vues ou non ne change rien à l'optimisation, car le moteur "déplie" les vues en faisant une transformation au niveau table.
Cependant il est possible qu'en intégrant vos vues à votre requête vous vous rendiez compte qu'une simplification est possible. C'est donc une bonne pratique que de réintégrer le code SQL des vues dans les requêtes lorsque ces dernières sont complexes.
Vous pouvez augmenter la valeur du join_collapse_limit de façon assez important et de modifier le geqo_threshold en conséquence. Personnellement je met 64 et 16, car les bases de données que je travaille sont assez complexes. Mais vous devez avoir le matériel en conséquence (CPU, RAM...).
A +
Si c'est aussi dangereux, car cela peut l'induire en erreur. En effet entre un index non unique (donc avec des données supplémentaire de contrôle d'unicité) et un index forcément unique car clef primaire, l'optimiseur peut se tromper aisément et conduire à un plan stupide... Je commencerais par supprimer ces index !
A +
La question est donc, pourquoi avez vous fait un index sur a et sur b en sus de la clef primaire ????
Une clef primaire créé systématiquement un index. Il est donc inutile et dangereux d'en placer un second totalement redondant !
En sus augmenter le nombre de secteur dans l’histogramme statistique d'une clef primaire (donc unique) n'est généralement pas une bonne idée, car il faut lire les 1000 entrées de stats avant de décider du plan.... Une bonne valeur dans ce cas est plus proche de 100...
A +