Pour rappel PostgreSQL est un SGBD libre (licence BSD) et facilement extensible qui supporte notamment les transactions, les triggers, les procédures stockées (que vous pouvez écrire en C, Python, PL/pgSQL, TCL ,Perl et Ruby).
C'est à mon goût le plus complet des SGBD libres. Au menu des nouveautés :
Les points de sauvegarde (savepoints) qui permettent d'annuler une partie spécifique d'une transaction sans affecter le reste de celle-ci.
Le système Point-In-Time de sauvegarde en continue des données du serveur.
Le support des tablespaces qui permet de choisir la partition (et donc le système de fichiers) pour le stockage des tables, index, schémas. Grâce à cette fonctionnalité il est possible d'optimiser les performances et la fiabilité du système.
La possibilité de changer le type d'une colonne avec ALTER TABLE.
Une nouvelle version de plPerl qui possède maintenant un espace de stockage persistant et partagé.
La commande COPY permet d'importer et d'exporter des fichiers CSV.
Une version native Win32, qui ne dépend plus des bibliothèques Cygwin.
Un installeur MSI pour MS Windows est également disponible.
Aller plus loin
- Annonce officielle (0 clic)
- What's new ? (0 clic)
- Site PostgreSQL en français (12 clics)
- Miroirs FTP (1 clic)
# Quelque liens complémentaires
Posté par Olivier Grisel (site web personnel) . Évalué à 10.
http://bt.postgresql.org/(...)
Ensuite il est possible d'administrer graphiquement sa base avec :
- pgadminIII : http://www.pgadmin.org/(...)
- mergeant : http://www.gnome-db.org/screenshots.php(...)
Mergeant et basé sur la bibliothèque gnomedb, basée elle-même sur la bibliothèque d'accès générique aux sources de données libgda (indépendante de GNOME). Il faut donc penser à installer le driver postgres pour gda (gda2-postgres sous debian).
On notera aussi la sortie récente en version 1.0 du projet de système de réplication asynchrone pour Postgres nommé Slony-I :
http://gborg.postgresql.org/project/slony1/projdisplay.php(...)
On notera enfin que l'auteur de Slony-I prévoit d'implémenter prochainement un système de réplication synchrone pour pgsql appelé Slony-II (vu sur /. - http://it.slashdot.org/comments.pl?sid=117456&cid=9930552(...) ).
En espérant que cette nouvelle version de PostgreSQL avec support natif de windows lui permettra de trouver une toujours plus large base d'utilisateurs.
[^] # Re: Quelque liens complémentaires
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Je pense que le vénérable pgaccess est toujours utilisable mais je suis heureux de voir que la concurrence est active. C'est absolument nécessaire pour offrir une alternative à MS Access.
J'espère aussi que la mise en œuvre de postgresql sera facilitée. Il n'est pas évident du tout à un débutant d'aller éditer /var/lib/pgsql/data/postgresql.conf pour y ajouter tcpip_socket = true et d'aller modifier /var/lib/pgsql/data/pg_hba.conf pour y permetter la connexion en mode local (par localhost).
Je suis convaincu que ces deux points ont été des obstacles insurmontables pour beaucoup de personnes et ont gravement porté préjudice au développement de posgresql. Il est indispensable de donner une configuration par défaut qui soit directement utilisable (comme Access).
La réplication de base est une très bonne chose. Il serait très intéressant de la faire vers MySQL pour faire de l'infocentre (base de données destinée à la consultation) car MySQL excelle en ce domaine tout comme Postgresql excelle dans la gestion des contraintes d'intégrité. Je n'ai pas vu dans la documentation si c'était possible.
J'ai utilisé Oracle pendant plus de 10 ans et je lui préfère nettement Postgresql. Les cas où Oracle est nécessaire sont vraiment marginaux. Oracle nécessite beaucoup plus de travail d'administration que Postgresql. C'est dû au fait que Oracle a été conçu pour gérer lui-même les accès disques alors que postgresql laisse le file system s'en débrouiller.
[^] # Re: Quelque liens complémentaires
Posté par Ramso . Évalué à 5.
> /var/lib/pgsql/data/postgresql.conf pour y ajouter tcpip_socket = true et d'aller
> modifier /var/lib/pgsql/data/pg_hba.conf pour y permetter la connexion en
> mode local (par localhost).
Wow, c'est plus du débutant là, c'est du glandu ! Tu crois vraiment qu'on peut mettre PostgreSQL entre les mains d'un type qui sait pas lire une doc ou un tutoriel pour configurer son SGBDR ? Imagine les conneries qu'il va faire s'il s'est pas formé un minimum...
> [...] obstacles insurmontable [...] gravement porté préjudice au développement
> de posgresql
Parce qu'ils ne savent pas changer la configuration par défaut ?! Finalement ça vaut peut-être mieux de ne pas leur avoir laissé une arme aussi puissante que PostgreSQL entre les mains. :-)
[^] # Re: Quelque liens complémentaires
Posté par passant·e . Évalué à -3.
ha le nom d'une base... heu je me rappel de dbfacturation.
alors, DROP dbfacuration...
ben oui je confirme! allez drop.
bon faut que je regarde la liste des dernières factures alors... comment ça, plus de données???
Voui boss je confirme, postgres c'est de la merde, je conseil access pour le service informatique.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Quelque liens complémentaires
Posté par Raoul Volfoni (site web personnel) . Évalué à 10.
Pierre, comparer PostgreSQL à Access c'est pas très gentil (je n'ai jamais autant pesé mes mots ;-)...
>J'espère aussi que la mise en oeuvre de postgresql sera facilitée. Il n'est pas évident du tout à un débutant d'aller éditer /var/lib/pgsql/data/postgresql.conf pour y ajouter tcpip_socket = true et d'aller modifier /var/lib/pgsql/data/pg_hba.conf pour y permetter la connexion en mode local (par localhost).
Tous les DBA préfèrent aller modifier un fichier de conf que de se retrouver devant une interface graphique propriétaire toujours limitée et + ou - foireuse (Cf Ms SQL Server). Maintenant si le commentaire s'adresse aux débutants non informaticiens, j'espère réellement qu'aucun d'entre eux n'aura jamais l'idée saugrenue d'installer PostregreSQL. C'est quand même pas un outil pour débutants :)
>Il est indispensable de donner une configuration par défaut qui soit directement utilisable (comme Access).
Argll non alors! Il y a déjà SQLite (et consors) pour ça.
>La réplication de base est une très bonne chose.
Elle y est depuis un bon moment, et de toutes façons rien ne vaut de bonnes procédures stockées pour se faire sa propre réplication aux petits oignons.
>Il serait très intéressant de la faire vers MySQL pour faire de l'infocentre
Pardon, mais je ne vois pas vraiment l'intérêt d'avoir un second moteur pour gagner quelques millisecondes sur les requêtes. Par contre PostgreSQL sera bien plus adapté lorsqu'il faudra mettre en place un Datawharehouse ou bien de l'analyse de données OLAP (Cf. le magnifique projet Mondrian : http://sourceforge.net/projects/mondrian/(...))
>Les cas où Oracle est nécessaire sont vraiment marginaux.
Tout à fait d'accord pour l'édition Standard destinée aux PME-PMI. Par contre quand il s'agit de gérer plusieurs Téra de données ou milliers d'utilisateur, je n'hésiterai qu'entre Oracle et DB2. OSDN a d'ailleurs choisi le dernier si je ne m'abuse.
>C'est dû au fait que Oracle a été conçu pour gérer lui-même les accès disques alors que postgresql laisse le file system s'en débrouiller.
Ayant débuté avec la V3 d'Oracle, je n'ai pas le souvenir d'y avoir vu le support des Raw devices à l'époque (mais je peux me tromper, ça ne date pas d'hier). Je crois que c'est arrivé bien plus tard. Et je continue de penser que c'est une excellente chose: lorsqu'on a bossé plusieurs jours/semaines sur la conception des Lun, on ne va quand même pas tout gacher avec un filestem! Concernant les Tablespace, reste à voir comment ils sont implémentés et ce qu'ils permettent de faire (Cf. partitionnement vertical et horizontal).
J'ajouterai que j'attendais la version 7.5 de PostgreSQL depuis un bout de temps justement pour les Tablespaces. Et puis là je vois arriver une V8 qui d'un point de vue des nouvelles fonctionnalités ne m'impressionne pas plus que celà. Par contre après avoir lu la liste des améliorations je m'aperçois que le paramètre tcpip_socket a été remplacé par un listen_addresses ce qui devrait te faire plaisir. ;-)
Plus sérieusement, la liste des améliorations sur les performances est impressionnante.
Je terminerai ce long message par une 'petite requête' à destination des DBA PostgreSQL: en dehors de pgAdmin, quel outil utilisez-vous pour l'analyse des requêtes (sortie du plan d'exécution)? J'ai lu que les stats et l'optimiseur ont subi quelques changements.
[^] # Re: Quelque liens complémentaires
Posté par Bertrand D . Évalué à 4.
Cependant, aujourd'hui les raw devices ne sont plus beaucoup utilisés étant donné qu'ils apportent beaucoup de contrainte pour peu de gain en performance (vu les performances des systèmes actuels).
Pour ce qui est des data warehouses, il me semble que les plus gros sont sur Teradata (SGBD de NCR). Wall Mart (qui a/avait le plus gros data warehouse au monde à la fin des années 90) utilisait Teradata, autant que je me souvienne.
[^] # Re: Quelque liens complémentaires
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
C'est vrai sur les SAN (EMC en fait de très bons), mais probablement pas sur les petits serveurs (sauf si cartes Raid 15 ou 20 avec moult Mo de RAM). Si j'arrive à installer Sybase 10 sur ma Gentoo, je ferais bien un petit test de perfs rien que pour voir.
> Wall Mart (qui a/avait le plus gros data warehouse au monde à la fin des années 90) utilisait Teradata, autant que je me souvienne.
Possible, mais à cette époque un VLDB ne dépassait pas quelques téras. Aujourd'hui les bases qui dépassent 50 téras se comptent par centaines. Il me parait évident dans un tel contexte que PostgreSQL n'a rien à faire dans cette catégorie.
[^] # Re: Quelque liens complémentaires
Posté par - - . Évalué à 5.
je suis pour la simplification et l'informatique nucléaire pour les petits enfants, mais ici on parle non pas d'un "sgbd" mais d'un Serveur de base de donnée SQL. c'est un outil complexe pour des besoins complexes pour des gens compliqués
les gens compliqués doivent prendre postgres et l'intégrer au sein d'un outil facile pour les gens qui se foutent de sql, serveur, ordi, tcp/ip etc
parce que vous vous dites que c'est dur de changer le fichier de config tcp = true ou lire la doc, mais non ! c'est le mot TCP et le principe de fichier de config, de réseau, de SQL , de base de donnée etc qui EST compliqué et que les gens ne veulent PAS SAVOIR.
personnellement, mon expérience m'a montré que postgresql est plus simple à mettre en place que Oracle. et Oracle a pas de problèmes pour se vendre. mais rappelons nous que Oracle vend pour les PROFESSIONNELS (qui bouffent du sql au lit) et n'a aucun complexe à être incompréhensible pour mon fleuriste. chacun son truc. moi je pige rien aux boutures.
rappelez vous que ce sont des outils pro pour des besoins pro. c'est un serveur SQL , ce n'est PAS access qui est conçu _spécifiquement_ pour des secrétaires, comptables etc d'entreprises et sans notion de client/serveur.
[^] # Re: Quelque liens complémentaires
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
J'ai vu pas mal de gens non informaticiens intégrer rapidement la notion de base de données et se faire des petites applications correspondant à leur besoins. Pour cela, il faut qu'ils trouvent dans leur machine un truc prêt à l'emploi. Malheureusement, j'ai toujours vu faire ça avec Access.
L'avantage de cette pratique, c'est que le besoin est bien mieux spécifié que par des spécifications qui ressemblent souvent à une lettre au Père Noël.
Dans un deuxième temps, l'application déborde du cadre personnel et celui qui l'a créée commence à se heurter aux problèmes se sécurité, de partage de ressources, sauvegardes, etc, bref, à tout ce qui constitue le travail des informaticiens. Il fait alors appel à eux pour déployer son application.
Étant donné qu'Access ne convient pas, il faut passer à une vraie base de données. Microsoft propose des outils de conversion sur SQL Server et Microsoft a gagné. Cette trajectoire depuis la maquette jusqu'à la base de données d'entreprise est stratégique et les logiciels libres ne proposent pas cette évolution. Ce qui manque, c'est de proposer un point d'entrée prêt à l'emploi sur le poste de travail, à la façon d'Access. Je pense qu'il est possible d'installer Postgresql avec une configuration par défaut qui en augmente considérablement l'audience. Les professionnels de l'informatique sauront conseiller les utilisateurs et auront plus de facilité pour déployer l'application.
[^] # Un compromis est possible
Posté par Jean-Max Reymond (site web personnel) . Évalué à 4.
Un compromis possible est de faire un lien ODBC entre l'interface Access et une base Postgres afin de réunir à la fois la souplesse de l'un et la puissance de l'autre. Je l'ai réalisé pour un client et ça marche finement. La 2e étape sera de permettre un accès Internet à ses données desormais sous Postgres. La 3e étape sera de virer Access mais ce n'est pas gagné :-(
On est bien dans l'idée d'intégrer petit à petit des briques Open Source dans l'entreprise et d'en augmenter le nombre au fur et à mesure.
[^] # Compromis, chose due
Posté par Gabriel . Évalué à 4.
On est aussi dans l'idée de donner accès à un outil nouveau pour l'utilisateur qui lui permettrait de déployer son boulot . Je trouve aussi qu'il manque un front-end intelligent aux bases de données (en général, et open source en particulier), pour gérer des formulaires.
Quelquechose qui ne soit pas pour les dba, ni pour les développeurs, mais de quoi faire des "applis jetables".
Pour beaucoup de gens au sein des entrprises, le boulot principal est de remplir des bases de données et de donner accès aux autres.
Pour beaucoup aussi il s'agit d'utiliser les données produites par les autres. Ainsi on pourrait leur donner le moyen de rendre ce boulot autonome, responsable et intéressant. Il n'y aurait plus beosin de faire appel à l'info pour faire des crud (create-read-update-delete)
Ce que Access a fait, on est pas loin de pouvoir le retrouver en mode web avec phpmyadmin/pgpmyadmin. Mais il manque les liens entre les entités et une certaine "malignité" du programme.
Dans mon ancienne boite, on avait fait un outil web agréable qui permettait de générer des formulaires (Magen pour ne pas le nommer). Mais il fallait un developpeur pour le déployer.
Le désavantage tout de même du mode web est qu'on a besoin d'un serveur. Donc, effectivement, c'est peut-être pas la panacée universelle (j'aime bien cette expression fautive!).
Le désavantage d'une appli non-web c'est (pardon si je choque..) que cela tournera sur le poste client qui est pas forcément du linux.
Mais en gros ce serait une sacrée killer feature - comme Linus parlait de VB comme d'une killer feature pour windows.
Une dépêche était parue il y a 6 mois parlant d'une appli de ce type , et qui était dans le cadre de kde en général - à l'époque c'était pas intégré à kde car c'était pas fini. ça vous dit qqchose?
[^] # Re: Compromis, chose due
Posté par Pinaraf . Évalué à 3.
Si tu veux l'essayer, n'hésite pas, mais c'est du 0.1beta4 => plein plein de features absentes !
N'hésite pas à y contribuer
[^] # Re: Un compromis est possible
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
On peut constater dans la pratique, que les logiciels fournissant les données à la base sont assez stables et sont assez peu souvent modifiés. Par contre, les logiciels d'exploitation doivent répondre à des demandes souvent variées. Ce qui était de la plus haute importance hier ne sera peut-être plus utilisé demain. Ils ont une vie beaucoup plus rapide. Il existe aussi des logiciels d'exploitation stratégiques comme ceux qui envoient les factures au client.
Alors je vois se dessiner les grandes lignes de la modularité des applications :
- La base de données
- La saisie
- L'exploitation critique
- L'exploitation libre
La saisie et l'exploitation peuvent être faites pas le web, un programme spécifique local ou distant, un programme générique comme pgaccess ou OpenOffice ou encore avec une console en sql. Cette modularité doit être expliquée et mise à profit.
Pour en revenir au fonctionnement de type access, elle n'est qu'un cas particulier.
[^] # Re: Quelque liens complémentaires
Posté par gc (site web personnel) . Évalué à 6.
Je suis convaincu que ces deux points ont été des obstacles insurmontables pour beaucoup de personnes et ont gravement porté préjudice au développement de posgresql. Il est indispensable de donner une configuration par défaut qui soit directement utilisable (comme Access).
Faut différencier la facilité de configuration, de l'utilité de la configuration par défaut.
L'éditeur du logiciel fournit une configuration par défaut qu'il pense convenir à ses utilisateurs. Le distributeur (Debian, Mandrakesoft, ChaperonRouge) se doit de changer cette configuration par défaut en fonction de ses choix et de son public.
La politique de Mandrakesoft par exemple est que tout logiciel installé, puisque désiré (puisque installé), est utile, il faut donc que le service soit activé par défaut. S'ensuit que le configuration par défaut doit représenter quelque chose d'utile lorsque pertinent, ou être absente (ou désactivée) lorsque non pertinent. Par exemple, pour un serveur DHCP une configuration par défaut est pertinente, pour un serveur DNS non. La configuration par défaut doit donc être adaptée et choisie avec soin.
Au contraire, à ma connaissance la politique de Debian et ChaperonRouge est de ne pas activer le service par défaut (pour mettre l'accent à fond sur la sécurité, et parce qu'une configuration par défaut est considérée peu utile), dans ce cas-là la distribution a plus de latitude pour conserver la configuration par défaut proposée par l'éditeur (mais souvent en la sécurisant ou la restreignant, on n'est jamais trop prudent).
Tout ça pour dire que pour le logiciel qui touche le neuneu, comme il arrive par le distributeur et non pas l'éditeur, sa configuration par défaut n'est plus de la responsabilité de l'éditeur.
Ensuite, si l'on veut parler de la facilité de configurer, il y a beaucoup d'outils graphiques qui facilitent la configuration de postgresql, et la documentation est abondante pour accéder aux fichiers de configuration, il ne me semble pas y avoir de problème au contraire.
[^] # Re: Quelque liens complémentaires
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
C'est à mon avis ce qui explique en parrtie le succès de Mandrake.
Cependant Postgresql n'était pas dans ce cas. J'ai même dû galérer pour le mettre en service. J'en parle au passé car dans cooker, la future version 10.1 c'est déjà beaucoup plus facile. Il ne manque que peu de choses pour que Postgresql soit vraiment facile à utiliser.
[^] # Re: Quelque liens complémentaires
Posté par Olivier Meunier (site web personnel) . Évalué à 1.
Y a pas un putain de manuel avec les étapes et des screenshots pour expliquer ça ?
PS: désolé d'être grossier, mais ça m'ennerve assez vite.
# C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à -7.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Zorglub . Évalué à 4.
Quels sont les avantages de Firebird par rapport a PostgreSQL (8) ?
Zorglub
[^] # Re: C'est pas pour troller mais...
Posté par PloufPlouf (site web personnel) . Évalué à 1.
je suis d'accord avec toi avec quelques arguments ca passe mieux, d'ailleurs ca serait bien que ceux qui ont envoyé ce pauvez Stephane à -10 nous donne les leurs....
un exemple qui me vient là, dans le thread suivant on demande comment changer le type d'une colonne avec postgre, avec firebird c'est possible avec un alter column, firebird s'occupe du transtypage des données s'il est possible
en vous remerciant
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Je n'ai pas mis d'arguments car je voulais pas lancer de débat, je voulais juste que les gens qui connaissent pas aille voir ce produit et se rende compte que Firebird est une merveilleuse alternative.
Je voulais pas de débat, juste attiser la curiosité, j'en ai payé le prix :)
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par PloufPlouf (site web personnel) . Évalué à 0.
en xp, c'et pas cher, yen a qui sont mort par ce qu'il etait ou pensait pas comme les autres....
[^] # Re: C'est pas pour troller mais...
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Avoues que tu ne l'a pas volé. ;-) Firebird n'est que le descendant d'Interbase, un produit proprio sur le déclin dont Borland a pensé qu'en le donnant à la communauté OSS celà lui donnerait une seconde jeunesse. Mais regardes ce qui est arrivé à SAP...
[^] # Re: C'est pas pour troller mais...
Posté par PloufPlouf (site web personnel) . Évalué à 3.
interbase, n'est pas sur le declin, sa version 7.5 est sorti recemment
et surtout, en quoi ca ferait de Firebird un produit de seconde zone ?
je n'inutile pas ton commentaire, pour que le debat est lieu, j'attend que tu m'explique....
on est en pleine subjectivité et obscurentisme, ca n'as plus rien a voir avec l'informatique, firebird est mal aimé, voir les scores a chaque fois qu'on en parle, et je pense pas ceux qui qui score negativement aient testé firebird, sinon ils diraient pourquoi ils pensent que c'est pas un bon logicel... je veux dire peut etre que j'ai tort d'utiliser ce sgbd mais expliquez moi pourquoi ! me laissez pas dans l'ignorance, c'est pas sympa de pas partager son savoir...
je vous en remercie d'avance
[^] # Re: C'est pas pour troller mais...
Posté par Yusei (Mastodon) . Évalué à 7.
Ça n'a rien à voir et tu le sais. Ceux qui "moinssent" ne le font pas parce qu'ils n'aiment pas firefird, simplement parce que le message à l'origine de ce fil était absolument creux et sans intérêt. Partir dans un délire florentpagnesque (ma libertééé de penseeer) ne mène à rien.
D'autres personnes ont par la suite complété ce message par des arguments, et la "censure" que tu dénonces n'a pas frappé.
[^] # Re: C'est pas pour troller mais...
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Je pensais que c'était la 7.1 mais je te crois sur parole. En parlant de déclin je ne faisais que me référer aux paroles de Paul Reeves dans le document intitulé "How InterBase became Open Source". Il faut d'autre part bien se souvenir qu'à cette période là tout le monde pensait que le produit allait tout simplement disparaitre comme bon nombre de produits chez Borland/Inprise qui était en pleine crise.
>et surtout, en quoi ca ferait de Firebird un produit de seconde zone ?
Je n'ai pas dis celà...même si je le pense :) Cf. plus loin.
>je n'inutile pas ton commentaire, pour que le debat est lieu, j'attend que tu m'explique....
Sage réaction, voici donc mes explications:
Firebird manque de pas mal de fonctionnalités natives (Tablespace, réplication, full text indexing, ...). On peut évidemment penser que le produit va évoluer maintenant qu'il est OSS, mais PostgreSQL fait déjà tout celà.
Firebird est trop lié à Interbase et reste avant tout un projet commercial destiné à rester 100% compatible avec un produit propriétaire. Pour ma pomme c'est rédibitoire. :(
Manque de documentation, celle de Borland étant payante.
Firebird ne tient pas vraiment la charge (http://www.postgresqlfr.org/usecases/elma.php(...)) et est bourré de bugs.
Tout celà suffit à me faire une mauvaise opinion du produit et de son environnement. Peut-être ais-je tort, mais dans la mesure où PostegreSQL est pleinement satisfaisant, pourquoi irais-je voir ailleurs, d'autant que contrairement à ce que j'ai lu à plusieurs reprises dans les messages ici, changer de SGBDR n'est jamais anodin et ne se fait pas non plus sur un coup de tête. On ne devient pas DBA du jour au lendemain...
Il faut savoir que j'ai bossé avec plusieurs versions de RDB (3->5), Oracle (3->9i), Sybase (10->11), Ms SQLServer(6.5->2000) , mySQL(3) et maintenant PostgreSQL (depuis la 7.1). Je me vois mal passer à Firebird voilà tout....
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Changer de SGBDR n'est jamais anodin mais dans une application qui respecte certaines règles, c'est relativement simple.
Je ne parle pas de bases énormes, je parle d'applications classiques avec 50 utilisateurs constants, 2 Go de base... pas un truc énorme.
Quand aux performances, j'ai fait tourné les tests unitaires tout une semaine en simulant des appels à toutes les fonctions métiers avec 50 clients en continu... beh ca a pas planté et les temps ne se sont pas écroulés.
Par contre, l'établissement de connexion est très lent, donc prévoir un pool de connexion dans les applis.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Il suffit de mettre le nom de la machine au début de /etc/hosts pour améliorer considérablement cette caractéristique.
[^] # Re: C'est pas pour troller mais...
Posté par C2RIK . Évalué à 0.
Il a la même sympathique backdoor que Interbase ? ;)
[^] # Re: C'est pas pour troller mais...
Posté par Nÿco (site web personnel) . Évalué à 2.
C'est la libération du code en OpenSource d'ailleurs qui a permit de l'identifier et de la boucher/corriger.
Aucun moyen de savoir en revanche si elle a été conservée/modifiée sur la BDD proprio Interbase.
[^] # Re: C'est pas pour troller mais...
Posté par Ayrton . Évalué à 3.
Bon ... ben ... comme avec PostgreSQL V8...
[^] # Re: C'est pas pour troller mais...
Posté par Yusei (Mastodon) . Évalué à 5.
Un vote ne veut pas dire "je suis d'accord" ou "je ne suis pas d'accord", un vote est censé indiquer que l'on estime un commentaire utile ou inutile. Cette précision faite, il semble donc tout à fait logique qu'un post sans argument soit noté négativement.
Imagine un post disant uniquement "firebird roxor", tu trouves ça utile ? Et bien niveau contenu, c'est aussi informatif :-)
Ça ne veut pas dire que la horde linuxfrienne préfère postgresql, ou même qu'ils n'ont pas envie d'être convaincus...
[^] # Re: C'est pas pour troller mais...
Posté par Olivier Jeannet . Évalué à 5.
Avec des détails (mise en oeuvre, performance, fiabilité, possibilités, facilité) et des arguments, ce genre d'affirmation serait nettement plus intéressant (et augmenterait la crédibilité du titre :-).
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Plus simple à installer, bons outils de devs dispo, leger et facile à aborder !
et il y a aussi la disponibilité pour s'en servir en embedded, je sais pas si postgreSQL permet ça ?
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par C2RIK . Évalué à 1.
Pour gagner du temps le site de Firebird est : http://firebird.sourceforge.net/(...)
y'a même un port FreeBSD !!!!
HS
Je profite du thread pour poser une question :
Quelqu'un connait un SGBD post-relationnel (orienté objet) intéressant ?
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par C2RIK . Évalué à 1.
Cite m'en un multi-langage par exemple. Y'a pas que java dans la vie !
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Christophe Renard . Évalué à 2.
Sinon ZopeDB est un exemple (mapping Python et Perl uniquement je pense).
voir la sinon http://www.odmg.org/(...)
# La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Gentoo][Gravis . Évalué à 0.
ce n'est pas possible aujourd'hui ??? Il est donc impossible de modifier une table sans faire un dump, la "dropper", puis la réimporter ? Comment fait-on en prod ?
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par itstimetogo . Évalué à 9.
création de la nouvelle colonne.
copy de ancienne colonne dans la nouvelle.
suppression de l'ancienne colonne.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par itstimetogo . Évalué à 4.
renommage de la nouvelle colonne.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Gentoo][Gravis . Évalué à -3.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par B. franck . Évalué à 4.
en production: on ne modifie pas la structure de donnée
normalement on a bien pensé sa structure avant de mettre en production et on ne revient pas dessus...
ou alors, c'est plutôt grave. (imho bien sûr )
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Yusei (Mastodon) . Évalué à 4.
Mais ce qui est important là dedans, c'est qu'un changement dans la structure des données n'est pas anodin, et donc peu importe qu'il soit simple à faire ou non, de toutes façons il est prudent (lire: indispensable) de faire une sauvegarde complète du système, et dans l'idéal il faudrait refaire l'étape d'analyse qui a mené du modèle conceptuel au modèle physique.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Gabriel . Évalué à 2.
ici où je travaille, où ils gèrent tout sur AS400 et consomment des données à tire-larigot (orthographe perso), ils compilent des programmes rpg qui pointent vers ces bases. Du coup, quand ils veulent changer le schéma de la base, ils sont obligés de recompiler tous les programmes qui utilisent ces fichiers.
Donc si tu veux changer la base produit il faut recompiler... 200? 300 programmes?
En général ça veut dire : " on ne touche pas aux fichiers" (ie base de données).
Et pour se donner un tout petit peu de marge,ils rajoutent des "filer" dans chaque table. Des champs vides mais qui garantissent une certaine évolutivité.
Avec mes habitudes de bases micro, que tu changes facilement, j'ai l'air d'une poule devant un couteau devant ces façons de faire.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Houlà, grave problème d'architecture. Quand on a plusieurs centaines d'applis qui attaquent une base, elles ne doivent jamais le faire en direct. Le schéma physique étant commun à toutes ces applis, il doit impérativement leur rester totalement inconnu. Dans ce contexte, chaque appli devrait disposer d'un schéma à base de vues et de procédures stockées qui représentent le 'contrat' entre l'appli et les DBA. Ainsi lorsque le modèle physique est modifié (en théorie c'est mal, mais en pratique ça arrive) on adapte les vues et les procédures de façon à conserver une interface identique pour l'appli.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Gabriel . Évalué à 2.
Mais je peux rallonger la liste des soucis: les vues logiques aussi sont définies dans des sources à recompiler si tu recompiles une table. Je suis pas sûr mais il me semble que les procédures stockées aussi? Je vais leur demander.
Ici j'apprend autant ce qui est bien que de ce qui est foireux.
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Ayrton . Évalué à 2.
C'est pour celà qu'il y a les views. Avec un "vrai" SGDB, tu n'attaques pas les tables qui stockent les données mais les views (ce qui permet aussi d'affiner les permissions). Après l'organisation ou le type des données peut changer sans que ça dérange les applis (si les views sont correctement mise à jours évidemment).
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
[snip]
Heu c'est exactement ce que j'ai écris non? ;-)
Pour une fois qu'il y a au moins 2 personnes en accord dans ce thread... :)
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Stéphane V. . Évalué à 2.
Ce que vous dites là est de la pure théorie... Il peut très bien y avoir un besoin qui évolue lorsque l'application est en production. Pour les grosses applications qui vivent depuis 20 ans par exemple, expliquez moi comment vous faites si vous voulez limiter les coûts ?
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par B. franck . Évalué à 1.
mon expérience me pousserait à procéder par héritage (dans le sens "objet"): une nouvelle table héritant de la première.
mais en tout cas, je n'irais (conditionnel) jamais changer la longueur ou le type d'un champ.
(de toute façon, rendre simple cette action critique, rend paresseux le concepteur du modèle de donnée et conduit immanquablement à l'usine à pets nékrosée)
# Et mysql
Posté par Pinaraf . Évalué à 2.
Mais alors, pourquoi mysql est-il plus utilisé que PostgreSQL ?
[^] # Re: Et mysql
Posté par Olivier Grisel (site web personnel) . Évalué à 10.
http://googlefight.com/cgi-bin/compare.pl?q1=mysql&q2=postgresq(...)
Y a aussi le mythe de la différence de rapidité qui est AMA un critère négligeable pour la majorité des utilisateurs.
[^] # Re: Et mysql
Posté par nextgens (site web personnel) . Évalué à 2.
Mais alors, pourquoi Vindobe est-il plus utilisé que GNU/Linux?
t'en as d'autre des comme ca? ;-)
ok ------------------>[]
[^] # Re: Et mysql
Posté par Pinaraf . Évalué à 2.
Il y a des raisons :
- l'installation par défaut sur les PCs vendus en magasins
- le marketing de m$ autour de win < 95 pour dire que c'est un standard (=> logiciels pour win uniquement)
- linux n'existait pas pour le end-user en 1995
[^] # Re: Et mysql
Posté par Black Fox . Évalué à 10.
Pour faire une liste de news, pas vraiment besoin de procédures stoqués, de contraintes ou autres :p
MySQL, même pas en InnoDB, suffis amplement et l'hébergeur as plus le controle (Pas de risque de procédures stoqués qui rament par exemple si elles n'existent pas, donc moins d'administration à faire)
Pour résumer : Pas besoin de sortir un buldozer pour détérer sur 3cm de haut...
[^] # Re: Et mysql
Posté par Kalex . Évalué à 1.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 5.
et je pense d'ailleurs que la base de données ne devrait servir qu'à stocker des données ;)
En fait, je pense qu'on devrait pouvoir changer des base de données comme de chemise...
Quand je développe une appli, autant la développer avec hsqldb par exemple et au moment du déploiement, en fonction des besoins, l'utilisateur choisit une base de données.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 7.
C'est une erreur. Les bases de données doivent ne gérer que les données. Ce qui est un peu plus que d'uniquement les stocker. Assurer l'intégrité des données (intégrité référencielle, backup à chaud, etc) c'est un travaille aussi important que de "seulement" stocker les données.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
L'intégrité peut etre gérer dans les objets... et les backups, sauvegardes... c'est bien entendu une fonctionnalité des bases de données.
Je ne dis pas que les bases de données ne servent à rien, je dis juste qu'on devrait pouvoir en changer comme de chemise :)
Après tout, le SQL étant "standard" et les logiciels étant pour beaucoup orienté objet... pkoi s'inquieter de la base de données choisie ?
on peut meme faire des clusters de bases de données différentes et de manière transparente avec des produits comme C-JDBC alors pourquoi se focaliser tant dessus ?
http://about.me/straumat
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 6.
Dans les annees 90 on(enfin certains) a cru que les BDD Objets allaient supplanter les SGBDR.
Finalement, si on programme tout en objet alors qu'le besoin de ces notions ringardes de tables/jointures et autres concepts desuets.
L'inconvenient c'est que beaucoup de problemes ne se pretent pas a cette approche. Quand tu veux manipuler des grosses masses de donnees, des cubes de donnees ou calculer des rapports statistiques enormes, ca n'est tout betement pas tres efficace de traiter individuellement chaque entree comme un objet, creer un instance, faire trois operations dessus et le detruire. Qui plus est les languages non objet n'ont pas disparu et restent bien vivaces.
En fait les gros consommateur de BDD ce sont des programmes de gestion dans les entreprises, les ERP en particulier. Et franchement, un backend Relationnel garantissant une bonne integrite leur est bien plus utile qu'une jolie BDD Objet.
A cela on peut ajouter que la plupart des gros projets utilisent plusieurs languages/environnements et que les stockages d'objets en bases sont souvent specifiques a un language.
Quand a changer de BDD comme de chemise, j'aimerai bien. Mais finalement le probleme c'est que 1) la plupart des BDD commerciales ont introduit des extensions proprio (gestion des arbres sous Oracle par exemple) 2) certaines BDD n'implementent que tres partiellement(ou exotiquement) le SQL (MySQL au hasard), 3) quand on veut tirer le maximum de ses requetes on peut etre amene a l'ecrire en vue du moteur sous-jacent et obtenir des resultats tres differents entre deux bases 4) certains besoins pourtant courants n'ont pas d'implementation standard (recherche FullText, donnees GIS ) 5) des qu'on utilise des "stored procedures" on a des chances de se lier profondement à une base spécifique.
Bref, y'a des systeme d'abstraction ODBC, JDBC, DBI ..... mais si on veut tirer les derniers bouts de performance ou profiter de fonctionnalites avancees on est souvent oblige de specialiser le code pour une base particuliere.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
je te parle de ce qui se passe aujroud'hui et je ne parle pas des bases de données objets..
Je parle des outils de mapping Objet/relationnel tel que les EJB CMP, JDO ou hibernate et ce n'est pas du domaine du reve, c'est utilisé tous les jours et de plus en plus.
Et ca gère les jointures sauf qu'on a un concept plus "parlant", les Collections... un client a une Collection de Factures par exemples et un client.getFactures() équivaut à une jointure.
C'est ce qui se passe aujourd'hui et meme microsoft pépare son objectspace je crois ? non ?
en tout cas, dans notre société, nous utilisons l'abtrasction JDBC et on a pas de code spécifique aux bases de données, on développe avec HSQBD et on change de bd au besoin.
http://about.me/straumat
[^] # Re: Et mysql
Posté par LeMagicien Garcimore . Évalué à 2.
L'inconvenient c'est que beaucoup de problemes ne se pretent pas a cette approche. Quand tu veux manipuler des grosses masses de donnees, des cubes de donnees ou calculer des rapports statistiques enormes, ca n'est tout betement pas tres efficace de traiter individuellement chaque entree comme un objet, creer un instance, faire trois operations dessus et le detruire.
Avec du JDO, bonjour les perf sur des operations de ce styles. Suivant l'utilisation, les solutions ne sont pas les mêmes. Chacune a un interêt.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
et pour avoir regarder un peu comment bossait hibernate et le cache hibernate, je peux te dire que ca doit pas etre beaucoup plus lent que sql pur et le gain de temps de dev est appréciable
http://about.me/straumat
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 2.
Je pense que si tu utilises une techno de serialisation le pbm est que tu vas quasiment a chaque fois de le relire depuis le meme language/meme bibliotheque, ca peut etre un facteur limitant .... ou pas.
Par contre niveau performance, imaginons un rapport calcule sur 10 millions d'entrees (courant par exemple pour calculer des facturations sur des communications entre operateurs telecom). Si tu est dans un modele objet/BDD tu vas parcourir tous les records, creer des millions d'objets, puis les mettre dans un container (bonjour la RAM), puis les parcourir pour faire ton calcul, puis les desallouer. Je veux bien croire que les environnements modernes fournissent du cache tres efficace, mais plus efficace que de faire un seul parcour des seuls champs concerne dans l'espace memoire de la base qui les as deja de charge ? Je demande a voir !
Parmis les autre exemples: si tu dois faire du datamining, avec la necessite de manipuler un gros tas de donnees a N dimensions pour y rechercher des motifs (on peut imaginer la recherche de comportement de consommateurs dans une base des achats d'une chaine de supermarches), ca s'avere aussi tres peut pratique.
Quand au gain de temps de dev, et bien la aussi c'est surtout relatif au type d'experience des developpeurs. Dans une equipe "tout Java", le gain de temps de dev sera considerable, par contre dans une equipe heterogene (ouis ca a aussi des avantages), ca n'est pas dit.
Bien entendu il y'a des espaces d'application ou le modele objet va s'averer tres efficace, mais vouloir l'appliquer partout ...... que dis le dictons deja ?
"Quand on a un marteau tout ressemble a un clou"
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 2.
Mais ca ne supprime pas les temps de creation/destruction meme si la JVM gere son propre pool et que celui-ci est cache proprement ca fait un paquet d'operations tout de meme.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Mais je suis d'accord avec toi sur beaucoup de points.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 2.
Je precise quand meme, pour moi la serialisation est le process qui consiste a conditionner les infos d'un objet pour les stocker sur disque, les envoyer sur un reseau ou a un serveur de base de donnees.
Je ne suis pas sur que ma definition soit totalement orthodoxe mais c'est ce que je voulais dire (et qui definitivement a lieu avec les technos que tu evoques et dont le cout, meme optimise n'est pas nul (surtout la de-serialisation je pense)).
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://java.sun.com/j2se/1.3/docs/api/java/io/Serializable.html(...)
D'ailleurs les objets hibernate sont des classes simples qui n'implémente pas l'interface serialization..
http://about.me/straumat
[^] # Re: Et mysql
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Par contre niveau performance, imaginons un rapport calcule sur 10 millions d'entrees (courant par exemple pour calculer des facturations sur des communications entre operateurs telecom).
J'ai bossé sur une appli de refacturation Interco. Impossible de t'envoyer un mail sur dlfp. Peux-tu me joindre stp?
Thxs.
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 1.
Je voulais juste faire remarquer que ton post semble supposer que le modele "je cree des objets, j'utilise une couche de stockage generique et j'ecrie dans n'importe quelle base" est universel et que je suis en desacord.
En fait ce type d'utilisation s'accorde bien du passage d'une base a l'autre parcequ'il n'utilise que tres peut les capacites de la BDD et deporte plutot les traitements sur le second tiers.
Ca a evidemment pas mal d'avantages, mais il est parfois (a mon avis souvent ... mais bon je n'ai pas un amour immodere pour les J2EE et consorts, cela m'aveugle sans doute), avantageux de tirer parti de ce qu'un SGBDR sait bien faire et d'avoir des traitements plus centraux, sur le premier tiers.
En tout cas mon opinion est que c'est une question a se poser avant de commencer un projet, et c'est donc du temps de reflexion depense en analyse pour eviter de passer du temps avec un profiler a essayer de determiner d'ou tirer des perfs ameliorees 2 jours avant de livrer .... moi je prefere.
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 3.
Parceque si on pousse ton raisonnement d'un iota (mais alors un tout petit), le stockage dans un SGBDR n'est pas du tout efficace puisque tu ne tires pas du tout partie des fonctionnalites de celui-ci.
Un stockage purement objet ou meme natif serai sans doute plus efficient.
Ca marche d'ailleurs plutot bien meme si c'est moins courant.
Mais je persiste : ca n'est pas une reponse generale a tous les problemes (qui comme tout le monde le sait est : 42)
Il fautt aussi admettre que si tu rencontres une certaine ardeur dans les reponses a tes posts (les miennes et quelques autres) sur ce sujet, c'est sans doute aussi parceque ton discours semble refleter une mode (surtout dans le monde des SSII) qui consiste a poser Java (et surtout J2EE) comme modele ideal de solution universelle.
Comme cette position est soutenue par un discours marketing assez lourd, ca peut etre enervant pour les gens qui pensent que le monde de l'informatique n'a aucune raison de se limiter au dipole Java/.Net.
Comme disais l'autre "nothing personal" ;-)
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Vu qu'on travaille en objet, on ne voit pas la base, autant que ce soit la meilleur mais j'ai pas envie de la voir.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Volnai . Évalué à 3.
C'est vrai ca, et puis on sait tous gerer des contraintes d'integrité dans un sgdbr, alors pourquoi utiliser une couche d'abstratction supplementaire pour le faire (qui boffe de la ram et qui est lente en plus) ? Et puis tout le monde sait programmer en perl, pourquoi on aurait besoin de java ? E on sait tous utiliser windows, alors pourquoi on utiliserait linux.
C'etait vraiment mal présenté comme phrase :)
Bon et je donne mon avis : si le but est seulement de stocker des données de la maniére la plus rapide possible, et de dedier la gestion d'intégrité a une autre couche, il y a surement beaucoup, voire infiniment plus rapide et econome que de faire des ejb et du sgbdr...
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
- des objets au nivo applicatif
- des requetes sql pour faire communiquer ces objets avec le sgbdr.
je préfère juste :
- faire des objets au nivo applicatif
et le support de sauvegarde des données, je m'en fous mais comme les SGBDR sont les plus rapides et les plus utilisés... je préfère m'en servir non ?
http://about.me/straumat
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 4.
Pourquoi est-ce important ? Parceque si le SGBD connais à l'avance les usages il peut etre optimisé pour les supporter.
Par ailleurs une chose tres importante dans une base de donnee ce sont les outils pour la gerer. Or si ces outils supportent nativement les concepts objets, les developpeurs et les DBAs voient les memes entites et peuvent un minimum echanger.
Quand l'appli et la base veillissent, les tables se multiplient, les patchs se supperposent ce genre de petits details peuvent faire la difference entre une appli in-maintenable et une appli qui survit.
Donc, pourquoi utiliser un logiciel specifique quand un generique peut faire l'affaire : c'est la difference de choix entre le sur mesure et le pret à porter.
Ce qui est certain c'est que les SGBR ont un poid, que ce qui fait la reputation de vitesse de MySQL est au prix d'une simplification tres large.
En fait en terme de performance il y'a des chances pour que des formes de stockage plus simples(dbm par exemple) explosent les SGBDR.
Au final le choix est en general fait parceque la base du projet est celle : 1) que les dev aiment/connaissent, 2) que le client a choisi sur les merites lus dans le Monde Info, 3) pour laquelle le client a deja plein d'experience/competences, 4) pour laquelle la SSII touche la plus jolie commission en vendant des licences, 5) celle supporté par la techno absolument nécessaire au projet, 6) ou celle dont le client à deja achete des licences, et rarement sur des criteres de parfaite correspondance technique au probleme sur les bras.
Donc on va rarement avoir un SGBDO, meme pour faire de l'objet parceque il est rare que ceux-ci remplissent un ou plusieurs de ces criteres, ca ne veut pas dire qu'il ne seraient pas plus indique.
NOTA: je crois bien que Postgresql a commence sa vie en SGBD mixte Objet/Relationnel et que le cote objet est tombe plus ou moins en desuetude faute d'une base d'utilisateurs suffisante.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Une classe hibernate toute bete est gérée dans ton appli et hibernate se charge de la mettre dans la base.
et comme les sgbd sont de supers produits, je ne vois pas un seul avantage à utiliser un SGBDO.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
PS: Je sais GNUstep est une vieille techno qui plait pas à tout le monde mais moi, je trouve ça sympa. C'est tout
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 2.
Tu n'es heureusement pas oblige d'utiliser un SGBDO.
Neanmoins, le plus rapide est sans doute de passer par un stockage specialise style SGBDO ou systeme de stockage dedie a Java, parceque ca a de bonnes chances d'etre plus rapide et d'enlever pas mal de couches (quel interet de generer du SQL, de l'interpreter et de gerer tout ces bidules relationnels, si ton gestionnaire de donnees passe directement par la reflexion pour savoir quoi stocker, gere les transactions au niveau de Java et te laisse les mains libres).
Mais en fait ton utilisation d'un SGBDR est tout a fait minimaliste, s'en passerai sans doute aisement. Le SGBDR dans l'usage que tu decris est a peine plus qu'un filesystem en reseau (ok je grossi le trait). Du coup il est normal que les fonctionnalites "avancees" des SGBDR te semblent gadgets puisque tu fais plutot les choses cote 2eme tiers (sauf des stored procedure..... n'est-ce pas mal de descendre la logique metier dans la base ? :-p ).
Ca n'est vraiment pas l'usage le plus efficace que l'on puisse faire de ces outils extraordinaires que sont les SGBD modernes.
Bref, je radote, mais ce que tu as leve c'est une vieille hache de guerre entre les tenants du SGBDR comme element d'infrastructure a peine plus intelligent qu'un filesystem et les amateurs d'intelligence dans la BDD (et pas forcement en stored procedures, mais par exemple en contraintes, valeurs pas defaut, types evolues, ...).
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
En fait, quand je vois les traces SQL de hibernate, il fait du SQL sans faire de reflextion... il traduit juste à partir d'un fichier de config.
Je ne pense pas qu'il existe des choses plus rapides qu'un SGBD :) mais jepeux me tromper
Vraiment il faut regarder les traces hibernate pour s'en rendre compte.
mon code est en effet dans le deuxième tiers... j'aime les applications multi tiers ;)
Les procédures stockées n'ont pas la logique métier en fait, c'est plutot tout ce qui est traitement de nuit, transfert... tout ce qui ne fait pas parti de la vie au jour le jour de l'appli et qui peut donc être "facile à migrer"
Ca n'est vraiment pas l'usage le plus efficace que l'on puisse faire de ces outils extraordinaires que sont les SGBD modernes.
Tout à dait d'accord, c'est juste une diffférence de points de vue, je trouve que les outils les plus extraordinaires sont les serveurs d'applications et je préfère me baser sur eux plutot que sur la bd.
Ce que je voudrais rajouter pour finir c'est que je ne pense pas que les bds sont des elements d'infrastructure betes... c'est juste que je préfère quand ils sont interchangeable...
perso, j'ai toujours été impréssionné par les bases de données et ce sont des outils merveilleux et fondamentaux :)
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 1.
Images ça :
Une base de données accédée en écriture/lecture par un site web, MS-access, SQLform, et une applie spécifique en C. Si tu ajoutes un outil général de consultation de base de donnée pour l'utilisateur il faut moins d'une semaine pour que la base de donnée soit dans un état "anormal" et au bout d'un mois tout doit être refait.
Si c'est la base de donnée qui gère l'intégrité des données, tu n'as pas ce problème. Si c'est l'appli, alors il faut une seul appli sinon c'est rapidement le bordel. On arrive à ton paradoxe :
- les bases de données doivent être interchangable (c'est un problème de standard et pas de postgresql qui respecte les standards (plus que mysql)).
- en reportant l'intégrité des données dans l'applis, tu limites le nombre d'appli utilisatable pour les mêmes données.
Bizarre ton raisonnement.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
l'intégrité des données dont je parle ne réside pas dans les clients mais dans la logique métier qui doit etre centralisée.
imagine maintenant une appli normale avec des ejb cmp pour gérer la persistance, des ejb de facade pour contenir la logique métier. (logique métier testé via tests unitaires)
toutes les applis qui seront développés font appel à la logique métier des ejbs.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 3.
ejb est dans ce cas fait aussi "gestionnaire de donnée"...
On en revient toujours au même. Bien séparer l'applicatif et des données (stockage, vérification, etc...).
Notes que tu fais presque du hors-sujet. Là tu parles des abstractions base de donnée. Ces abstractions peuvent s'occuper de l'affichage par exemple ce qui n'est pas le rôle d'un SGBD.
Tu parles aussi spécifiquement de java. ejb ne marche pas pour un site web développé en php ou avec Visual basic. Si tu as intégre toute la partie gestion de données (stockage, vérification, etc) dans la base de donnée, tu es indépendant du language et peut utiliser java ou php etc...
En même temps, rien ne t'empêche d'utilise java pour les procédures embarquées dans la base de données...
Donc idéalement, il faut laisser au SGBD le rôle de gérer (et pas seulement stocker) les données. Ou tu considères que SQL n'est pas un standard d'accès aux données et que tu considère que ejb est le standard des systèmes d'accès aux SGBD. Mais il n'y a pas que Java.
PS : connais pas vraiment ejb.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Les ejbs font parti de l'applicatif. A aucun moment, tu n'as pas de code qui se connecte à une bd ou tu n'as de requetes sql d'update, insert ou delete....
Je ne suis pas hors sujet car le sujet dont on parlait au début etait que, pour moi, on devait pouvoir changer de base comment ou voulait d'où l'utilité de l'abstraction et du mapping O/R.
Quand au multi plateforme, les ejbs facade sont automatiquement exportable en webservices donc tu as ton multi platforme de cette façon et c'est normalisé.
Donc idéalement, il faut laisser au SGBD le rôle de gérer (et pas seulement stocker) les données. Ou tu considères que SQL n'est pas un standard d'accès aux données et que tu considère que ejb est le standard des systèmes d'accès aux SGBD. Mais il n'y a pas que Java.
Ce n'est pas ça que je dis,
je dis que le SGBD doit gérer les données et qu'il doit y avoir entre le SGBDR et tes objets une couche qui te masque la persistence.
je ne parle pas spécifiquemnt de java, les outils de mapping O/R existent dans tous les langages, mon idée était qu'il fallait mieux utiliser une couche de mapping O/R pour arriver à devenir indépendant de la base de données.
Quand on développe un site en PHP, on est indépendant du serveur web non ? beh pour moi, quand on développe en objet, on doit etre indépendant de la bd.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 3.
C'est là que tu ne comprends pas...
SQL est indépendant de la bd. La base de donnée peut-être en mémoire vive ou n'importe où ailleur, ça ne change rien.
Tout ce que tu proposes, c'est de remplacer un standard par un autre. C-à-d remplacer SQL par ejb. Or l'objectif de SQL n'est pas celui de ejb (tel que le je comprend) et les deux peuvent cohabiter.
Par exemple SQL vérifie les données (ce que ne doit pas faire normalement l'applicatif ou ejb) et ton objet ejb indique que les ventes du mois ont été minables par rapport aux objectifs fixés par le patron (ce que ne fait pas SQL).
Déplacer ce qui doit être fait par le SGBD dans ejb (ou ailleur) car le SGBD est "insuffisant" n'est pas LA solution. C'est un workaround.
Si ton objectif est de dire qu'SQL n'est pas suffisament implémenté (ce qui est un problème pour l'intéropérabilité des bases de donnée (nb : je ne fais pas de hors-sujet)), et que ejb peut -être une solution pour contourner ce problème, alors je suis d'accord. Mais faut pas tout mélanger.
Ton "mapping", abstraction de donnée, etc... (avec ejb) est hors sujet. Cette problématique se pose pour les fichiers txt (gestion de named), exploitation du bus pci, etc...
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Mais quand tu fais un site web avec des utilisateurs, tu vas permettre, par exemple, d'administrater les utilisateurs.
Alors tu vas écrire un objet Utilisateur avec ton insert, ton delete et ton update sql... beh je trouve ça répétitif et intutile.
Quand je crée un utilisateur, je fais :
Utilisateur u = new Utilisateur();
u.setNom("TRAUMAT");
u.setPrenom("Stéphane");
et c'est tout, je vais pas me connecter à une base, je vais pas faire les requetes de select, update, insert et delete pour gérer les utilisateurs... j'ai envie que quelqu'un d'autre s'en charge ! et que les données soient stockées dans un SGBD !
Je ne propose pas de standard, je dis juste qu'il est mieux d'utiliser des objets et de laisser quelque chose style hibernate se charger des stocker les données dans la base ( faire les requêtes )
Mon but etait juste de dire que Les SGBD sont les meilleurs endroits pour stocker les données mais que le développeur ne devrait plus avoir a se taper toutes les requetes sql bidons update, insert et delete par exemple pour gérer les données.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 3.
On est d'accord, mais tu fais du hors-sujet. Ce que tu dis est valable pour tous les développements et n'est absolument pas spécifique aux SGBD.
Si je prend l'exemple de la gestion d'utilisation.
SGBD : stockage et gestion des données. C'est le SGBD qui va vérifier qu'il n'y a pas de doublon dans les ID par exemple. Utilisation de SQL car on est au niveau des données.
Applicatif : utilisation de adduser(), deluser(), etc... et non de SQL car on est au niveau applicatif et pas donné. adduser() ajoute un utilisateur (point de vu applicatif) et n'ajoute pas un enregistrement à une table (sous Unix il y a "adduser" et pas "add_one_record_to_etc_passwd" (alors que cette fonction doit bien exister :-) )). Que ça utilise une base de donnée relationnelle ou que ça tripote /etc/passwd, au niveau applicatif on s'en fout. De même, avant de faire adduser() on ne va pas vérifier s'il y a doublon ou non. C'est le SGBD (ou autre) qui le fera (comme il gèrera les accès en écriture concurrent, etc). C'est ici (niveau applicatif) qu'on ajoutera une aide contextuelle etc car ce n'est pas lié aux données.
Notes que si tu laisses l'applicatif (ou une librairie) s'occuper de l'intégrité des données (par exemples comme avec Mysql) il est impossible de faire un backup à chaud avec des données cohérentes. Dans ce cas il y a toujours des moments ou les données sont incohérentes. C'est obligé ou alors tu as une base vraiment simple.
Si tu prends PostgreSQL et tu l'utilises comme Mysql, tes backups à chaud ne valent presque rien si les contrôles d'intégrités (contrainte/transaction/etc) ne sont pas fait au niveau du SGBD. Que t'utilise un ejb ne change rien à la problématique.
Bref, encore une fois tu décris les avantages d'avoir une abstraction supplémentaire par rapport à SQL. Tu n'as pas à me convaincre de ça mais c'est du hors-sujet.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Ce que je veux dire, c'est que mon but dans le dev est de le rendre plus simple et indépendant de la base de données ce qui est tout à fait possible...
Exemple de code :
Transaction tx = null;
Keyword kw = new Keyword( 1,"red" );
tx = session.beginTransaction();
session.save( kw );
tx.commit();
Et voila, j'utilise une transaction, je sauve des données sans taper une ligne de SQL et sans avoir de code de connexion à la base de données.
Je ne veux pas utiliser de code spécifique à une base de données et ainsi pouvoir en changer suivant les besoins.
et avec ça, je voulais dire au début que la base de données MySQL peut très bien convenir dans de très nombreux devs et si le besoin s'en fait sentir... on change de base en changeant juste un fichier de config.
http://about.me/straumat
[^] # n'oublions pas les perfs
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
Alors tu regardes un peu ce qui se passe au niveau de la base de données, tu mets un mouchoir sur tes convictions, tu mets de la procédure stockée et tu gagnes un facteur 10 (cas vécu) et ton client est content et si le client est content, tu es content aussi.
[^] # Re: n'oublions pas les perfs
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: n'oublions pas les perfs
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
- J'utilise aussi les procédures stockées
- Hibernate permet de voir les requêtes SQL executées et je ne l'ai jamais vu faire de trucs "inutiles", je l'ai plutot défois vu utiliser le cache judiciseusement.
Je répète que mon fil de discution n'avait pour but à la base que de dire que dans certains cas ( le cas par exemple d'une appli utilisant un outil de mapping O/R ) la base de données MySQL avec sa vélocité peut être une bonne solution
Meme si perso, j'utilise Firebird au cas où on ai besoin de procédure stockées ou d'autres trucs évolués.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 2.
- on s'en fout il y a les ejb ou autre
Ton exemple avec "tx.commit()" est limite comique. Si le SGDB en-dessous n'a pas de support de transaction, ton "tx.commit()" ne sert à rien (et ne fait sûrement rien :-) comme c'est le cas avec beaucoup de wrapper... ). Ou alors il faut vérrouiller toutes les tables (ou quelques tables "judicieusement choisies" (comprendre qu'un jour tu vas oublier de verrouiller une table ou que tu en verrouille une de trop)) et c'est une catastrophe pour la montée en charge, etc.
Pour les réservations de place d'avion ou train, tu ne peux pas faire ça sans un solide système transactionnel (ejb ou pas). Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc... Le transactionnel doit être fait au coeur du serveur de base de donnée (il n'y a pas le chois). C'est la même chose pour les contraintes si tu ne veux pas que tes backups soit pollués (parfois même à 3 heures du matin une base est utilisée...).
L'abstraction c'est bien. Mais une bonne base de donnée c'est bien aussi et c'est même parfois indispensable (que l'API de l'abstraction de donnée soit super élégante ou non).
btw : j'en profite pour dire que de faire une base de donnée solide (avec les bonnes contraintes, les controles d'intégrité, les mises à jours de données automatiques des données annexes, etc) c'est très dure.
Mais que c'est profidable après. L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc...
Les EJB tournent dans des serveurs d'applications J2EE comme Websphere, Weblogic, Oracle 9i AS, Sun One application serveur, JBoss ou JOnAS, ils sont transactionnels, gèrent les requêtes en parralèle, supporte le clustering....
Pour finir, je dirais qu'on peut développer sans se soucier de la base de données, c'est possible.
L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée
beh je suis pas d'accord avec toi... désolé mais l'intégrité des données ne se gère pas seulement avec des contraintes.
Pour moi, les données seront bonnes si et seulement si on met la logique métier à un endroit centralisé et qu'elle est testée avec des test unitaires.
Il faut créer des fonctions creerCommande(idClient, date)... et c'est ainsi que les données seront cohérentes car on sera sur que chacun aura pas fait sa sauce dans son coin.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 2.
Pour finir, je dirais qu'on peut développer sans se soucier de la base de données, c'est possible.
Ahahah.
C'est du discours de marketeux à la petite semaine.
Ce n'est pas possible. C'est tout. Faut pas chercher plus loin. Ou alors les ejb ça fait aussi gestionnaire de base de donnée avec support de transaction etc...
C'est tout simplement du bidon et c'est tout.
Juste un petit exemple. Ta base de donnée est Mysql et elle tourne sur un machine qui n'a pas d'ejb, etc. Par contre, tous les clients passent par ejb (via des middleware par exemple).
Ça rend mysql transactionnel ?
=> Non.
Tes clients voient des données gérées de façon transactionnelles (pas seulement car il font toto->begintransaction) ?
=> Non. (ou alors les middlewares communiques entre eux pour gérer les conflits).
Donc, s'il y a une coupure de courant et plusieurs clients qui écrivent à la foi, dans quel état sont les données au niveau Mysql ?
=> corrompus/incohents (btw, mysql peut tourner en local avec ejb (ou n'importe quoi d'autre) ça ne change rien).
M'enfin, si je me trompe, je veux bien que tu m'expliques par quelle magie noire c'est fait. Sauf si ejb fait aussi SGDB, c'est impossible. Il est inutile de connaitre ejb pour arriver à cette conclusion. C'est comme ça. Ce n'est pas pour rien que PostgreSQL est PostgreSQL, qu'Oracle est Oracle, etc...
Si Mysql pouvait remplacer au pied levé Oracle seulement en utilisant des ejb (ou n'importe quoi d'autre), ça se serait.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Bon, beh je laisse tomber, si tes arguments, c'est "Je connais pas mais c'est pas possible", c'est pas la peine, la discution était quand même interessante.
Renseigne toi sur J2EE ou sur hibernate et JTA...
tu verras que beaucoup de gens ont développé des solutions très propre, qui sont en production et qui font une abstraction de la base de données.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 3.
Ben explique !
Comme fait ejb pour rendre Mysql transactionnel ?
Si une transaction c'est :
- modification table A
- modification table B
- modificaiton table C
Avec Mysql les 3 modifications seront faites une par une.
Avec PostgreSQL les 3 modifications seront visibles "d'un coup" ou ne seront pas visibles.
Donc comme fait ejb pour rend Mysql transactionnel (pense à plusieurs clients (ejb ou pas), à une coupure de courrant, un plantage, etc). S'il y a une coupure de courrant, les données qui seront utilisés seront ceux dans Myslq (donc avec des "transactions incomplètes"). Les objets persistants, etc n'interviennent pas ici puisque qu'il y a plus de courrant...
Le seul moyen pour que ce soit possible, c'est que ejb soit le seul point d'entré (il n'y a qu'une connection à la base de donnée). Alors c'est possible car il fait aussi serveur de base de données. Mais même dans ce cas la mission doit être ardue (impossible ?) avec Mysql...
Explique moi cette magie et pas en terme de :
- "tu verras que beaucoup de gens ont développé des solutions très propre, qui sont en production et qui font une abstraction de la base de données."
btw : arrête avec "une abstraction de la base de données", je sais ce que c'est et j'utilise. Merci.
[^] # Re: Et mysql
Posté par saorge . Évalué à 2.
Voilà ce que j'en retiens (donc, mon avis perso) :
- base de données objet ne sont pas mauvaise en soi, mais ne correspondent pas à certaines réalités du terrain ;
- laisser à un SGBD le soin de faire ce qu'il est censé faire à savoir la gestion des données ;
- il existe des couches d'abstraction permettant de ne pas se soucier de la base de données employées (EJB, etc) ;
- ces couches d'abstractions permettent de développer rapidement ;
- ces couches d'abstractions effacent les spécificités de certaines DB (ne gère qu'un sous-ensemble du langage SQL propre à certains sgbd) , ce qui les rend inadapté dans quelques cas précis, où il est nécessaire d'utiliser les outils de dev du sgbd pour en exploiter toute la puissance ;
- encore plein d'autres trucs, mais bon, les principaux y sont, non.
Je regrette l'impression de dialogue de sourd, mais je suis content d'y avoir lu des opinions intéressantes.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Ayrton . Évalué à 2.
Par exemple il y a les triggers ou les rules sous PostgreSQL pour faire ça.
Lorsque tu fais :
insert into command (idClient, date) values (200, now) ;
PostgreSQL fera toutes les vérifications et bidouilles nécessaires. Que ce soit depuis php ou MS-Access et même EJB.
La "vrai" table est par exemple command_data et elle n'est pas inaccessible aux utilisateurs "normaux". Tout doit passer par des accès à la view command et là le développeur peux tout faire (au niveau donné).
Ainsi personne ne fait "sa sauce dans son coin" et ejb/java n'a pas l'exclusivité dans l'utilisation et la mise à jour des données.
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
quand tu crées un utilisateur par exemple, il va falloir lui créer une adresse par défaut et tout un tas d'autres trucs... et à mon avis, c'est une grosse erreur de mettre la logique métier dans les triggers.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
Clap clap clap. Et soulagement de ne pas être seul à penser celà. :)
[^] # Re: Et mysql
Posté par Olivier Meunier (site web personnel) . Évalué à 10.
Par contre, quand on regarde la situation maintenant, j'ai de plus en plus l'impression que MySQL se retrouve pris en étau entre SQLite et PG. Un hébergeur va sans doute voir son intérêt à l'utilisation exclusive de SQLite (mise à part les perfs peut-être) et releguer MySQL au profit du premier. Pour le côté petites appli (Web ou pas), SQLite est clairement un challenger intéressant.
Côté plus pro, MySQL souffre toujours de choses qui n'en finissent pas de ne pas arriver, je pense aux procédures, annoncées depuis des années et qui n'arrivent toujours pas, là ou PG permet de faire des proc dans plein de langages (à savoir, il existe un projet de proc en Java[1] et un autre en PHP[2]).
Bref, si aujourd'hui on me demandait mon avis pour une installe de BDD, je réponds SQLite pour une appli de type access ou Web pas trop sollicitée et je réponds PG pour un gros truc, genre site de e-commerce.
[1] http://plj.codehaus.org/(...)
[2] http://plphp.commandprompt.com/(...)
(ces deux projets sont encore en dev)
[^] # Re: Et mysql
Posté par Christophe Renard . Évalué à 5.
ca permet a tous les Jean Kevin de la Terre de roxorer comme des brutes sur leur Windows 98 (oups pardon Windows 2003 server datacenter).
Ok, je fais du corporatisme antidemocratique, mais j'en ai marre que quand je Google quoi que ce soit comportant le terme database 99% des reponses soient des questions de lamers sur MySQL sur tous le forums de la terre .....
Et puis je suis de mauvais poil aujourd'hui, nah !
ok, je sors -> [ ]
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
mais bon, mieux vaut ça que de voir fleurir des sites asp access partout :)
http://about.me/straumat
# Comparatif par rapport à Oracle ?
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Je vous préviens, je ne connais vraiment que la base en SGBD. Mais j'aimerai quand même savoir ce que vaut un PostegreSQL par rapport à un Oracle.
Ce que j'ai retenu de Oracle :
- Bonne gestion des droits d'accès
- Procédure stockée
- Trigger : c'est super ce truc ! (pour valider les entrées en particulier)
- Requêtes imbriquées (ouais, bon, il faut le noter quand même ...)
- Vues
- Sauvegarde / restauration (savepoints)
- Transactions (opérations atomiques)
- Bonne gestion du clustering (dans le sens : base de donnée partagée par plusieurs serveurs)
Je sais que PostegreSQL supportait déjà un paquet de ces fonctionnalités, je vois qu'ils viennent d'ajouter les savepoints. Il reste quoi à faire ?
C'est juste pour une question de curiosité car dans mon usage personnel, MySQL est déjà trop gros :o)
Pour un stage été, je bosse sous SAP : c'est une usine à gaz (un progiciel ou vous appelez ça comme vous voulez) pour gêrer une entreprise. Ca va de la gestion des stocks à la simulation d'entreprise en passant par la maintenance. Pour une boîte de 1600 employés, ça doit vraiment faire BEAUCOUP d'informations. Ben j'ai vu que le logiciel est basé sur Oracle. Le logiciel " n'est qu'une interface graphique pour les transactions " (selon moi) ... Je me demande si PostegreSQL pourrait faire de l'ombre à Oracle pour ce genre d'applications.
@+ Haypo
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Christophe Renard . Évalué à 7.
D'ailleurs SAP peut tourner sur d'autres SGBD qu'Oracle, SAPDB entre autre qui a ete OpenSourcé il y'a quelque temps, et, je crois, doit faire l'objet d'un rapprochement avec MySQL...
La ou Oracle se distingue en particulier de PgSQL(en mal sur une petite base, mais en bien des qu'on tape dans le "gros oeuvre") c'est dans la capacite a etre "tuné" pour une application en specifiant la repartition des entites de la base (tables, index, segments de roolback...), en RAM et sur les disques, etles politiques d'evolutions de ces entites.
Une des ameliorations de la version 8 de Postgresql est justement la possiblite de configurer des Tablespaces (pas encore essaye) ce qui le rapproche de Oracle.
Depuis la version 10i de Oracle il y aurai aussi un net progres dans la possibilite de reellement repartir une base sur plusieurs machine, ce qui lui donne une avance considerable sur les bases libres, mais la j'avoue ne jamais avoir essaye.
Le point faible de Oracle : un prix exorbitant, par CPU ou par user, et une complexite de configuration qui le mettent hors de portee des projets a budget modere. C'est un creneau majeur pour les SGBD du monde libre.
On peut en tout cas imaginer un jour les SGBD du monde du libre concurencer les poids lourds du proprio dans leur environnement de predilection (grosses bases strategiques, support des progiciels geants...), et dans ce cadre PGSQL sera sans doute bien place, mais pour l'instant les DB2 et Oracle me paraissent bien accrochés.
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Victor STINNER (site web personnel) . Évalué à 1.
C'est dommage que PgSQL ne supporte pas encore d'être réparti sur plusieurs machines, car pour les *GROSSES* bases de données c'est vital ! Je pense qu'il faudra attendre qu'une boîte (petite ou grosse) se donne la peine de faire évoluer PgSQL dans ce sens ... en utilisant PgSQL dans un cas concret. Ou bien ?
@+ Haypo
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
C'est simple, pour Ms SQLServer ça n'existe pas encore, pour Oracle ça date de la 10g, ça doit faire un an à peu près. Pour ce qui est du marketing, je partage en partie ton avis. D'un autre coté, au vu de l'accroissement vertigineux de certaines bases, on peut penser que les solutions en grid ont un réel avenir. D'autant que répartir les applis de façon native (et non pas avec une solution comme C-JDBC) sur plusieurs serveurs c'est quand même un pas vers la haute dispo.
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
D'accord, pour le fait que ça semble utile mais si tu savais la complexité de ce qui se passe derrière, ça donne le vertige.
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Je m'en doute un tout petit peu pour avoir bossé sur des projets de Grid-computing et de mutualisation de BDD. De toutes façons les marketeux peuvent raconter ce qu'ils veulent, je ne commencerai à regarder la 10g que dans un an ou deux. Je suis certain qu'elle fourmille encore de bug .
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Christophe Renard . Évalué à 2.
(On pouvait explicitement faire des requetes tapant sur des bases multiples sur plusieurs machines mais bonjour les perfs ...)
Si j'ai bien compris la repartition de charge reelle n'est apparue que tres recemment avec la version &0i.
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
D'autre part Oracle a été conçu pour fonctionner sur un système de fichiers rustique ou même inexistant (raw mode). Quand on le fait fonctionner sur un système de fichiers sophistiqué comme Reiserfs, on s'aperçoit que pas mal de choses sont faites en double. Par exemple la gestion des "extends" d'Oracle date d'une époque où il fallait déclarer la taille d'un fichier avant de l'utiliser. Les "extends" créent d'autres fichiers qui sont des extensions d'une taille prédéfinie et paramétrable de la table.
Avec Postgresql, l'extension de la taille d'un fichier est gérée par le FS et Postgresql crée sa table, c'est beaucoup plus simple. Il en résulte que le travail d'administration de Postgres est beaucoup plus léger que celui d'Oracle.
[^] # Re: Comparatif par rapport à Oracle ?
Posté par Volnai . Évalué à 3.
[^] # Clustered JDBC
Posté par _alex . Évalué à 2.
L'idée c'est de faire comme du RAID sur des bases des données :
- il y a plusieurs bases de données en //
- la lecture se faire sur une BD.
- l'écriture sur toutes les BD.
Je ne sais pas ce que ca vaut ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.