Cette version apporte de nouvelles fonctionnalités comme le "commit à deux phases" ou les paramètres IN / OUT pour les fonctions. Elle contient également de nombreuses améliorations concernant les performances : bitmap index, shared row lock, partitionnement de tables.
Il est savoureux de constater que c'est également aujourd'hui que Computer Associates a annoncé la mise en Open Source de sa base de données Ingres.
NdM : merci à François Suter pour avoir également proposé une dépêche à ce sujet. Nouvelles fonctionnalités avancées
Rôles : PostgreSQL supporte désormais les « rôles de bases de données », ce qui simplifie la gestion de grands nombres d'utilisateurs avec des droits d'accès complexes.
Paramètres IN/OUT : Les fonctions de PostgreSQL acceptent maintenant les paramètres IN, OUT et INOUT, ce qui améliore sensiblement le support de logiques applicatives complexes pour les plateformes J2EE et .NET.
Commit à deux phases (2PC) : Réclamé depuis longtemps pour les applications WAN et les centres de calcul hétérogènes, ce dispositif permet des transactions ACID entre des serveurs distants.
Amélioration des performances
Amélioration des performances sur les multiprocesseurs (SMP) : le gestionnaire de la version 8.1 a été retravaillé de manière à fournir une augmentation quasi-linéaire des performances par rapport au nombre de processeurs, apportant des gains significatifs d'exécution sur des unités centrales de type 8-way, 16-way, double-coeur et multi-coeur.
Parcours de cartes («Bitmap scan») : les index seront dynamiquement convertis en cartes (bitmaps) en mémoire lorsqu'un cas approprié se présente, soit une exécution jusqu'à vingt fois plus rapide lors d'interrogations d'index complexes sur de très grandes tables. Cela contribue également à simplifier la gestion de la base de données en réduisant considérablement le besoin d'index à colonnes multiples.
Partitionnement des tables : le planificateur de requêtes est maintenant capable d'éviter de parcourir des sections entières d'une grande table en utilisant une technique connue sous le nom d'« exclusion de contraintes ». Semblable à la division des tables, que l'on rencontre dans d'autres systèmes, ce dispositif améliore la vitesse d'exécution et la gestion des données pour des tables de plusieurs gigaoctets.
Verrous de ligne partagés : Le verrou « plus fin que la ligne » utilisé par PostgreSQL autorise des niveaux encore plus élevés de concurrence d'accès grâce à l'ajout du verrou de ligne partagé pour les clefs secondaires. Les verrous partagés améliorent l'insertion et la mise à jour dans beaucoup d'applications avec un gros volume de transactions (« Online Transaction Processing » ou « OLTP »).
Autres fonctionnalités de cette version
Parmi les 120 nouveautés et améliorations non mentionnées par le communiqué de presse (cf. supra), on trouve :
* GiST : Le « Generalised Search Tree (GiST) » de PostgreSQL (mécanisme d'indexation optionnel) a été amélioré pour supporter la concurrence d'accès à haute vitesse et les performances en mise à jour que l'on n'obtient généralement qu'en utilisant des index de type B-Tree. GiST est la base de l'indexation en texte intégral (TSearch2), des systèmes d'information géographiques (GIS) et des requêtes d'analyse d'indexation arborescente de PostgreSQL. Grâce à ce perfectionnement, les requêtes sur les types de données complexes maintiennent de bonnes performances dans les applications à haute disponibilité.
* Réécriture de COPY : La commande COPY a été réécrite pour un traitement jusqu'à 30% plus rapide des données en bloc. En ajoutant à cela les améliorations de charge obtenues avec CSV, ceci rend le chargement de grosses bases de données dans PostgreSQL plus rapide que jamais.
* Mémoire partagée 64-bit : le gestionnaire de tampons peut maintenant utiliser jusqu'à deux téraoctets de RAM sur les plateformes 64-bits, préparant ainsi PostgreSQL pour les serveurs à grande mémoire du futur.
* Autovacuum intégré : le « ramasse-miettes » de base de données de PostgreSQL a été amélioré et intégré dans le programme principal du serveur, ce qui rend les serveurs PostgreSQL plus simples à installer et administrer.
* Accélération des agrégations : les fonctions d'agrégation ont été améliorées afin d'accélérer encore les requêtes d'analyse. Les développeurs ont à la fois réécrit la gestion de la mémoire pour les agrégations et optimisé l'indexation de MIN() et de MAX().
* Fonctions d'administration : de nouvelles fonctions ont été ajoutées pour récupérer des informations concernant le serveur et effectuer des tâches administratives, le tout en ligne de commande PSQL.
* Fonctions de compatibilité : les fonctions lastval(), greatest() et least() ont été ajoutées pour faciliter le portage des applications MySQL et Oracle.
Aller plus loin
- La traduction de l'annonce officielle (4 clics)
- Miroirs (4 clics)
- Bittorrent (1 clic)
- Notes de version (1 clic)
# Avantage pour un néophyte ?
Posté par gasche . Évalué à 7.
Est-ce que PostGreSQL apporte un gain par rapport aux autres solutions libres comme MySQL pour un débutant, c'est à dire qui ne maitrisera pas les fonctions avancées.
J'ai cru comprendre que sa spécialité était les relations "complexes" entre les tables, mais je ne sais pas trop ce qui est complexe et ce qui ne l'est pas. Est-ce que les relations des tables d'un forum bourré d'options sont "complexes" ?
[^] # Re: Avantage pour un néophyte ?
Posté par erik_lallemand . Évalué à 10.
Non! Clairement, quand on est débutant sur l'un des 2 systèmes, on utilise uniquement des fonctionalités simples, on traite des petits volumes de données, et on gère peu d'utilisateurs simultanément. Par conséquent, on est loin d'atteindre les limites d'un système ou d'un autre, et il est alors évidemment plus simple de continuer à utiliser le système qu'on connait.
[^] # Re: Avantage pour un néophyte ?
Posté par reno . Évalué à 9.
Maintenant je ne suis pas un expert ni dans l'un ni dans l'autre..
[^] # Re: Avantage pour un néophyte ?
Posté par BiBite . Évalué à 10.
- Tu fais un update du genre:
update table1 set result = 'OK' where val = '10';
avec MySQL, si tu as 10 tuples (lignes) avec result val = '10' et que tu as déjà 3 lignes avec result = 'OK', MySQL te dit qu'il a modifié 10 tuples...
Super chiant dans certaines applis pour vérifier que tu as bien modifié ce que tu voulais. Les autres BDD auraient retourner 10 lignes modifiées.
- Tu fais un update (encore) du genre:
update table1 set date = '2005-12-32';
MySQL accepte sans broncher, alors que la date n'est pas valide (32 décembre).
Idem si on essaye de mettre un chaine de 20 caractère dans un varchar(10), pas de problème... Sauf que du coup la chaîne est tronquée et tu ne t'en rends pas compte.
Bref, au moins avec postgres tu limite ce genre de mauvaise surprises...
[^] # Re: Avantage pour un néophyte ?
Posté par briaeros007 . Évalué à 6.
Tu voulais sans doute dire 7, non?
[^] # Re: Avantage pour un néophyte ?
Posté par Xavier Poinsard . Évalué à 6.
update table1 set result = 'OK' where val = '10' and not result='OK'
[^] # Re: Avantage pour un néophyte ?
Posté par Pooly (site web personnel) . Évalué à 4.
En ligne de commande, MySQL va te sortir le nomber de lignes qui correspondent a ta requete, et le nomber de lignes modifiés. Donc tu as les deux informations. Si tu utilise l'API C, il y a une option pour avoir soit le nombre de 'match' ou le nomber de lignes modifiés.
[^] # Re: Avantage pour un néophyte ?
Posté par Xavier Poinsard . Évalué à 6.
Ainsi de nombreuses applis développées pour MySql sont difficilement portables vers d'autres SGBD.
[^] # Re: Avantage pour un néophyte ?
Posté par Dring . Évalué à 2.
Comme déjà indiqué plus haut, c'est au contraire un comportement standard. Concernant les "autres BDD", je sais que Sybase au moins fait la même chose ; il me semble que Firebird/Interbase aussi.
D'autre part, je ne vois pas trop l'intérêt de vérifier que le nombre de ligne modifiées correspond, sauf dans le cas où il n'y en a qu'une.
Soit ça marche, soit ça échoue ; et c'est normalement tout ce que tu as à savoir.
[^] # Re: Avantage pour un néophyte ?
Posté par erik_lallemand . Évalué à 4.
La question concernait le besoin (ou non) de passer de MySQL à PostgreSQL pour un débutant. Alors oui, PostgreSQL est plus strict sur les vérifications de dates. On peut aussi trouver à MySQL des bons points qui font défaut à Postgres.
Mais pour un débutant, ces petites différences ne justifient pas de tout remettre à plat, de tout remettre en cause. Déjà, s'il est vraiment débutant, je tire mon chapeau s'il stocke ses données de dates sous un format de données de type "Date/time". Quand j'ai commencé sous MySQL il y a 5 ans, j'aurais sans doute pu le faire, mais j'ai utilisé des chaines de caractères parce que c'était tellement plus simple et suffisant. Rappelez-vous, les gars! dé-bu-tant!
[^] # Re: Avantage pour un néophyte ?
Posté par briaeros007 . Évalué à 0.
Enfin c'est quand meme du sql a la base . C'est pas completement incompatible. Non?
[^] # Re: Avantage pour un néophyte ?
Posté par Xavier Poinsard . Évalué à 10.
Travailler avec PostgreSql permet d'être ensuite à l'aise avec la plupart des bases de données.
[^] # Re: Avantage pour un néophyte ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Si ton programme modifie une donnée qui ne doit pas l'être (mettre un id de categorie qui n'existe pas dans un enregistrement de produit par exemple), postgresql va raler car ce n'est pas normal. C'est donc des bugs vite détéctés.
Mysql ne va pas raler et va laisser faire (sauf si tu utilises des tables Innodb, mais ce n'est hélas pas le format par défaut et les développeurs choisissent implicitement MyIsam, qui ne prend donc pas en charge les clés étrangères)
[^] # Re: Avantage pour un néophyte ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Dans la table clients, chaque compte ne peut exister qu'une fois. Cette contrainte d'intégrité se nomme primary key ou clé primaire.
On ne peut faire des mouvements que sur des comptes existants. Donc dans la table des mouvements, on va déclarer que le numéro de compte doit exister dans la table des clients; on la nomme foreign key ou clé étrangère.
L'énorme intérêt d'une base de données avec des contraintes d'intégrité fortes, c'est que l'on peut modifier les données avec tous les outils que l'on veut sans risquer de perdre leur cohérence, même sur un bug de programmation.
L'intérêt des fonctions et des triggers est le même : on déclare que lorsqu'on insère/modifie/supprime quelque chose dans la base de données, on exécutera la fonction qui vérifiera/modifiera/archivera/etc les données. Par exemple, si je gère du matériel, le moteur A est dans le stock, casier X. Je le confie au labo d'essais.
Dans la base de données il y a le lien (moteurA)-(stockX) Je modifie avec (moteurA)-(labo essai). Le trigger va alors appeler une fonction qui va stocker dans une table historique que :
- (moteurA) est enlevé de (stockX) par Mr Machin à telle date.
- (moteurA) est associé à (labo essai) par Mr Machin à telle date.
- (stockX) a un (moteurA) de moins certifié par Mr Machin à telle date.
- (labo essai) possède (moteurA) certifié par Mr Machin à telle date.
Je peux vous assurer que lorsque l'on a des milliers d'éléments dans une base de données, un défaut d'intégrité tel que (moteurA) n'est pas à l'endroit indiqué, est bien plus difficile à corriger qu'un bug dans un programme.
J'espère que ces lignes permettront à ceux qui ne sont pas familiarisés avec les contraintes d'intégrité de mieux en percevoir l'intérêt.
[^] # Re: Avantage pour un néophyte ?
Posté par Laurent PELLISSIER . Évalué à 4.
Dans la mesure où les 2 produits ont une durée d'aprentissage équivalente mieux vaut dès le départ choisir celui qui aura le maximum d'évolutivité. Dans ce cas PostgreSQL a montré depuis des années sa plus grande richesse fonctionnelle. Le choix me semble vite fait.
# Ingres : trop tard ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Ouvrir son code est une bonne stratégie à deux conditions ; que la licence soit libre (selon les 4 libertés de la FSF) et que ce soit fait à temps. On peut craindre qu'il ne soit déjà trop tard.
[^] # Re: Ingres : trop tard ?
Posté par snt . Évalué à 10.
( c'est quand meme un comble : on en arrive à avoir plus de SGBD gratuits et/ou libres que de navigateurs ou de suite bureautique )
[^] # Re: Ingres : trop tard ?
Posté par lezardbreton . Évalué à 4.
[^] # Re: Ingres : trop tard ?
Posté par Xavier Poinsard . Évalué à 2.
[^] # Re: Ingres : trop tard ?
Posté par Franck Routier (Mastodon) . Évalué à 1.
cf http://www.postgresql.org/about/history
Ce sont des cousins, comme Sybase et MS Sql*server le sont...
Preuve de la supériorité du modèle économique du libre ? :-)
# Il ne lui manque plus que le cluster...
Posté par Hubert FONGARNAND . Évalué à 10.
Félicitation tout de même pour les développeurs de PostGreSQL, ce produit est vraiment très prometteur!
[^] # Re: Il ne lui manque plus que le cluster...
Posté par Stéphane Traumat (site web personnel) . Évalué à 5.
http://about.me/straumat
[^] # Re: Il ne lui manque plus que le cluster...
Posté par ArBaDaCarBa . Évalué à 2.
[^] # Re: Il ne lui manque plus que le cluster...
Posté par Philippe Poumaroux (site web personnel) . Évalué à 3.
http://pgfoundry.org/softwaremap/trove_list.php?form_cat=392
[^] # Re: Il ne lui manque plus que le cluster...
Posté par Hubert FONGARNAND . Évalué à 2.
http://gborg.postgresql.org/project/erserver/projdisplay.php
" is deprecated: the project has been mostly abandoned by the developers in favour of Slony-I. Go to the Slony-I web page for more info."
Slony-I ne permet pas le load balancing.
Par contre le projet pgcluster à l'air interessant, quelqu'un l'aurait-il déjà utilisé en environnement de prod?
[^] # Re: Il ne lui manque plus que le cluster...
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
Alors, avant d'utiliser des 7.3.10 en cluster et en production, vaut mieux aller faire un tour sur pgpool et Slony1 qui permettent la réplication et la répartition de charge ;-)
[^] # Re: Il ne lui manque plus que le cluster...
Posté par Philippe Poumaroux (site web personnel) . Évalué à 4.
http://pgcluster.projects.postgresql.org/
[^] # Re: Il ne lui manque plus que le cluster...
Posté par bastouille . Évalué à 3.
Par contre, pour avoir testé c-jdbc au mois de février, je pense que ce projet doit maintenant être suffisament avancé pour bien fonctionner (à l'époque, il y avait encore quelques bugs génant : reprise après incident très délicate, octopus très buggué).
Enfin, j'utilise Slony-1 en production depuis maintenant 4 mois : RAS.
Sa seule limitation est la non réplication des blobs.
Couplé avec IPVS, on a un système de fail-over automatique, mais c'est vrai pas de répartition de charge comme avec c-jdbc.
[^] # Re: Il ne lui manque plus que le cluster...
Posté par Hubert FONGARNAND . Évalué à 1.
[^] # Re: Il ne lui manque plus que le cluster...
Posté par bastouille . Évalué à 1.
# Comparatif de performances
Posté par Christophe Merlet (site web personnel) . Évalué à 0.
Aujourd'hui. En tant que base de données Web, quelle est la plus performante ?
[^] # Re: Comparatif de performances
Posté par Anonyme . Évalué à 10.
Déjà ca part mal : ca fait plutôt restrictif comme usage, même si c'est la plus répendue, l'utilisation pour le web est limitée.
En fait MySQL et PostgreSQL ont des orientations tellement différentes que ca ne sert a rien de les comparer pour savoir laquelle est la "meilleure".
Mais globalement :
- PostgreSQL est orienté contrainte, procédure stockées et respect de paradygmes de SGBD.
- MySQL est plutôt orienté performances brutes, légerté quitte a un peu rustique (exemple rapide : gestion des clés étrangères), et je ne sais pas si cela a changé dans la version 5, mais les requètes imbriquées n'ont pas été supportée pendant longtemps - alors que c'est élémentaire en l'algère relationnel.
[^] # Re: Comparatif de performances
Posté par Christophe Merlet (site web personnel) . Évalué à -10.
Ton "globalement" n'est qu'un étalage de lieu communs répété depuis plus de 6/7 ans.
On est fin 2005, MySQL et PostgreSQL ont beaucoup évolué. Il est temps de faire table rase des idées reçus et repartir sur des faits avérés. Parler de "paradygmes" et de "fonctionnalités" ne me dit toujours pas lequel est le plus performant pour une application web !
[^] # Re: Comparatif de performances
Posté par crusher . Évalué à 5.
Celui que tu auras testé avec ton application web et ton matériel !
Ta question est en fait trop simpliste, il faut tu sois plus précis.
Si réellement ton seul critère est la performance, tu achètes un max de RAM et tu charges toute la base en mémoire et là tu auras des performances excellentes mais sans sauvegarde ...
[^] # Re: Comparatif de performances
Posté par neil . Évalué à 1.
[^] # Re: Comparatif de performances
Posté par billy . Évalué à -4.
c'est archi faux ca, même avec toute la base de donnée en RAM postgre est incroyablement plus que MySQL/INNODB. c'est un fait.
[^] # Re: Comparatif de performances
Posté par briaeros007 . Évalué à 0.
C'est un fait qui viens d'ou sans indiscretion?
[^] # Re: Comparatif de performances
Posté par briaeros007 . Évalué à 0.
(la fatigue...)
[^] # Re: Comparatif de performances
Posté par animal_omega . Évalué à 10.
Pour commencer, "base de donnée web" n'a pas de sens.
BDD c'est un moyen de stocker les données
le Web c'est un protocole de communication.
donc on peut imaginer n'importe quel application, de la plus simple a la plus complexe, qui utilise une BDD pour stocker ces données et le Web pour communiquer.
Donc j'imagine que la question est du style "quelle est la base de donnée la plus performante pour les portails/forum/blog/..."
(ok, je pinaille)
Mais la encore, je serais incapable de repondre. Prennons le cas d'un forum, ben moi je repondrais "ca depend comment c'est codé".
Y'a moyen de coder un forum en utilisant des triggers, des transactions et tout pleins de trucs sympathiques pour quelqu'un qui tiens a garder une certaine intégrité dans ces données, meme en cas d'un bug dans l'application ou d'une interruption brutale du systeme.
Mais il y a aussi moyen de coder un forum sans tout ca, juste avec quelques tables avec des relations basiques.
bref... je crains qu'il va falloir etre plus precis pour avoir une réponse.
Le mieux est de prendre l'appli et de faire des benchmark :)
[^] # Re: Comparatif de performances
Posté par Christophe Merlet (site web personnel) . Évalué à -10.
C'est comme si on te demandait quelle est la voiture la plus rapide entre une clio et une c3 et que tu répondes qu'il y en a une qui est rouge et l'autre qui a une boite à gants ! Merci d'avoir joué
[^] # Re: Comparatif de performances
Posté par Toufou (site web personnel) . Évalué à 10.
Parler de performance sans donner d'informations sur le contexte n'a pas de sens. Base de données web n'est pas un critère ayant un impact sur la performance (en admettant que performance veuille dire rapidité). Ce qui va surtout jouer c'est le nombre de tables, les relations entre ces tables et la complexité des manipulations de données.
[^] # Re: Comparatif de performances
Posté par Christophe Merlet (site web personnel) . Évalué à -9.
Ya pa de raisons de passer du temps à migrer sous PostgreSQL vu que ses avantages ne sont pas évidents !
[^] # Re: Comparatif de performances
Posté par Pierre Tramonson . Évalué à 10.
[^] # Re: Comparatif de performances
Posté par erik_lallemand . Évalué à 10.
Vu comme tu es poli avec ceux qui font des efforts pour te répondre (même si tu n'es pas satisfait des réponses, tu pourrais réorienter, ou fournir un complément d'informations sur ce que tu souhaites savoir), garde ta config actuelle et consacre ce temps supplémentaire à apprendre le respect! Ca sera plus déterminant pour ton avenir que les subtilités entre 2 SGBD.
[^] # Re: Comparatif de performances
Posté par un_brice (site web personnel) . Évalué à 10.
Moi par contre ça m'a pas arrêté : je l'ai joué à pile ou face. J'ai fait pile, tu devrais utiliser MySQL.
[^] # Re: Comparatif de performances
Posté par pshunter . Évalué à 4.
[^] # Re: Comparatif de performances
Posté par Xavier Poinsard . Évalué à 4.
Utiliser trigger et procédures stockées diminue fortement la portabilité de l'application, tandis que les transactions et les clés étrangères/primaires sont standardisées (sauf pour la création des contraintes) et donc portables.
[^] # Re: Comparatif de performances
Posté par pshunter . Évalué à 4.
En revanche je serais moins catégorique sur la notion d'intégrité. On peut parler d'intégrité au-delà de ce que le modèle relationnel peut exprimer, et dans ce cas une partie de la «logique» participe aux contraintes d'intégrité que le standard ne peut exprimer...
Pour en avoir fait l'expérience, il est parfois difficile de tracer la ligne entre ce qui sera fait par la base et ce qui sera fait par l'applicatif sans tomber dans des extrémismes (rabaisser la BDD à un système de fichiers glorifié ou rabaisser l'applicatif à un visionneur/éditeur de la base).
Dans tous les cas, s'il y a une des extrêmes à choisir je prendrais plutôt la deuxième, je trouve ça plus «économique» en quantité de travail ;)
[^] # Re: Comparatif de performances
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Et je ne vois pas en quoi il est difficile de tracer cette ligne. Nos applis n'ont pas de problèmes, on les développe et des outils se débrouillent pour tout stocker.
http://about.me/straumat
[^] # Re: Comparatif de performances
Posté par Hardy Damien . Évalué à 4.
Dam
[^] # Re: Comparatif de performances
Posté par briaeros007 . Évalué à 2.
[^] # Re: Comparatif de performances
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
http://about.me/straumat
[^] # Re: Comparatif de performances
Posté par canarlake . Évalué à 1.
1 portabilité de la base de données:
1.1 portabilité entre différents moteurs de bases :
La, c'est clair que les triggers et procédures stockées diminuent la portabilité
1.2 portabilité entre différents OS :
Pas trop de pb pour ce qui est de Mysql et Postgresql
2 portabilité des clients :
L'intégration de procédures au moteur de base allège la tâche des clients, ce qui facilite la conception de clients pour divers environnements. C'est une forme de portabilité.
Daniel
[^] # Re: Comparatif de performances
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
mm dans ce cas la, mieux vaut utliser un serveur d'applications, ca permet de garder la portabilité.
http://about.me/straumat
# Un manque dans l'offre
Posté par salvaire . Évalué à 7.
- PostgreSql, la solution complète
- MySql, la solution optimisant la rapidité
- SqlLite, la solution poids plume
Ceci est une bonne chose, car se sont des besoins différents.
Par contre, il y a un gros manque. Une base de donnée optimisé en lecture seule. C'est à dire que la mise à jour n'est pas implémenté. Les base de données tels que PostgreSql/MySql sont optimisé pour des accès concurrents en écriture ou en mise à jour. Cas typique des applications commerciales. Or ceci a un coût en complexité et en rapidité. Or des données mesurées sont par définition fixe. On pourrait donc obtenir un gain important avec une base de données optimisé pour la lecture seule. Malheureusement, personne ne semble intéressé par ce cas.
[^] # Re: Un manque dans l'offre
Posté par Olivier Jeannet . Évalué à 8.
Je pense que tu te trompes, car une des faiblesses de MySQL depuis toujours a été son écroulement lors d'accès concurrents en écriture, contrairement à (par exemple) PostgreSQL; ceci en particulier pour les tables au format "historique", à savoir MyISAM (je crois que pour InnoDB, qui permet du transactionnel, c'est différent).
On pourrait donc obtenir un gain important avec une base de données optimisé pour la lecture seule.
Dans MySQL, une table de type MyISAM (relativement basique) est réputée être très rapide en lecture. Ce format convient bien si on met peu à jour la table.
[^] # Re: Un manque dans l'offre
Posté par Xavier Teyssier (site web personnel) . Évalué à 9.
Ça s'appelle un annuaire, et le protocole LDAP est là pour ça : gèrer des annuaires, c'est à dire des données dont le stockage est optimisé pour la lecture.
A noter que LDAP n'est pas vraiment un annuaire en soi, mais juste un protocole permettant de gèrer des annuaires. Après, les données peuvent être stockées dans n'importe quelle base (typiquement, OpenLDAP peut utiliser BerckeleyDB, PostgreSQL, et surement d'autre.).
[^] # Re: Un manque dans l'offre
Posté par salvaire . Évalué à 4.
Je parle de données en général. Par exemple, une base de donnée contenant la morphologie d'une population.
[^] # Re: Un manque dans l'offre
Posté par Mr F . Évalué à 3.
[^] # Re: Un manque dans l'offre
Posté par Guillaume Knispel . Évalué à 3.
Je croyais que c'étais l'inverse ?
[^] # Re: Un manque dans l'offre
Posté par ham . Évalué à 3.
Pour la recherche sur des donnée organisé de maniere hiearachique il y a des fortes chances que une structure d'arbre soit plus puissante dans ce cas.
Si tu veut modeliser des relations complexe entre objet, la la base de donnée peut etre plus a l'aise.
Ensuite qu'est ce qui est plus puissant, un graphe orienté ou un hypergraphe, les chenilles (sisi )??
[^] # Re: Un manque dans l'offre
Posté par Guillaume Knispel . Évalué à 1.
Mais c'était juste une réaction pour dire que les DB n'était pas forcement "à plat", et que d'ailleurs un de leur aspects faisait des arbres un sous ensemble.
[^] # Re: Un manque dans l'offre
Posté par Mat (site web personnel) . Évalué à 5.
J'ai déjà rencontré le problématique que tu évoques. J'avais à travailler avec une base de données qui donnait des relations entre des mots. (synonymie, antonymie, ....) donc jamais mise à jour.
J'y faisais d'intenses requêtes dessus. Là où sqlite s'est avéré décisif dans mon choix c'est que la base de données (le fichier .sqlite) pesait environ 800Mos, ce qui faisait quelques milliers de relations sur un lexique de 300 000 mots. (j'ai utilisé sqlite2 et non sqlite3 car les fichiers sont moins volumineux avec le 2 qu'avec le 3 et les nombreux indexes ajoutés lors du passage à la version 3 n'amélioraient pas vraiment les perfs)
Donc hop, en chargeant toute la base en RAM, les temps de réponse étaient devenus bien meilleurs que lors de mes tests sur MySql ou Postgres.
Ca implique cependant d'avoir moult RAM ou bien une machine dédiée à cet usage. Et puis, avec sqlite de base, il n'y a pas de serveur...
[^] # Re: Un manque dans l'offre
Posté par Raoul Volfoni (site web personnel) . Évalué à 10.
Le standard SQL 92 a définit une norme sur les niveaux d'isolation des transactions (source: Second Informal Review Draft ISO/IEC 9075:1992, Database Language SQL- July 30, 1992). Document très coûteux mais certainement dispo quelque part...
Il existe trois phénomènes qui peuvent apparaître durant une lecture des données dans la base: les Dirty read, les Non-repeatable read et enfin les Phantoms. Selon le niveau d'isolation choisi pour la transaction, il se peut que l'un ou plusieurs (voire aucun pour serializable) de ces phénomènes apparaisse (C.f. tableau page 69 pour ceux qui ont le document normatif).
Tout SGBD voulant être conforme avec cette norme se doit donc d'implémenter les 4 niveaux d'isolation suivants:
- READ UNCOMMITTED
- READ COMMITTED
- REPEATABLE READ
- SERIALIZABLE
Mettre en place une solution style Datawarehouse (lecture seule) avec PostgreSQL est très simple: il suffit d'éditer le fichier postgresql.conf et d'y placer les paramètres suivant:
default_transaction_isolation = 'READ UNCOMMITTED'
default_transaction_read_only = yes
Dans la mesure où les transactions ne poserons pas de verrou exclusif sur les ressources, la lecture sera extrèmement rapide si les index sont correctement définis. On peut également penser qu'une telle base de données serait parfaitement adaptée à une pile de disques en RAID 0. Avec de bons disques et une carte Raid munie d'une bonne quantité de RAM, on devrait obtenir des perfs à faire pâlir mySQL en isam.
Conclusion: tous les bons SGBDR savent remplir ce rôle. J'ajoute qu'avant qu'une base puisse être en lecture seule il faut quand même l'avoir alimentée avec des données...
ps: pour ceux qui aiment les chiffres bruts qui ne veulent rien dire (suivez mon regard qui remonte dans les commentaires), j'ai chargé hier une table de 150 millions de lignes à la vitesse de 48000 lignes/sec.
[^] # Re: Un manque dans l'offre
Posté par Franck Routier (Mastodon) . Évalué à 1.
Attention, ne pas confondre un index bitmap à la nouveauté de la 8.1, qui est (si j'ai bien compris) de construire et garder une image bitmap de l'index en mémoire pour les interrogations ultérieures (une sorte de cache).
Les index bitmap sont des index très compacts, donc très vite lus, mais très long à mettre à jour. Ils sont donc particulièrement adaptés aux datawarehouses...
Dans Postgresql, ils existe des tentatives d'implémentation ou des prototypes, mais rien de de vraiment intégré au standard...
cf http://www.sai.msu.su/~megera/postgres/gist/
Dommage.
[^] # Les vues
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> lecture seule. C'est à dire que la mise
A mes souvenirs, une vue est en lecture seule (je ne suis pas spécialiste des bases de données). Donc, normalement, il suffit de créer une vue pour avoir un accés en lecture seule donc optimisé (mais ca, c'est la boulot de la base de donnée).
D'ailleurs, un client qui n'a pas besoin d'écrire devrait toujours utiliser des vues, rien que par principe de précausion.
[^] # Re: Les vues
Posté par Xavier Poinsard . Évalué à 1.
Il est toutefois vrai que la mise à jour d'une vue implique que les clés primaires des tables modifiées soient présentes dans la vue.
# table héritée
Posté par Axel R. (site web personnel) . Évalué à 9.
Quand tu créer une ligne dans "femme", ça créer en même temps une ligne dans "individu"...
Bon, c'est juste pour expliquer en vitesse ce que c'est, mais je peux vous assurer que c'est vachement pratique. En ce moment, je travaille pour un projet qui utilise PostGres et nous avons toutes nos tables qui hérites d'une même table (parfois avec des tables intermédiaires). Et nous avons ainsi tout nos clefs primaires qui sont uniques (pas uniquement au sein d'une même table)
L'inconvénient c'est que la gestion des clefs étrangeres ne se fait pas très bien, on devrait pouvoir faire une table adresse qui aurait un champ qui pointe vers individu (ou "homme",ou "femme"), mais ça gere strictement les clefs alors qu'en programmation objet, si un objet possede une instance d'individu, il peut de la même façon posseder une instance d'homme ou une instance de femme.
Axel
[^] # Re: table héritée
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
C'est ce qu'on appelle en objet le polymorphisme ;-)
[^] # Re: table héritée
Posté par nouguier . Évalué à 3.
L'exemple est peut etre plus parlant, noter le "FROM ONLY"
[^] # Re: table héritée
Posté par Axel R. (site web personnel) . Évalué à 1.
Note: Although inheritance is frequently useful, it has not been integrated with unique constraints or foreign keys, which limits its usefulness. See Section 5.8 for more detail.
et je confirme que c'est un truc super, et que ce serait aussi très bien si les clés étrangeres géraient ce truc :-)
Axel
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.