Discussion :

[Ceddoc]

J'avoue ne pas avoir lu toutes les interventions mais j'aurais besoin d'aide au choix d'un SGBD pour une application à naître. Voilà les principaux critères:

-Multiplateforme: l'OS du serveur de BDD n'a pas encore été décidé, mais ce peut être windows comme linux et l'idéal serait que les deux soient possibles.
-Compatible Java: La base va être exploitée en Java comme langage de prédilection il faudrait donc que la compatibilité soit optimale.
-Autres langages: Si on peut aussi attaquer la base en php ce serait bien.
-Volumétrie: A priori le nombre d'enregistrement devrait être moyen, mais il y aurait une historisation assez conséquente et donc à terme un volume assez important.
-Accès simultanés: à priori pas de contrainte à ce niveaux, jamais plus de 30 connexions simultanées. (Et encore 30 serait un record ultime)
-Simplicité d'administration: nous ne disposons pas d'un administrateur de BD confirmé, il faut donc que ce soit assez facile d'accès et bien documenté.
-Prix: Il faut rester raisonnable et bien sûr au moins cher c'est au mieux c'est mais je pense pouvoir convaincre l'utilisateur d'acheter une licence si nécessaire.
-Sauvegardes: il faut pouvoir sauvegarder facilement mais si il faut stopper la base, elle ne sera pas accédée h24 donc ça ne pose pas problème

Quelques pistes? Conseils? Avis?

[CinePhil]

Vite fait : Postgresql me semble un bon choix qui répond à tous vos critères.

[Bluedeep]

Bonjour

On va procéder par élimination de haut en bas.

J
-Multiplateforme: l'OS du serveur de BDD n'a pas encore été décidé, mais ce peut être windows comme linux et l'idéal serait que les deux soient possibles.

On élimine donc Sql Server. Reste donc Oracle, PostGreSql, MySql (dans les solutions "non exotiques").

-Compatible Java: La base va être exploitée en Java comme langage de prédilection il faudrait donc que la compatibilité soit optimale.

Pas d'élimination sur ce critère.

-Autres langages: Si on peut aussi attaquer la base en php ce serait bien.

Idem.Pas d'élimination sur ce critère, même si MySql est mieux intégré avec Php (mais qu'avec php).

-Volumétrie: A priori le nombre d'enregistrement devrait être moyen, mais il y aurait une historisation assez conséquente et donc à terme un volume assez important.

Désolé, mais cela ne veut strictement rien dire. Il faudrait un chiffre. Qu'appelle tu un volume important ? 100 Go, 1 To, 10 To ?

-Accès simultanés: à priori pas de contrainte à ce niveaux, jamais plus de 30 connexions simultanées. (Et encore 30 serait un record ultime)

Toutes bases possibles.

-Simplicité d'administration: nous ne disposons pas d'un administrateur de BD confirmé, il faut donc que ce soit assez facile d'accès et bien documenté.

Un net désavantage pour Oracle sur ce critère. Le mieux de ce point de vue est Sql Server mais éliminé sur un autre critère.

-Prix: Il faut rester raisonnable et bien sûr au moins cher c'est au mieux c'est mais je pense pouvoir convaincre l'utilisateur d'acheter une licence si nécessaire.

Oracle est cher. PostGre et MySql à peu près gratuit (moins vrai pour MySql car sa pauvreté fonctionnelle fait qu'on est souvent obligé d'ajouter des modules payant). Oracle Express est gratuit mais là il faudrait avoir une volumétrie précise.

-Sauvegardes: il faut pouvoir sauvegarder facilement mais si il faut stopper la base, elle ne sera pas accédée h24 donc ça ne pose pas problème

Toutes bases possibles.

Quelques pistes? Conseils? Avis?

Avantage PostGreSql visiblement.

[Ceddoc]

Pour le volume je ne peux pas encore savoir, les estimations seraient trop hasardeuses, mais ça confirme ce que je pensais on s'orienterait plus sur du PostGre ou du MySql.

Avec un léger avantage pour PostGreSql a priori? Pourquoi pas.

Je vous remercie de vos conseils!

[Bluedeep]

Pour le volume je ne peux pas encore savoir, les estimations seraient trop hasardeuses, mais ça confirme ce que je pensais on s'orienterait plus sur du PostGre ou du MySql.

Là il faut voir au niveau des foncionnalités. MySql est très pauvre.

[Ceddoc]

Quels type de fonctionnalités pourraient faire le différence? J'avoue que j'ai un peu de mal à voir, quelques exemples?

[Bluedeep]

Quels type de fonctionnalités pourraient faire le différence? J'avoue que j'ai un peu de mal à voir, quelques exemples?

As tu besoin de réplication par exemple ou d'utiliser un ETL, etc ... ?

Par ailleurs le SQL de MySql est assez limité (pas de support des expressions de tables récursives, par exemple, pas de fonctions statistiques, etc ...), ce qui oblige à déléguer au code client des fonctions devant relever normalement du SGBD.

De plus, certaines fonctionnalités impose le changement de moteur de base (Clustering par exemple qui impose NDB, ce qui implique d'autres contraintes tel que la non utilisation d'index "full text", etc .... ).

[Waldar]

Vous pouvez lire l'article à charges de SQLPro :
http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

[Jester]

PostgreSQL sur windows ce n'est pas une bonne idée. Postgresql génère pas mal de fragmentation sur NTFS et au fur et à mesure les perfs s'éffondrent par les accès disques, du moins avec des requêtes analytiques (générant des fichiers temporaires importants et beaucoup de lectures séquentielles). Il faut défragmenter ce qui impose un arrêt de la base. Cela apparait même sur des disque relativement vide.

[Ceddoc]

Merci de vos infos,

Je viens de lire la critique de mysql et le manque de certaines fonctionnalités ne me dérangent pas plus que ça, je n'ai jamais entendu parler de la plupart et comme nous n'avons pas d'administrateur BD confirmer je doute qu'elles soient utilisées.

Ce qui me fait le plus peur c'est cette perte de performances lors de la mises en concurrence. Est-elle vraiment significative, la ressent on avec des requêtes "classiques" (Select de 5000 lignes, inserts et updates) venant d'une dizaine de clients?

Pour PostGre, Cette histoire de fragmentation sur du NTFS me fait un peu peur aussi, il y a des chances que le serveur BD soit sous windows et je n'aimerais pas que ça pourrisse les disques.

[Jester]

Le problème de concurrency semble avoir été pas mal résolu dans la version 5.5.

Pour la fragmentation, je remets que c'est sur un cas particulier assez intensif.