Quel SGBD pour mon outil sous windev ?

[Davboc]

Bonjour

Je suis étudiant en dernière année d'école d'ingénieur, et j'ai pour projet de réaliser pour une entreprise un outil de traçabilité sous windev.

Basiquement c'est un outil de gestion/interrogation de base de données accessible depuis un peu partout en France (Hopitaux, Cliniques), et la base de données sera assez grosses et amenée à grossir et grossir puisqu'on devra théoriquement y stocker des données pendant 150 à 200 ans.
Par ailleurs j'aurai besoin de nombreuses connexions simultanées. Bien que la boite soit petite et ne compte pas encore de nombreux clients, elle est amenée à grossir et on risque d'arriver un jour à un très grand nombre de connexions simultanées (disons 1000 pour donner un chiffre).

Les postes clients seront en grande majorité sous windows, et les serveurs aussi, mais vu la diversité des clients il faut se préparer à ce qu'ils ne soient pas sous windows (bien que ça ne soit à mon avis pas un problème car il y a des chances qu'on fasse une appli web)

Ce que je voudrais surtout savoir, c'est quel SGBD vous me conseilleriez de choisir.
Je connais MySQL, mais j'imagine que ses performances ne seront pas suffisantes pour une telle application. HyperFile ? Selon le site de WinDev il en est capable, mais en même temps leur avis est pas super objectif...

Oracle ? Ms SQL ? J'avoue que pour le moment je suis plutot attiré par MS SQL, par sa relative similitude avec MySQL et sa facilité de prise en main par rapport à Oracle, même si je ne suis pas un grand fan des produits Microsoft...

Merci pour vos conseils !

David

[zooro]

Bonjour,

Moi je choisirais plutôt PostgreSQL. Ses fonctionnalités approchent celles d'Oracle, il est gratuit, et il me semble qu'il en existe maintenant une version native pour Windows.

[Davboc]

Merci de ta réponse.

PostgreSQL est il performant avec une grosse base de données comme la mienne ?

Je vais faire quelques recherches à ce sujet

Merci

[zooro]

Oui, il s'en sort bien avec les gros volumes de données.

Il y a une page qui en parle, mais je n'arrive plus à mettre la main dessus.
Sinon, tu peux commencer par là :
http://www.postgresql.org/about/users

[Davboc]

http://fadace.developpez.com/sgbdcmp/#PostgreSQL

Je lis le contraire ici... A moins que ce comparatif soit obsolète ?

Sinon QUID d'Interbase ? Je viens de lire le topic interbase vs sqlserver mais il date de 3 ans déjà...

Il serait peut être plus adapté à une grosse charge non ?

[zooro]

PostgreSQL est utilisé pour géré les noms de domaines .org...
http://www.postgresql.org/about/news.123

[Davboc]

Ah d'accord ^^

Mais je vois qu'il n'y a pas d'accès natif vers PostgreSQL sous windev... Est-ce que ça ne va pas nous poser des problèmes ?

[zooro]

Pas spécialement: tu peux toujours passer par ODBC.

[Davboc]

Je sais bien, mais est ce que ça n'engendre pas trop de complications ?

J'ai un schema sous les yeux avec les differents types de fichiers accessibles par windev, et la couche ODBC est reliée directement alors que pour tous les autres SGBD il y a une couche UDC (Universal Data Connector), cela implique t'il que je ne pourrai pas utiliser le w-langage pour faire des requetes sur une base Postgres ?

[zooro]

Envoyé par Davboc

cela implique t'il que je ne pourrai pas utiliser le w-langage pour faire des requetes sur une base Postgres?

Apparemment, tu ne pourras pas, en effet.

[Xo]

Salut,

Les SGBD les plus robustes sont sans conteste SQL Server et Oracle, mais quel que soit ton choix, il est certain que la manière dont est configuré/administré le SGBD, ainsi que la conception de la BDD joueront pour beaucoup dans les performances.

Envoyé par Davboc

puisqu'on devra théoriquement y stocker des données pendant 150 à 200 ans.

Moui, bon, là, je ne sais pas qui t'a fait cette demande farfelue, je sais bien qu'il subsite des logiciels écrit en Cobol aujourd'hui, mais les technologies de l'informatique étant ce qu'elles sont (évolutions constantes & co), je pense que la durée de vie d'un logiciel, aussi robuste et puissant soit-il, aura du mal à excéder 10-15 ans ...

[vmolines]

Je me suis fait la même remarque mais je pense qu'il y a méprise due à une mauvaise formulation du "pendant 150-200".

Peut être s'agit il de données d'archives qui peuvent remonter jusqu'à 150ans, auquel cas le SGBD aura à supporter des données datées sur une plage de 200ans mais pas tourner pendant 200ans.

D'ailleurs je paierais bien pour savoir ce que sera l'informatique dans 200ans...

[vtrone]

Envoyé par Davboc

J'avoue que pour le moment je suis plutot attiré par MS SQL, par sa relative similitude avec MySQL et sa facilité de prise en main par rapport à Oracle, même si je ne suis pas un grand fan des produits Microsoft...

La similitude est plus que relative... Elle est même inexistante je pense.

1. As-tu déjà fait un schéma conceptuel et un schéma interne de ta base ?
2. As-tu estimé la taille approximative de tes données à terme ? 200 ans de données peuvent être très petits aussi... Il faut la calculer.
3. Où sera stockée ta base ? En local ? Sur un SAN ?
4. Quelle sera la proportion de consultation / mise à jour de ta base ?

Ces points peuvent t'aider à choisir le SGBD. Ton budget aussi.

[Davboc]

Merci pour vos réponses.

Je parlais de 150/200 ans car il s'agit d'un outil de traçabilité d'agrafes à memoire de forme posées sur des patients.. 150 à 200 ans c'est large, mais par exemple il faut savoir retrouver sur une mamie de 90 ans une agrafe posée quand elle avait 3 ans...

Pour ce qui est du budget, il faut que j'en discute avec le client le projet vient d'être lancé je ne sais pas s'il préfère un SGBD open source sans assistance technique ou un payant avec assistance technique...
Pour l'instant la base se limiterait à 4-5 tables maximum et la proportion de mises à jours/consultations dépassera sans doute les 50% (plus de mises à jour que de consultations) car il faudra pour chaque étape de la vie d'une agrafe modifier un champ.. Alors que les consultations seront moins fréquentes en théorie.

Quand à la taille des tables... C'est difficile à dire disons que pour chaque agrafe il y aurai une 30aine de champs (majoritairement des champs texte) et que le nombre d'agrafe ne fera qu'augmenter... (900 à l'heure actuelle alors que l'entreprise n'a pas un an)

J'essaierai de vous apporter plus de précisions plus tard je dois aller en cours ^^

Merci

La base sera interrogeable depuis n'importe ou en France (pour l'instant du moins) donc elle aura sans nul doute son propre serveur.

[Davboc]

Bon ben fin de l'histoire apparemment je vais être obligé d'utiliser Hyperfile C/S...

Vive l'enfermement dans le propriétaire... Qu'en pensez-vous ? On va dans le mur ou ça passera ?

[Emmanuel Lecoester]

Rien ne t'empeche de démarrer tes développements en HF C/S et de migrer par la suite vers un autre SGBD du marché.

[makowski]

Envoyé par Davboc

Pour ce qui est du budget, il faut que j'en discute avec le client le projet vient d'être lancé je ne sais pas s'il préfère un SGBD open source sans assistance technique ou un payant avec assistance technique...

open source avec assistance technique ça existe

et bien bon courage avec HF

[Davboc]

Merci de votre soutien

on va bien voir c'que ça donne

[zooro]

Envoyé par makowski

et bien bon courage avec HF

Ce qui me manquait le plus la dernière (et unique, j'espère) fois que j'ai utilisé HF, c'était les transactions. Enfin, ils ont bien un machin qu'ils nomment "transaction", mais j'ai eu du mal à ne pas m'étouffer en en constatant l'effet

Enfin bon, HF n'est pas un "vrai" SGBD (je ne parle pas de la version C/S que je ne connais pas). Si l'on considère les critères "Atomicité, Consistance, Isolation, Durabilité":
- atomicité et isolation: pas de transaction, donc...
- consistance: le minimum syndical
- durabilité: bon, effectivement, ce point là fonctionne.

[petit arbre]

bahhh il paraît qu'ils gérent des bases de 10 milliards d'enregistrement sur HF.
J'ai vu une démo en ce sens à Paris, maintenant : du volume et une masse d'utilisateurs simultanés je demande à voir !!!