Discussion :

[TGMDev]

J'utilise très souvent SQLite: empreinte mémoire très faible, pas de requis d'un serveur, interface C++ très simple, rapide. A priori, il n'est pas recommandé pour une base de données partagée en réseau. Je l'utilise pour une application depuis 3 ans en réseau avec une cinquantaine d'utilisateurs. Pas un seul problème lié à la base de données. Il présente, certes, des faiblesses (comparé à MS SQL) mais le fait de ne pas avoir besoin d'un serveur a été un élément décisif du choix. Installation hyper-simple: copier la Db sur un disque réseau et c'est parti !

[korntex5]

My sweet honey Firebird...
Mais dites moi il est pas un peu orienté ce sondage?
Parce que ne pas lister des SGBD aussi connues et usitées dans le monde, c'est bizaroide non?

[ecor6633]

J'ai voté postgresql parce que pour apprendre le SQL il est vraiment parfait et complet. PgAdmin3 livré avec est très facile à utiliser, il permet les trigger et stored procedures et a de bonnes performances.

J'ai aussi choisi autre pour H2 ou HSQL très léger et pratique aussi pour de l'embarqué ou pour un apprentissage et bien plus agréables que derby.

[masivelo]

Bonjour,

J'opterai pour deux : PostgreSQL et FireBird :
- PostgreSQL est de loin celui que je prefère avec un ensemble riche de fonctonnalités : héritage, PL. etc.

- FireBird est très facile à utiliser coté administratif et offre pas mal de fonctionnalités que MySQL n'en a pas !!

Salutations.

[nycolas]

Firebird !

[mmollon]

Firebird

[jean-pol]

Firebird

My sweet honey Firebird...
Mais dites moi il est pas un peu orienté ce sondage?
Parce que ne pas lister des SGBD aussi connus et usités dans le monde, c'est bizaroide non?

+1

[alassanediakite]

My sweet honey Firebird...
Mais dites moi il est pas un peu orienté ce sondage?
Parce que ne pas lister des SGBD aussi connues et usitées dans le monde, c'est bizaroide non?

+1
Je trouve qu'il y a lieu d'ajouter explicitement Oracle XE et Firebird, vue le nombre de votants.
@+

[tomlev]

En tous cas ce sondage aura eu le mérite d'attirer l'attention sur la popularité de Firebird (bien qu'il ne soit pas dans les choix proposés). Perso je connaissais de nom mais je ne savais pas qu'il était aussi largement utilisé...

[CinePhil]

Perso je connaissais de nom mais je ne savais pas qu'il était aussi largement utilisé...

Idem.

[jmarsac]

PostgreSQL en client/serveur (multiposte)
SQLite en desktop (monoposte) ou "transparente"
- libre
- SQL
- couche spatiale (PostGIS et SpatiaLite)

[pcourant]

PostgreSql c'est Stonebraker, mais avant il a fait Ingres, qui contrôle encore aujourd'hui les TGV et les contrôleurs de la SNCF, la Banque Barclays, et 10 000 autres sites dans le monde.

Pourquoi le discrédit sur une base qui a encore aujourd'hui tant d'années d'avance sur MySql, ou même Firebird (la base autoadministrée du génial Borland).Et qui est désormais disponible en version OpenSource.

Et pourquoi oublier son environnement associé, OpenRoad, totalement objet, qui la valorise encore, en permettant de réaliser en 200 lignes ce qui demande 2500 lignes de Javascript, et au moins 1500 de php ou de java ...

Aujourd'hui Ingres c'est Actian, (ingres version10), mais aussi Vectorwise, la base de données la plus rapide du monde ... (mais elle n'est pas OpenSource)

NoSql, c'est comme le cloud, une épée de Damoclès. Je n'y crois pas. La technologie est trop floue, trop opportuniste. Seules les bases Hash de Facebook me paraissent une véritable innovation (quoique l'on connaisse le hash-coding depuis le premier disque des Rolling Stones)

Si les médias faisaient un peu plus de technique et un peu moins de commerce, on serait mieux renseigné ... (mais merci à développez.com, site exceptionnel).

Et bonne année à tous.

[sevyc64]

Pourquoi le discrédit sur une base qui a encore aujourd'hui tant d'années d'avance sur MySql,

Ou as-tu vu que PostgreSQL était discrédité ? Ici ?

NoSql, c'est comme le cloud, une épée de Damoclès. Je n'y crois pas. La technologie est trop floue, trop opportuniste.

LE principe de NoSQL, ça fait juste plus de 10 ans que Google, entre-autre, ainsi que bon nombre de société manipulant ce que l'on appelle maintenant les Big Data, l'utilise pour ses indexations.

NoSQL est, à l'heure actuelle, le seul mécanisme pas trop mal adapté pour gérer les big data et le volume important de données totalement hétéroclites. Le coté relationnel des SGBD classiques SQL n'est pas du tout adapté, par le fait qu'il nécessite que les données soient typées et surtout toutes de même type, qu'il y a besoin d'une relation entre les données.

Il est fort à parier qu'à terme, des moteurs NoSQL seront adaptés et intégrés aux gros SGBD actuel, Oracle, SQLServer, MySQL, Postgre, etc...

[Frank Mesnard]

Firebird pour sa pleine gratuité. On peut l'inclure dans un logicel "desktop" (sans serveur) et vendre ce logiciel sans frais....dommage qu'il n'y a pas beaucoup de sites d'hebergement qui offre Firebird...

[Théo0303]

Bonjour,

Pour ma part, je dois dire que cela dépend de l'utilisation. En embarqué SQLite, en mode online, voire même offline MySql

Théo.

[Jester]

Greenplum un fork EMC de PostgreSQL pour les data warehouses où PostgreSQL aurait du mal, sinon PostgreSQL.

Accessoirement H2 et MySQL pour des besoins spécifiques.

[SurferIX]

Pour ce qui me concerne c'est MySQL étant donné que mes projets sont des projets web à 80% pour le reste j'ai pas mal lu sur NoSQL avec MongoDB, et PostgreSQL reste à découvrir pour plus de robustesse tout en restant Open

Le jour où tu poussera à peine la machine MySQL tu verras quelles sont toutes les lacunes inadmissibles de ce moteur de bd.

Premier exemple concret (et inadmissible) : déclaration d'un trigger lors d'un update, et ce trigger fait un "insert" dans la même table.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
DELIMITER ;;
 
DROP TRIGGER IF EXISTS produit_trigger_update_before;
 
CREATE TRIGGER produit_trigger_update_before
BEFORE UPDATE ON produit
  FOR EACH ROW BEGIN
    /* */
    INSERT INTO produit SET 
      id_origine      = OLD.id_origine,
      date_v_creation = OLD.date_v_creation,
      date_v_start    = OLD.date_v_debut,
      date_v_end      = NOW(),
      ...
      last_record     = OLD.last_record;
 
    /* Dependancies : */
    SET @last=LAST_INSERT_ID();
    UPDATE categorie_produit SET id_produit=@last
    WHERE id_produit = OLD.id;
    UPDATE produit_attribut SET id_produit=@last
    WHERE id_produit = OLD.id;
  END;;
 
DELIMITER ;;

Impossible de toucher à la table concernée lors du déclenchement d'un trigger :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
mysql> update produit set importance=3;
ERROR 1442 (HY000): Can't update table 'produit' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.
mysql> Bye

MySQL a détruit tout un principe sur lequel j'ai basé une grosse partie de ma base de données (= archivage automatique des enregistrements) parce qu'il ne peut pas faire ça, et j'ai dû faire un hack horrible, tout en développement au lieu d'utiliser le moteur de bd, qui, si il avait fait ça, aurait non seulement économisé du temps de développement, mais aussi des sources de problèmes, et (pire) de la vitesse d'exécution (parce que maintenant mon code doit faire une table temporaire pour tout copier avant d'archiver) .
Bien sûr, tout vrai moteur de bd digne de ce nom fait ça de base : PostGreSQL fait ça depuis longtemps (cf ici).

Sans parler du manque chronique d'optimisation des requêtes, comme on le cite...

Bref pour résumer, MySQL n'est bien que pour des petits sites Web mais faut surtout pas pousser un peu la machine sinon on se casse vite les dents, et si on veut du lourd et du long terme, penser "PostGreSQL".

[Waldar]

Votre cas n'a rien d'inadmissible et n'est pas propre à MySQL, sur Oracle vous ne pourriez pas le faire non plus, sujet débattu ici :
http://www.developpez.net/forums/d11...tion-triggers/

Les SGBD ne gérant pas les données de la même façon, ils ont chacun leurs spécificités, la modification d'une table déjà en cours de modification en faisant partie.

Maintenant, si je regarde le code de votre trigger, c'est vraiment pas terrible.
Vous changez le nom d'un produit, donc vous en recréez un nouveau (qui contient les anciennes valeurs) et vous mettez à jour tous les id dans toutes les tables filles. N'ayez pas trop d'utilisateurs en simultané car ça ne supportera pas de montée en charge.

[SurferIX]

Maintenant, si je regarde le code de votre trigger, c'est vraiment pas terrible.
Vous changez le nom d'un produit, donc vous en recréez un nouveau (qui contient les anciennes valeurs) et vous mettez à jour tous les id dans toutes les tables filles. N'ayez pas trop d'utilisateurs en simultané car ça ne supportera pas de montée en charge.

Euh non, au contraire, je ne mets pas du tout à jour tous les id dans toutes les tables filles, je "duplique" l'enregistrement en cours pour me souvenir de son état... Et je valide la modification sans rien faire d'autre. Mon but étant d'historiser les changements. Il y aurait des milliers de façon de se souvenir d'un changement dans un enregistrement avant de le modifier (enregistrer uniquement l'id, le champ modifié et l'ancienne valeur par exemple etc.). Mais je cherchais une façon facile de pouvoir ressortir l'historique d'un enregistrement donné. Et vous avez tout à fait raison : je ne suis pas du tout spécialiste SQL et mon code ne doit pas être terrible... mais il fonctionne et le code écrire pour ressortir l'historique d'un enregistrement est minime. Bref, une fonctionnalité très pratique qui fait cruellement défaut à MySQL.

J'ai aussi oublié une chose : j'ai l'impression que MySQL a été racheté par Oracle non pas pour rentabiliser la chose, mais pour ralentir son développement qui commençait, à mon avis, justement, à titiller la poule aux oeufs d'or qu'est le moteur de bd Oracle, et pour pouvoir être mieux étouffé. D'ailleurs il n'y a qu'à voir la vitesse avec laquelle les nouveautés sont créées sur MariaDB et comparer avec les nouveautés sur MySQL... la communauté de MariaDB non seulement a le temps de backporter les nouveautés de MySQL dans MariaDB, mais en plus d'en faire d'autres et d'optimiser les requêtes (cf tableau comparatif simplement des optimisations ici).

Bref, même si mon discours n'est pas "parfait", je me permets de le redire : MySQL oui, mais pas pour de gros projets.

[Luc84]

Bonjour,

j'utilise (et donc je vote) Firebird : utilisée depuis 9 ans, pas de bug, pas de plantage. Que demande le peuple ?