Choix de SGDB pour stockage de données médicales

[jane40]

Bonjour à tous,

Je ne suis pas une spécialiste des bases de données, j'ai eu des cours de SQL et j'ai un peu utilisé MySQL. Je viens de commencer ma thèse dans un labo de biologie et je dois créer une base de données pour conserver les données recueillies jusqu'à présent (400 patients) et intégrer ceux qui viendront. J'ai besoin d'aide pour déterminer les outils adéquats à mon problème. J'ai parcouru la partie "Comparatif, quel SGDB choisir?", mais je n'ai pas trouvé ce que je recherche.

J'ai vu que certains SGDB sont plus ou moins adaptés suivant le nombre de données et le nombre d'utilisateurs. La leucémie qui m'intéresse étant rare, je n'aurai pas des millions d'enregistrements. Donc je peux déjà éliminer certaines bases. Je pense qu'il n'y aura pas plus de 20/30 utilisateurs.

Voici les premières spécifications :
1) Le premier critère que j'ai est qu'il me faut un outil facile d'utilisation car il sera utilisé par des biologistes. Il ne faut pas qu'ils aient à écrire de lignes de commandes. Il me faut donc un outil graphique.

2) La base sera utilisée par des médecins, des techniciens, ... qui ne devront pas pouvoir modifier les mêmes informations.

3) Certains champs (comme le stockage d'échantillons) doivent absolument être remplis. Il faudra que je créé une alerte (ou autre, je ne sais pas encore) si l'utilisateur cherche à se déconnecter sans avoir modifier/valider ces infos. Ceci est peut-être faisable avec tous les SGBD...

Connaissez-vous des outils qui me permettraient de concilier tous ces besoins ?

Merci d'avance,
Jane

[StringBuilder]

Vu la demande, et le niveau technique visiblement faible, Access aurait été une bonne solution.
Mais la possibilité d'avoir 20/30 personnes en simultané dessus, ça va pas le faire.

Il reste donc une solution avec MySQL, SQL Server Express par exemple, et un front-end développé en C#, Java ou PHP (par exemple) mais il faudra faire intervenir soir une société tierce, soit un développeur un minimum expérimenté : c'est un peu chaud de confier la conception et la réalisation à la fois d'un modèle de base de données et d'une application client à une même personne, surtout si elle est débutante dans les deux domaines.

[jane40]

Merci pour la réponse.

20/30 personnes, c'est un maximum. Il y a environ 7/8 personnes dans le labo qui peuvent faire des modifications. J'imagine que d'autres personnes peuvent vouloir s'y connecter pour voir des infos, mais ils ne devront rien modifier.

De mon côté, je n'ai pas un gros niveau en BD, mais je n'ai pas de contrainte de temps. Je peux prendre plusieurs semaines pour la faire donc ça ne me dérange pas de me pencher dessus. Je peux de plus avoir de l'aide de la part du service informatique. Le but c'est de faire quelque chose de stable, de maintenable et facilement utilisable pour les utilisateurs, même si ça doit me demander pas mal de boulot.

[StringBuilder]

Il faut différencier "gestion de base de données" et "saisie des données".

Mise à part quelques suites telles que Access, la plupart des SGBD ne font que le rôle de "gestion de base de données" (c'est d'ailleurs ce que veux dire le sigle "SGBD").

La saisie des données doit donc se faire dans un outils tiers la plupart du temps (un site web, un client lourd, etc.)

Pour la consultation, idem, il existe des outils qui ne sont généralement pas intégrés au SGBD pour pouvoir les consulter (site web, excel, business object, etc.)

L'interface de saisie des données (et de consultation) est de loin le plus difficile et le plus long à écrire/recetter.

La conception de la base de données en elle-même, même avec un modèle un peu complexe, ne dure généralement que quelques heures (enfin, pour ce genre de projets, on ne parle pas ici d'un gros système). La création de l'interface, elle, est bien plus longue et nécessite beaucoup de travail.

En effet, contrairement à la conception de la base de données, la création de l'interface nécessite de "pisser du code", sans forcément une grande valeur ajoutée, mais beaucoup de travail (d'où ma suggestion d'Access, qui permet de s'affranchir de cet aspect)

[skuatamad]

Il y a aussi Oracle 11GR2 XE (gratuit) qui vient avec l'utilitaire APEX, qui permet de développer une application web sans faire trop de code (un peu à la access).

[SQLpro]

Oui, mais la limitation d'Oracle est quand même très retreignante en comparaison à d'autres SGBDR !

http://blog.developpez.com/sqlpro/p1...le-sql-server/

A +

[Waldar]

Un petit bémol, la traduction d'une base SQL-Server c'est un schéma chez Oracle (les notions de schéma / user étant proches), il n'y a pas de limite notable sur ce nombre chez Oracle non plus.

[SQLpro]

Envoyé par Waldar

Un petit bémol, la traduction d'une base SQL-Server c'est un schéma chez Oracle (les notions de schéma / user étant proches), il n'y a pas de limite notable sur ce nombre chez Oracle non plus.

Là je pense que vous confondez avec MySQL !!!!!!!

SQL Server c'est un truc de Microsoft, qui implémente des bases normatives avec les SCHEMA SQL depuis l'origine... (en fait SQL Server c'est un produit Sybase né en 1986...)

Il n'y a que MySSL qui ne sait toujours pas ce qu'est un schéma SQL et fait croire que c'est la même chose qu'une base de données.

Vous feriez bien de réviser un petit peu votre savoir avant d'affirmer des grossièretés pareilles ! ;-)

A +

[Waldar]

Je ne critique pas SQL-Server, je dis que les pratiques n'est sont pas les mêmes chez les deux éditeurs.

Après vérification, les schémas SQL-Server et Oracle sont bien les mêmes, c'est leur utilisation qui diffère.

Avec Oracle Database, on installe par machine une seule instance (ça fait partie des recommandations de l'éditeur), et le plus souvent une seule base.
Si plusieurs applications utilisent cette base, elles vont être déployées sur des schémas différents.

Avec Microsoft SQL-Server, on va installer une ou plusieurs instances, qui vont chacune faire tourner plusieurs bases, les applications vont se scinder sur ces bases différentes.
Par contre, dans 100% des cas que j'ai croisé - ce qui ne reflète que ma maigre expérience - le seul schéma utilisé est dbo.

Les pratiques ne sont pas les mêmes dans les deux mondes, et limiter la version XE de Oracle à 1 instance / 1 database n'est en aucun cas gênant, rien n'empêche de faire tourner parfaitement 150 petites applications avec.

[SQLpro]

La différence est quand même énorme : oracle est limité à 11 Go parce que 1 seule base, là ou SQL Server est limité à 320 To en version Express (32 000 bases de 10 Go).

Entre les deux, y'a une petite différence ou je me trompe encore ???

Et sur la notion de schéma SQL aucune différence d'aucune sorte. Oracle et SQL Server sont à 100 % conforme à la norme.

A +

[Waldar]

Oui, bien vu pour le coup des Go !

[skuatamad]

Envoyé par SQLpro

Entre les deux, y'a une petite différence ou je me trompe encore ???

Boh une broutille en même temps qui irait stocker 320 To sur une base express

[SQLpro]

Envoyé par skuatamad

Boh une broutille en même temps qui irait stocker 320 To sur une base express

Bien joué, Perrier !!!!
Il faudrait être fou..... (-;

A +

[xelab]

Envoyé par jane40

Voici les premières spécifications :
1) Le premier critère que j'ai est qu'il me faut un outil facile d'utilisation car il sera utilisé par des biologistes. Il ne faut pas qu'ils aient à écrire de lignes de commandes. Il me faut donc un outil graphique.

2) La base sera utilisée par des médecins, des techniciens, ... qui ne devront pas pouvoir modifier les mêmes informations.

3) Certains champs (comme le stockage d'échantillons) doivent absolument être remplis. Il faudra que je créé une alerte (ou autre, je ne sais pas encore) si l'utilisateur cherche à se déconnecter sans avoir modifier/valider ces infos. Ceci est peut-être faisable avec tous les SGBD...

Connaissez-vous des outils qui me permettraient de concilier tous ces besoins ?

Merci d'avance,
Jane

On peut connecter OpenOffice Base (ou LibreOffice) à MySQL il me semble. Je n'ai jamais essayé mais cela pourrait peut-être répondre au besoin...

Edit: Et aussi ça (pas testé non plus):
http://kexi-project.org -> apparemment ça fait parti du projet Koffice maintenant, donc plutôt à utiliser sous Linux.

[jane40]

Merci pour vos réponses !
Je n'ai pas encore choisi, je me concentre sur le modèle relationnel et mes données pour le moment.
Autre piste dont on m'a parlé : lims

[SQLpro]

Un LIMS est un outil qui intègre la partie cliente et un éventuel SGBDR ! C'est une application spécialisée pour les labos d'analyse (pas spécialement médicale).

A +

[Bluedeep]

Envoyé par jane40

Bonjour à tous,

Je ne suis pas une spécialiste des bases de données, j'ai eu des cours de SQL et j'ai un peu utilisé MySQL. Je viens de commencer ma thèse dans un labo de biologie et je dois créer une base de données pour conserver les données recueillies jusqu'à présent (400 patients) et intégrer ceux qui viendront. J'ai besoin d'aide pour déterminer les outils adéquats à mon problème. J'ai parcouru la partie "Comparatif, quel SGDB choisir?", mais je n'ai pas trouvé ce que je recherche.

Vous pouvez aussi jeter un oeil chez AGILAB, voir si ils n'ont pas quelque chose pouvant vous convenir (par contre, comme techno c'est Oracle + APEX).

[jane40]

Bonjour,

Finalement, je pense m'orienter vers MySQL. Je ferai ça sous linux, je ne sais pas encore quelle distribution mais certainement Fedora ou Ubuntu.

Voici les étapes que je pense suivre.
1) Construire un modèle relationnel (avec Dia par exemple). Validation avec certaines personnes de l'équipe.
2) Créer la base de données (MySQL). Tests pour vérifier que tout est bien fait.
3) Définir les droits d'accès pour les différents groupes d'utilisateurs) (MySQL). Tests.
4) Chargement des données (qui sont contenues dans des fichiers excel) (MySQL)
5) Faire l'interface en Php pour que les biologistes puissent ensuite entrer des données eux-mêmes.

Qu'en pensez-vous ?

Est-il possible de commencer sans être tout de suite hébergé sur un serveur de base de données ? Vaut-il mieux y être dès le début ? Ou faut-il transférer la base une fois qu'elle est prête ?

[SQLpro]

Bon choix... MySQL est le plus mauvais des SGBDR !
A lire : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[xelab]

Envoyé par SQLpro

Bon choix... MySQL est le plus mauvais des SGBDR !
A lire : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

En même temps pour jane40 il n'y a pas d'impératif de performances et la quantité de données sera limitée et en plus elle connaît déjà MySQL...