Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
633 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Comparatif Mysql / postgre

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Comparatif Mysql / postgre

n°1650171
dedooz
Posté le 28-11-2007 à 12:42:12  profilanswer
 

Bonjour,
je suis actuelement sur un projet de base de donnée qui sera mis a jour par plusieur personne situé sur des sites differents, ce sera une interface web php.
 
Je suis a la recherche de complement d'information sur le mysql et le postgre afin de savoir lequel correspondrai le mieux aux attentes de la boite ou j'effectu mon stage.
 
J'hesite entre ces deux base de données et Oracle XE (version gratuite) mais la capacité de cette derniere est limitée à 4Go.
 
J'attend vos eventuels conseils, merci d'avance.


Message édité par dedooz le 28-11-2007 à 12:42:46
mood
Publicité
Posté le 28-11-2007 à 12:42:12  profilanswer
 

n°1650222
MagicBuzz
Posté le 28-11-2007 à 14:30:52  profilanswer
 

Fonctionnellement parlant, PostGre reprend au moins autant de fonctionnalités qu'Oracle.
 
MySQL, quant à lui, n'en reprend même pas le dixième.
 
En revance, MySQL est bien plus rapide et facile d'administration.
 
Pour le reste... Ca reste tous deux de bons SGBD.
 
PS : 4 Go, c'est vraiment une limitation pour ton truc ? T'es sûr ?
 
Ici je suis chez un client qui utilise un ERP, avec des centaines de commandes saisies chaque jour, et au bout de 5 ans ils ont dépassé les 2 Go de données durant l'été...
 
Alors je crois que ça te laisse de la marge !

n°1650288
dedooz
Posté le 28-11-2007 à 15:19:35  profilanswer
 

Merci, je te remerci pour ta reponse, je t'avoue que cela m'éclaire déja un peut,
cela j'aimerais savoir ce que tu me conseil,
sachant que l'entreprise souhaite créer une base de données contenant plus de 50 tables, devant etre disponible en ligne en lecture et ecriture,
elle dois aussi etre mis en relation avec une autre base de données de gestion et partage de documents.
 
Sachant que mysql s'arrete à 61 tables, par contre je ne sais pas a combien s'arrete POSTGRESQL.
J'aimerais egalement avoir des infos sur ORACLE XE si tu en as.
 
Merci d'avance.
 

n°1650298
MagicBuzz
Posté le 28-11-2007 à 15:24:33  profilanswer
 

que 61 tables dans MySQL ???
 
T'es sûr ? Parceque je trouve ça... comment dire... euh...
 
Sinon, moi je conseille SQL Server 2005 Entreprise mais c'est payant :D
Mais au moins il est blindé de doc, claire et facile d'accès.
 
A défaut, PostGre est l'équivalent à SQL Server ou Oracle, mais avec une doc bien moins accessible (écrite par des geeks autistes pour des geeks autistes si tu préfères). Mais tu ne rencontrera aucune limite avec.
 
Dans tous les cas, 50 tables, base de documents... Rassure-moi, les documents sont pas stockés DANS les tables si ?
 
Parceque si c'est pas le cas, t'aura saturé une baie de disques de 1000 To avant d'avoir rempli une base de 4 Go hein...

n°1650323
dedooz
Posté le 28-11-2007 à 15:43:01  profilanswer
 

J'ai oublier de te dire qu'il veulent une solution open source et gratuite.
 
Ensuite les documents ne seront pas stocker dans la BD, ca sur.
Les 50 tables font parti d'une base de données et la base de document est apart c pas la meme base. CETTderniere sera sur POSTGRE, mais ca ce n'est pas de mon ressort.
 
Donc toi, tu me conseil postgre sql ? et oracle 10 Express ?

n°1650333
MagicBuzz
Posté le 28-11-2007 à 15:53:03  profilanswer
 

Si tu dois t'interfacer avec une base PostGre, alors je te conseille PostGre, pour deux raisons principales :
1/ Tu pourras faire des DBLINK d'une base à l'autre sans problème (possible en mélangeant les SGBD, mais c'est s'exposer à des problèmes)
2/ N'importe qui qui a travaillé sur un système pourra filé un coup de main sur l'autre système. C'est pas négligeable, surtout pour le DBA qui va devoir maintenir les deux bases... Et surtout, ça lui permet d'héberger les deux bases sur la même machine !

n°1650348
dedooz
Posté le 28-11-2007 à 16:11:50  profilanswer
 

MagicBuzz a écrit :

Si tu dois t'interfacer avec une base PostGre, alors je te conseille PostGre, pour deux raisons principales :
1/ Tu pourras faire des DBLINK d'une base à l'autre sans problème (possible en mélangeant les SGBD, mais c'est s'exposer à des problèmes)
2/ N'importe qui qui a travaillé sur un système pourra filé un coup de main sur l'autre système. C'est pas négligeable, surtout pour le DBA qui va devoir maintenir les deux bases... Et surtout, ça lui permet d'héberger les deux bases sur la même machine !


 
eXACT CE sont des choses aux quel j'ai penser mais pour le moment les deux seul choses ki me freine un peut sur mon choix definitif, cest que je ne trouve aucune doc bien faite pour interfacer php/postgre et que je ne sais pas si ORACLE 10 express ne serai pas mieux sachant que c oracle et que c gratuit.
 
Je te remerci pour tes conceil j'en tiendrai compte lors de ma decision.
 
a bientot

n°1650355
Taz
bisounours-codeur
Posté le 28-11-2007 à 16:15:53  profilanswer
 

MagicBuzz a écrit :

Fonctionnellement parlant, PostGre reprend au moins autant de fonctionnalités qu'Oracle.
 
MySQL, quant à lui, n'en reprend même pas le dixième.
 
En revance, MySQL est bien plus rapide et facile d'administration.


foutaise et fud.
 
http://www.postgresqlfr.org/?q=node/1432

n°1650370
dedooz
Posté le 28-11-2007 à 16:25:15  profilanswer
 


 
C'est sympa que tu reponde, mais peux tu argumenter, ici nous sommes civilisés, merci d'avance,
en attendant ta reponse.

n°1650371
MagicBuzz
Posté le 28-11-2007 à 16:26:00  profilanswer
 

dedooz > T'as dû chercher loin :o
http://www.manuelphp.com/php/ref.pgsql.php
 
taz > ouais, et sur mysql.com, t'as l'article opposé.
 
chez oracle on dit qu'on est mieux que chez microsoft, et chez microsoft on dit l'inverse.
 
forcément, si tu compares des procédures stockées faisant appel à des transactions de façon intensives, deux domaines neufs sous mysql et pas encore optmisés, tu vas exploser mysql avec postgre.
mais pour une utilisation courante, genre insertions et selections unitaires sans transactions, postgre est à la rue, c'est toujours autant le cas aujourd'hui qu'il y a 5 ans (surtout si avec mysql tu choisi un format de fichier non transactionnel)
 
globalement, les perfs de mysql, pour 99% de l'utilisation d'un sgbd, sont suppérieures à postgre. ça ne remet pas pour autant en cause sa montée en charge ou ses capacités. c'est un fait. une requête d'insertion de 100 000 lignes qui prends 0,001 seconde, sous postgre c'est impossible. sous mysql, on trouve ça très lent.
 
après y'a aussi des domaines où windows est mieux que linux, sisi, en cherchant bien ça doit se trouver.

mood
Publicité
Posté le 28-11-2007 à 16:26:00  profilanswer
 

n°1650570
Sh@rdar
Ex-PhPéteur
Posté le 28-11-2007 à 22:29:09  profilanswer
 

la limite de 61 tables sous mysql est fausse, un typo3 (cms) avec 2-3 plugins ça t'en fait facilement le double :p

n°1650574
Harkonnen
Modérateur
Un modo pour les bannir tous
Posté le 28-11-2007 à 22:44:54  profilanswer
 

Sh@rdar a écrit :

la limite de 61 tables sous mysql est fausse, un typo3 (cms) avec 2-3 plugins ça t'en fait facilement le double :p


:hello:

n°1650639
Taz
bisounours-codeur
Posté le 29-11-2007 à 08:20:30  profilanswer
 

MagicBuzz a écrit :

dedooz > T'as dû chercher loin :o
http://www.manuelphp.com/php/ref.pgsql.php
 
taz > ouais, et sur mysql.com, t'as l'article opposé.
 
chez oracle on dit qu'on est mieux que chez microsoft, et chez microsoft on dit l'inverse.
 
forcément, si tu compares des procédures stockées faisant appel à des transactions de façon intensives, deux domaines neufs sous mysql et pas encore optmisés, tu vas exploser mysql avec postgre.
mais pour une utilisation courante, genre insertions et selections unitaires sans transactions, postgre est à la rue, c'est toujours autant le cas aujourd'hui qu'il y a 5 ans (surtout si avec mysql tu choisi un format de fichier non transactionnel)
 
globalement, les perfs de mysql, pour 99% de l'utilisation d'un sgbd, sont suppérieures à postgre. ça ne remet pas pour autant en cause sa montée en charge ou ses capacités. c'est un fait. une requête d'insertion de 100 000 lignes qui prends 0,001 seconde, sous postgre c'est impossible. sous mysql, on trouve ça très lent.
 
après y'a aussi des domaines où windows est mieux que linux, sisi, en cherchant bien ça doit se trouver.


mais qu'est-ce que je fous ici à discuter avec un type d'un produit qu'il a tellement utilisé qu'il ne sait même pas l'orthographier ?

n°1650667
casimimir
Posté le 29-11-2007 à 10:15:36  profilanswer
 

tu discutes pas, t'essayes juste de descendre systematiquement magic, discuter c'est avoir un dialogue sissi

n°1650674
MagicBuzz
Posté le 29-11-2007 à 10:21:30  profilanswer
 

merci casimimir, tout est dit :jap:

n°1650789
Sh@rdar
Ex-PhPéteur
Posté le 29-11-2007 à 13:40:21  profilanswer
 
n°1650802
Taz
bisounours-codeur
Posté le 29-11-2007 à 14:00:21  profilanswer
 

casimimir a écrit :

tu discutes pas, t'essayes juste de descendre systematiquement magic, discuter c'est avoir un dialogue sissi


ouais c'est tout à fait ça. Je file un lien intéressant et la seule réponse que j'ai d'une personne qui n'a jamais utilisé postgres c'est "les autres disent le contraire et ils ont raison". Personne qui si elle lisait un peu l'article comprendrait qu'il n'est pas question de comparées des requêtes tordues mais bien de propriétés fondamentales d'un SGBDR. Magic nous annonce des chiffres délirants et mythomanes sur des histoires d'insertion de "100 000 lignes qui prends 0,001 seconde". Il en vient à nous conseiller sa daube de SQLWormServer. Enfin il nous explique que "A défaut, PostGre est l'équivalent à SQL Server ou Oracle, mais avec une doc bien moins accessible (écrite par des geeks autistes pour des geeks autistes si tu préfères)." ce qui est finalement assez vrai dans la mesure où si tu ne sais pas orthographier le produit, tu risques d'avoir du mal à trouver la doc.

n°1650880
dedooz
Posté le 29-11-2007 à 15:05:28  profilanswer
 

Salut, au depart j'ai poster cette article pour avoir un comparatif entre MYSQL et POSTGRESQL, merci de revenir au sujet d'origine. Merci d'avance

n°1650892
Taz
bisounours-codeur
Posté le 29-11-2007 à 15:27:40  profilanswer
 

Donc le lien que j'ai posté est pas mal notamment à propos des propriétés ACID / fiabilité.
 
Sinon niveau perfs, l'un ou l'autre, tu seras satisfait. Je parle en tant qu'admin pg: la conf est très simple, la documentation est excellente. Les outils et le support complet des transactions permettent de faire du très bon travail notemment backup et MAJ de schéma (atomicité).

n°1651011
dedooz
Posté le 29-11-2007 à 19:17:59  profilanswer
 

Taz a écrit :

Donc le lien que j'ai posté est pas mal notamment à propos des propriétés ACID / fiabilité.
 
Sinon niveau perfs, l'un ou l'autre, tu seras satisfait. Je parle en tant qu'admin pg: la conf est très simple, la documentation est excellente. Les outils et le support complet des transactions permettent de faire du très bon travail notemment backup et MAJ de schéma (atomicité).


 
Ok merci pour cette réponse, maintenant que j'ai eliminé Mysql de mon choix car il ne correspond pas asser a ce ke je recherche,
par contre ya deux nouveau ki sont en lisse,
SQL SERVER 2005 ET ORACLE 10 XE,
 
je ne sais aps trop vu que se sont des version moin puissante que leur version payante, si elles seront a la hauteur des attente de l'entreprise.
 
Que pensez vous de ces deux SGBD ?

n°1651024
Harkonnen
Modérateur
Un modo pour les bannir tous
Posté le 29-11-2007 à 19:49:41  profilanswer
 

Laisse tomber Oracle, à moins que tu sois accro :
- aux erreurs aléatoires injustifiées (bonjour les ORA-01031 en étant loggé en SYS)
- à l'administration lourdingue et d'un autre age (quand on voit la gueule de SQL*PLUS, franchement... proposer un tel outil en 2007 est une honte)
- au déploiement bloaté et d'une lourdeur éléphantesque
- au PL/SQL bien pourri (vive les PS en C# de SQL Server 2005)
- ...

n°1651033
dedooz
Posté le 29-11-2007 à 20:01:25  profilanswer
 

Harkonnen a écrit :

Laisse tomber Oracle, à moins que tu sois accro :
- aux erreurs aléatoires injustifiées (bonjour les ORA-01031 en étant loggé en SYS)
- à l'administration lourdingue et d'un autre age (quand on voit la gueule de SQL*PLUS, franchement... proposer un tel outil en 2007 est une honte)
- au déploiement bloaté et d'une lourdeur éléphantesque
- au PL/SQL bien pourri (vive les PS en C# de SQL Server 2005)
- ...


Je sais qu"ORACLE possède certaines faille, mais ça reste quand même la référence, je veux juste savoir si ORACLE 10 XE et SQL Server 2005 Expresse sont des SGBDs de qualité et si PostGreSQL peut les remplacer sans grandes différences.

n°1651046
Harkonnen
Modérateur
Un modo pour les bannir tous
Posté le 29-11-2007 à 20:21:37  profilanswer
 

Oracle est certes une référence, mais une référence Commerciale et pas Technique, tu saisis la nuance ? C'est pas parce qu'un produit est leader que c'est forcément le meilleur, c'est juste qu'il est mieux vendu.
Ceci étant dit, j'avoue ma préférence pour SQL Server Express. Mais ni l'un ni l'autre ne rentrent dans tes critères car comme tu le dis toi même, tu cherches une solution Open Source ce que ni l'un ni l'autre sont.
Donc pour toi, point de salut : PostgreSQL te tend les bras.

n°1651175
MagicBuzz
Posté le 29-11-2007 à 22:33:12  profilanswer
 

Taz a écrit :


Je file un lien intéressant et la seule réponse que j'ai d'une personne qui n'a jamais utilisé postgres c'est "les autres disent le contraire et ils ont raison".


Vas-y les déformations. Arrête de lire en diagonale mes posts avant de me faire dire ce que je n'ai pas dit.
 
Chaque produit proclame haut et fort qu'il est le meilleur, donc ton lien n'est pas "fiable" c'est tout ce que j'ai dis dans mon post.
Il n'en reste pas moins qu'il peut être intéressant, jamais dit le contraire.
 
Par contre, tu noteras quand même que l'article stipule lui-même que les tests sur lesquels il se base ne supportent pas de comparaisons : matériel différent, conditions de test différentes, etc. Et du coup il est principalement théorique.
PostGres avec un S si ça te fait tant plaisir, a bien évolué, et c'est tant mieux, mais il n'y a guère plus de choses à en retenir.
J'aime surtout la petite éloge d'Oracle d'un point de vue rapidité, etc. Si PostGres est comparable à MySQL sur ce point, alors tu peux mettre de côté Oracle, qui est très loin derrière.
Le seul atout d'Oracle d'un point de vue performances, c'est sa montée en charge qui est exemplaire. Pour le reste, il est très lent comparé à MySQL.
La moindre requête du genre "select 1 from dual" prends systématiquement 5 à 10 ms.
Autant sur de très grosses requêtes concurrentielles dans de grosses transactions, il va tirer son épingle du jeu, autant pour la moindre petite requête (et c'est quand même ce genre de requêtes qui sont les plus utilisées) c'est incoparablement plus lent. Donc selon l'utilisation, généralement Oracle n'offira clairement pas le même niveau de performances (transa-quoi déjà ?)
 
Enfin, pour reprendre l'article en question, il est spécifié que le test de MySQL est effectué avec la version 5.0
Et c'est rigoureusement ce que j'ai répondu. La 5.0, c'est plus une béta qu'une version d'exploitation. Elle apporte plein de nouveautés (vues, PS, triggers, etc.) mais absolument rien n'a encore passé la phase d'optimisation : ça marche, et c'est déjà ça. Un très grand nombre de gens s'en sont d'ailleurs plainds, et la version 5.1 était très attendue.
Pour cette raison, une comparaison avec la 5.1 ou une 4.x aurait été bien plus parlante, puisque MySQL n'est plus aussi désavantagé avec cette version (ceci dit, comparer PostGres à MySQL < 5, c'est une insulte pour PostGre).
 
Au fait, Christophe Chauvet alias KrysKool, cité en fin d'article, n'est ni plus ni moins qu'un de mes collègues. On en discute suffisament comme ça à chaque fois que je le dépanne sous SQL Server pour que je sâche un minimum de quoi je parle.


Message édité par MagicBuzz le 29-11-2007 à 22:33:24
n°1651627
el muchach​o
Comfortably Numb
Posté le 01-12-2007 à 08:05:36  profilanswer
 

dedooz a écrit :

 

eXACT CE sont des choses aux quel j'ai penser mais pour le moment les deux seul choses ki me freine un peut sur mon choix definitif, cest que je ne trouve aucune doc bien faite pour interfacer php/postgre et que je ne sais pas si ORACLE 10 express ne serai pas mieux sachant que c oracle et que c gratuit.

 

Je te remerci pour tes conceil j'en tiendrai compte lors de ma decision.

 

a bientot


Non, ça n'est pas mieux du tout. Oracle XE ne sert que pour le développement sous Oracle. Autrement dit, il est utile si ta compagnie a déjà choisi Oracle. A ce moment-là, il est pratique car on peut déployer un Oracle XE sur son poste pour développer, au lieu d'acheter une licence (hors de prix, comme tout chez Oracle) et un serveur dédié à partager entre devs.
Pour la production, il ne faut pas compter dessus, il est quasi inutilisable, avec sa limitation à 1 Go de RAM, ce qui réduit certainement considérablement ses performances (sachant qu'XE prend déjà ~400 Mo au démarrage). Il n'y a pas officiellement de limite de connexions simultanées mais la limitation sur la RAM fait offfice de limitation sur le nombre de connexions simultanées. Oracle ne va pas distribuer son produit gratuitement du jour au lendemain, faut pas rêver.
Ah et Oracle est BIEN plus compliqué et casse-burnes à administrer que MySQL ou Postgres. Ok, XE est simple à installer, mais le jour où vous décidez de sortir le portefeuille pour le produit complet, c'est une autre paire de manches. Et à l'utilisation, Oracle réserve effectivement plein de surprises, notamment avec des messages d'erreur d'une infinie variété et qui n'ont strictement rien à voir avec les erreurs qu'ils sont censés montrer (une belle partie de plaisir pour le dev). Ce qui réduit considérablement le "facteur fun" d'Oracle et donc la productivité du développeur. A ne pas négliger quand on va passer quelques années à développer sur un produit.

 

Franchement, prends Postgres 8 ou MySQL 5 (qui continue à s'améliorer et n'a bien sûr jamais été limité à 61 tables. Le nombre de tables par base est probablement illimité, ou alors un nombre comme 32000). L'un et l'autre logiciels ont largement fait leurs preuves en production. Perso, j'ai une grosse préférence pour Postgres, qui au niveau du développement a quasi autant de fonctionnalités qu'Oracle. En particulier, les procédures stockées sont un accélérateur de développement et surtout de performances que même des données brutes sur des select ne peuvent rattraper (car une PS permet de supprimer tout l'overhead entre ton appli cliente et le moteur de base de données, - à savoir essentiellement de multiples transferts de données sur le réseau, les surcouche applicatives/persistence du client -, vs traitement en RAM dans le cas d'une PS --> on peut obtenir des gains de perfs de x100 ou plus). Par contre autant l'usage massif de PS permet d'augmenter considérablement les perfs (si le serveur dédié est costaud), autant il interdit toute migration vers une autre base à l'avenir.

 

Si vous optez pour un logiciel commercial, SQL Server est basé sur Sybase, qui est très performant aussi.

Message cité 1 fois
Message édité par el muchacho le 01-12-2007 à 08:30:46

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
n°1651631
el muchach​o
Comfortably Numb
Posté le 01-12-2007 à 09:06:10  profilanswer
 

Allez, je m'autoquote:

 

"Oracle Enterprise Manager c'te grosse bouse au nom marketing hypertrophié. Comment je plains Harko [:le kneu]

 

Donc je voulais insérer un nouvel enregistrement à une table existante. Hop, un copier-coller d'une ligne existante, et le tour est joué.
Seulement voilà, quand on insère une date via un bête copier-coller d'une date qui existe, Oracle te sort un beau

Citation :

ORA-01841: année(complète) doit être comprise entre -4789 et +9999 et être différente de 0

 

Ah, bon. On vérifie, on re-vérifie la date, elle est bonne.
Finalement, un collègue t'explique que t'as tout faux, qu'un copier-coller ne fonctionne pas parce qu'il faut en fait insérer la commande escuelle:
TO_DATE('21-avr. -2006 10:15:00 AM', 'dd-Mon-yyyy HH:MI:SS AM')

 

Vaincu par la logique implacable de la chose (vu qu'on spécifie le format), on s'exécute patiemment.
 

Citation :

ORA-00907 parenthèse de droite absente

[:le kneu]

 

Mais bien sûr...
 :sleep:
A nouveau vaincu, mais passablement énervé au bout de 40mn à chercher, on on essaye alors autre chose.
Le machin est censé te sortir la commande SQL qui correspond à une insertion dans un tableau via la supaaaiiiir IHM en Java. Chouette, me dis-je, je n'ai qu'à la recopier dans SQL*Plus, en faisant très attentiion à ne pas me planter vu le degré d'user-friendliness de cet outil, et le tour et joué. :)

 

Evidemment, ça ne marche pas. La commande SQL générée par l'outil "Oracle Enterprise Manager" est bourrée d'espaces posés au hasard du genre (copier-coller de la commande générée):

Code :
  1. INSERT INTO "CORE31"."COUNTER_DEFINITION" ("COUNTER_ID" ,
  2.     "COUNTER_NAME" ,"TYPE" ,"ACTIVE_FLAG" ,"ACTIVE_START" ,
  3.     "ACTIVE_END" ,"PERIOD" ,"FILTER1" ,"OPERATOR1" ,"FILTER2" ,
  4.     "OPERATOR2" ,"FILTER3" ,"OPERATOR3" ,"FILTER4" ,"OPERATOR4" ,
  5.     "FILTER5" ,"OPERATOR5" ,"VERSION_NBR" ,"LANGUAGE_ID" ,
  6.     "REMARK" ,"CREATED" ,"DOMAIN_ID" ,"BATCH_MODIFIED" ,
  7.     "UPDATE_USER" ,"PARAM_VALUE" ,"OPERATOR" ,
  8.     "NUMBER_COUNTER_FLAG" )
  9.     VALUES (6 ,'Non regression Test 5' ,1 ,1 ,TO_DATE('21-mars
  10.     -2005 11:04:00 AM', 'dd-Mon-yyyy HH:MI:SS AM') ,
  11.     TO_DATE('21-avr. -2006 10:15:00 AM', 'dd-Mon-yyyy HH:MI:SS
  12.     AM') ,60000 ,'' ,'' ,'' ,'' ,'' ,'' ,'' ,'' ,'' ,'' ,1 ,'fr '
  13.     ,'' ,TO_DATE('15-mars -2006 03:47:12 PM', 'dd-Mon-yyyy
  14.     HH:MI:SS AM') ,1 ,TO_DATE('24-mai  -2006 02:43:34 PM',
  15.     'dd-Mon-yyyy HH:MI:SS AM') ,'spop' ,'APP.*' ,'like' ,1  )


Admirez le placement des espaces avant (!) les virgules. C'est pas beau, ça ? Mais le pire étant les chaînes coupées en plein milieu avec des espaces en début de ligne. Sûr que SQL va apprécier...
Qu'à cela ne tienne, je la recopie dans mon éditeur favori, dégage les CR/LF superflus  et rejoue.

 

... Reperdu ! :fou:

 

Finalement, je m'aperçois que cette daube d'OEM génère une commande fausse, du fait d'une traduction hasardeuse et de tests inexistants chez Oracle.
En effet, "21-avr. -2006" comporte un point et un espace de trop, "24-mai  -2006" a 2 espaces de trop, etc. Evidemment, dans la police sans serif proposée par OEM, c'est à peine visible.

 

Non mais vraiment...

 

Actuellement, j'en suis à :

Citation :

ORA-01401: valeur insérée trop grande pour colonne

. Surtout ne me dis pas où. :kaola:"


Message édité par el muchacho le 01-12-2007 à 10:26:36

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
n°1651637
el muchach​o
Comfortably Numb
Posté le 01-12-2007 à 10:05:23  profilanswer
 

Pour une bonne tranche de rire, quelques perles:

Citation :

skeye a écrit :
 
http://www.orafaq.com/error/ora-01403.htm
Citation :
 
 
The easiest fix would be is to handle the error in the PL/SQL block
 
When a SQL statement is written within a PL/SQL block, enclose the SQL with a BEGIN and END statement. Handle the exception and raise a user-friendly message or handle the rest of the processing.
 
 
[:rofl]
 
 
super l'explication [:wam]
t'as une erreur ? t'as qu'a foutre un try/catch et tu traduis le message en français pour faire plaisir à l'user !
oracle, c'est vraiment top :pfff:


Citation :

je viens de tester Oracle 10g \o/
c'est toujours aussi archaique et pourri \o/


Citation :

tiens, mon trigger a explosé la base, c'est génial Oracle ! un simple trigger de 2 lignes , et c'est toute une banque qui est paralysée [:fenston]


Citation :

salut les lootres !
ma journée fut intense. j'explique : je n'ai rien foutu d'autre que d'essayer de comprendre pourquoi ce matin, en embauchant, j'ai eu ce message :
 
Citation :
 
 
SQL*Plus: Release 8.1.7.0.0 - Production on Je Dec 2 18:07:56 2004
 
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
 
 
Connected to:
Oracle8i Release 8.1.7.0.0 - Production
JServer Release 8.1.7.0.0 - Production
 
SQL> connect internal
Enter password: ***********
ERROR:
ORA-01031: insufficient privileges
 


Citation :

j'adore Oracle... le seul SGBD qui change le mot de passe SYS de lui même pendant une nuit...


Citation :

Harkonnen a écrit :
 
au fait skeye, tu connais le hash utilisé pour encoder le pass d'un user oracle ? c'est pas du MD5 en tout cas
 
 
réponse d'Oracle
Citation :
 
 
The algorithm is a modified DES algorithm which is proprietary to Oracle. In
addition, the algorithm is one-way so there is no way to decrypt it.
 
 
/o\


Citation :

si un jour vous avez du temps à perdre, installez Oracle 10g sur Fedora !
j'ai renoncé au bout de 10 heures infructueuses


Citation :

tiens, en parlant de bloatware, vous connaissez la dernière que m'a fait Oracle cet aprèm ?
j'ai fait un INSERT tout con, et la base s'est carrément arrétée ! en fait, l'INSERT m'avait éteint les services ! pourquoi ? va savoir... :pfff:


Citation :

program de l'aprèm : débugger un script PL/SQL tout plein de fonctions avec des paramètres IN et OUT dedans [:el g]
Oracle, un petit pas pour le SGBD, un pas de géant dans la merde [:pingouino]

 

Citation :

Oracle, O Désespoir, O SGBD ennemi


Citation :

vous noterez quand même la présence d'une erreur ORA-xxx alors qu'Oracle n'est pas dispo !
c'est ça que j'aime chez Oracle : même quand il est pas là, il continue de te faire chier


Message édité par el muchacho le 01-12-2007 à 10:13:35

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
n°1651638
dedooz
Posté le 01-12-2007 à 10:13:06  profilanswer
 

el muchacho a écrit :


Par contre autant l'usage massif de PS permet d'augmenter considérablement les perfs (si le serveur dédié est costaud), autant il interdit toute migration vers une autre base à l'avenir.
 
Si vous optez pour un logiciel commercial, SQL Server est basé sur Sybase, qui est très performant aussi.


 
Merci 'el muchacho'
 
Donc si je comprend bien, le choix de PostGres est un choix definitif ? impossible de d'exporter mes bases sur une autre SGBD, il n'y a vraiment aucun moyen ?

n°1651639
el muchach​o
Comfortably Numb
Posté le 01-12-2007 à 10:24:37  profilanswer
 

Oui et non.
Les Proc stockées de PG sont globalement compatible avec Oracle (enfin selon Harkonnen, à vérifier). Mais de toute façon, une fois qu'on utilise des PS, sauf si elles sont codées dans un langage standard, on peut oublier les portages, parce que PL/SQL (Oracle) et Pg/SQL (PG) sont des langages propriétaires. C'est pour ça que bcp de boîtes codent la logique applicative dans les applis client, ce qui est à mon sens une erreur stratégique, parce que le portage vers une BD même 4x plus rapide rattrapera rarement les pertes de performances dues aux entrées/sorties (et jamais si ça passe par le réseau).
Mais globalement, on peut dire qu'il n'existe pas vraiment 2 bases de données compatibles, parce que très peu supportent le SQL standard. Donc un portage d'une BD vers une autre prendra de toute façon tjrs pas mal de ressources. A ce titre, PG est peut-être la plus standard de toutes car elle supporte intégralement SQL92, ce qui n'est pas le cas d'Oracle, par ex. qui n'est pas standard du tout, - ni même de MySQL -.


Message édité par el muchacho le 01-12-2007 à 10:38:11

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
n°1651643
el muchach​o
Comfortably Numb
Posté le 01-12-2007 à 10:39:22  profilanswer
 

Disons que pour la compatibilité Oracle, PG est probablement le meilleur choix (à part Oracle XE évidemment). Après, je préfère laisser la place aux spécialistes BD plutôt que de dire n'importe quoi.


Message édité par el muchacho le 01-12-2007 à 10:55:56

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
n°1651651
dedooz
Posté le 01-12-2007 à 11:31:49  profilanswer
 

Donc si je veux transférer d'une SGBD  à une autre, faudra exporter les tables et tous reprogrammer, si j'ai bien compris.

n°1651652
MagicBuzz
Posté le 01-12-2007 à 12:01:40  profilanswer
 

changer de sgbd en cours de route, oui, c'est toujours un gros travail.
 
faut pas "tout" refaire, mais en effet y'a pas mal de choses qui ne passent plus, car le support du langage sql n'est jamais éxactement le même d'un sgbd à l'autre (pg est l'outils qui se rapproche le plus de la norme) mais surtout les langages pg/sql, pl/sql, t-sql mar exemple... comme leur nom l'indique, ne sont pas compatibles... ils sont équivalent, structurés de la même façon, mais syntaxiquement différents.
 
donc ça nécessite pas mal de boulot.
 
mais pas autant que de passer par exemple d'un programme écrit en VB à un programme écrit en VB.NET : mise à part la syntaxe, généralement t'as rie à modifier.

n°1651654
dedooz
Posté le 01-12-2007 à 12:21:57  profilanswer
 

Merci, c'est ce que je voulais savoir, car l'entreprise, après mon passage passera peut être à une SGBD sous licence, donc faut prévoir l'exportation au cas ou (un cahier des charges).
 
Je vous remercie vous avez répondu a mes questions, tout devient plus clair, bien sur j'ai fait de recherche en parallèle.
 
Donc je proposerai en premier temps PostGreSQL et je proposerai de passer sous SQL Server si ils veulent passer sous licence.
 
Merci encore ...

n°1651725
Elmoricq
Modérateur
Posté le 01-12-2007 à 20:09:33  profilanswer
 

Autres frais à prévoir pour l'entreprise : un DBA à plein temps.  
Une base de données ça demande du travail à maintenir, et le monde de l'administration est très différent de celui du développeur.
 
Côté SGBD payant y a Sybase qui est pas mal aussi, en tout cas c'est ce qui est utilisé chez nous et c'est solide (par contre ce SGBD souffre également de "concision" lors de problèmes... genre un insert qui foire au milieu, il te dit juste que ça a foiré, pourquoi, mais pas où [:joce])

n°1651731
dedooz
Posté le 01-12-2007 à 20:31:50  profilanswer
 

Elmoricq a écrit :

Autres frais à prévoir pour l'entreprise : un DBA à plein temps.  
Une base de données ça demande du travail à maintenir, et le monde de l'administration est très différent de celui du développeur.


 
Ah ça je sais qu'il faut prévoir un DBA, j'aurai aimé prendre ce poste, mais bon faut voir ce que l'entreprise a comme moyen et si il n'en pas déjà prévu d'embaucher quelqu'un(ce qui m'etonnerais) mais bon ils le savent aussi.
 

Citation :

Côté SGBD payant y a Sybase qui est pas mal aussi, en tout cas c'est ce qui est utilisé chez nous et c'est solide (par contre ce SGBD souffre également de "concision" lors de problèmes... genre un insert qui foire au milieu, il te dit juste que ça a foiré, pourquoi, mais pas où [:joce])


 
Au sujet de des problèmes de 'concision' apparemment grand de bases de données en souffre d'après ce que je li depuis l'ouverture de ce topic lol.

n°1651757
MagicBuzz
Posté le 01-12-2007 à 23:03:35  profilanswer
 

Elmoricq a écrit :

Autres frais à prévoir pour l'entreprise : un DBA à plein temps.  
Une base de données ça demande du travail à maintenir, et le monde de l'administration est très différent de celui du développeur.


C'est pour cette raison que beaucoup de gens aiment SQL Server et MySQL.
Car contrairement à Oracle surtout, et PostGres (à moins que ça ait changé), ils ne nécessitent que très peu de paramétrage, beaucoup de choses étant automatisées par défaut, et les paramètres par défaut étant généralement suffisants pour avoir un bon compromis entre "compétence de DBA" et "performances du serveur".
Oracle, c'est l'horreur, puisque par exemple il ne sait pas redimensionner automatiquement un tablespace : crash assuré plusieurs mois/années après mise en place, sans que personne n'aie la moindre idée du pourquoi du comment.
Pour PostGres, il fallait à l'époque autant de boulot que pour Oracle afin d'obtenir un truc stable et performant. Je ne sais pas si ça a évolué depuis.


Message édité par MagicBuzz le 01-12-2007 à 23:07:10
n°1651770
el muchach​o
Comfortably Numb
Posté le 02-12-2007 à 09:21:00  profilanswer
 
mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Comparatif Mysql / postgre

 

Sujets relatifs
[php/mysql] Ajout d'un prix variable dans le panierlangue arabe et mysql
[php/Mysql] requete à partir d'une requeteprobleme mysql + droits
Remplacer fonction mysql par odbc dans scriptinstaller PHP et MySQL sur un IIS
Migration PostGre SQL vers MySQLRequete mysql avec min() et max()
Erreur entre PHP et BD mysql 
Plus de sujets relatifs à : Comparatif Mysql / postgre


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR