2008-10-19 10 views
5

Je dois commencer à construire l'architecture pour un projet de base de données mais je ne connais pas vraiment les différences entre les moteurs.postgresSQL différences d'oracle mysql

Quelqu'un peut-il expliquer quels sont les avantages et les inconvénients de chacun de ces trois moteurs? Nous allons devoir choisir l'un d'entre eux et la seule chose que je sais en fait à leur sujet est le suivant:

  • Mysql & Postgres:
    • sont gratuits, mais pas aussi bon que l'oracle
    • Mysql sécurité problèmes (est-ce vrai?)
  • Oracle:
    • meilleur moteur de base de données dans le monde
    • cher

Quelqu'un peut-il effacer d'autres différences entre eux? C'est un projet moyen/grand (on pense à environ 100 à 200 tables) avec un budget réduit, que choisiriez-vous? Et avec un budget plus élevé?

Merci à tous pour avoir aidé à clarifier les différences. Ps: J'espère ne pas dupliquer un post existant, mais j'ai essayé de chercher et je n'en ai pas trouvé.

Répondre

12

Il y a quelques années, j'ai dû écrire un moteur de traduction; vous lui donnez un ensemble de sql et il se traduit par le dialecte du moteur actuellement connecté. Mon moteur fonctionne sur Postgres (AKA PostgreSQL), Ingres, DB2, Informix, Sybase et Oracle - oh, et ANTS. Franchement, Oracle est mon moins favori (plus sur cela ci-dessous) ... Malheureusement pour vous, MySQL et SQL Server ne sont pas sur la liste (à l'époque aucun n'était considéré comme un SGBDR sérieux - mais les temps changent).

Sans égard à la qualité ou la performance du moteur - et la facilité de fabrication et la restauration des sauvegardes - voici les principaux domaines de la différence:

  • types de données
  • limites
  • invalides
  • réservés mots
  • null sémantique (voir ci-dessous)
  • citation sémantique (guillemets simples ', double citation', ou e ither)
  • sémantique d'achèvement de l'instruction
  • sémantique de la fonction
  • Date de manutention (y compris des mots-clés constants comme 'maintenant' et entrée/formats fonction de sortie)
  • si les commentaires en ligne sont autorisés
  • attribut longueurs maximales
  • nombre maximal d'attributs
  • paradigme de sémantique/sécurité de connexion.

Sans vous ennuyer sur toutes les données de conversion, voici un échantillon pour un type de données, LVARCHAR:

oracle = varchar (% x) sybase = text db2 = "long varchar" Informix = LVARCHAR postgres = varchar (% x) ants = varchar (% x) ingres = varchar (% x,% y)

La plus grosse affaire de toutes, à mon avis, est la gestion du zéro; Oracle convertit SILENTLY les chaînes d'entrée vierges en valeurs nulles. ... Quelque part, il y a longtemps, j'ai lu un article que quelqu'un avait écrit sur "Les dix-sept significations de Null", et le point réel est que les NULL sont très précieux et la distinction entre une chaîne vide et une chaîne vide est utile et non-trivial! Je pense qu'Oracle a fait une énorme erreur sur celui-ci; aucun des autres n'a ce comportement (que j'ai jamais vu). Mon deuxième plus petit favori était ANTS parce que contrairement à tous les autres, ils ont appliqué les règles stupides pour la syntaxe parfaite que personne d'autre ne fait et même s'ils sont peut-être la seule société DB à fournir une parfaite conformité à la norme, ils sont aussi une douleur royale dans le cul pour écrire un code pour.

De loin, mon préféré est Postgres; C'est très rapide dans les situations _real_world_, il a un très bon support et est open source/gratuit.

+0

Oracle recommande d'utiliser varchar2 et non varchar. –

+0

Merci pour la mise à jour, Mark. Je vais m'assurer que cela sera propagé dans le moteur - et prendre un moment pour chercher d'autres mises à jour, aussi. RT –

3

Voir les tableaux de comparaison sur wikipedia: http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems & & http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

Oracle peut ou peut ne pas être le meilleur. C'est cher, mais ça ne veut pas dire mieux.

Avez-vous regardé DB2? Sybase? Teradata? MS SQL?

+0

ty, je suis étudiante et c'est pour un projet universitaire, le professeur de db ne parlait que de ça, je connaissais MS sql mais je n'avais aucune idée des autres. Tks pour le lien :) – fmsf

+0

HTH :) ..Je resterais avec n'importe quel rdbms auquel l'école a accès: que ce soit MS SQL, ORacle, MySQL, ou PostgreSQL (il est peu probable qu'ils aient DB2, mais possible) – warren

+0

nous pouvons choisir n'importe quel libre ou oracle – fmsf

4

Les différences entre les différentes implémentations SQL sont grandes, au moins sous le capot. Ces planches ne suffiront pas à les compter toutes.

Si vous devez demander, vous devez également vous demander si vous êtes en mesure de prendre une décision valide et fondée sur le sujet.

A comparison von MYSQL and Postgres can be found here

Notez que Oracle propose également un Express (XE) edition, réduit en fonctionnalités, mais libre d'utiliser. Aussi, si vous avez peu de connaissances pour commencer, vous devrez apprendre vous-même, je choisirais n'importe lequel, et commencer à apprendre en l'utilisant.

+0

Même commentaire que je suis parti pour warren, je suis un étudiant, et c'est pour un projet dans une classe, nous avons essayé de rechercher, mais nous ne pouvons pas comprendre ce qui serait mieux pour l'utilisation. L'Univ nous donne des clés pour oracle. Tks pour le lien et la référence – fmsf

+0

Vous avez seulement besoin de XE si vous voulez l'utiliser dans Prod. Si vous essayez simplement ... téléchargez l'édition d'entreprise et apprenez toutes les fonctionnalités. –

2

Je pense que pour les scénarios à petit budget, Oracle est hors de question. 100-200 tables n'est pas grande et généralement la quantité de tables dans un schéma n'est pas une mesure d'échelle. L'ensemble de données et le débit sont.

Vous pouvez jeter un oeil à http://www.mysqlperformanceblog.com/ (et leur livre superbe) pour voir comment MySQL peut gérer des déploiements énormes.

Généralement de nos jours, la plupart des RDBMS peuvent faire presque tout ce dont vous avez besoin dans une application très sérieuse.