Choix de version

Bonjour,

Etant nouveau sur ce forum, il me semble important de me présenter rapidement. Je travaille dans l'analyse de données dans la biologie, plus précisément sur l'abeille domestique depuis peu. J'ai donc une formation statistique et une maitrise très correcte du logiciel R. Je ne suis pas des métiers de la programmation, mais la chose ne m’effarouche pas. J'ai par le passé créé une application de traitement de données, assez rudimentaire, sous tcl/tk (implémenté dans R par un package), juste pour dire que ça me plait suffisamment pour partir la fleur au fusil.

Actuellement, il y a un besoin, dans l'association où je travaille, de créer une base de données relative à des analyses toxicologiques menées sur les abeilles. Je voudrai donc créer cette base, dans un premier temps à partir de rien puisqu'il n'est pas prévu d'intégrer les analyses passées. Cette base doit pouvoir être renseignée en ligne sur notre site par les différents partenaires professionnels que nous comptons. Aucune requête ne sera permise de leur part pour l'accès aux données pour des raisons de confidentialité, sauf peut être pour réédition en cas d'erreur de saisie, donc avec un droit d'accès partiel. Les différentes recherches réalisées sur google et consorts m'incitent à m'intéresser au tandem MySql & php (le coté open source m'a beaucoup séduit). Je vais d'abord chercher à créer la BDD et l'interface de saisie avant de travailler sur la mise en ligne. D'après ce que j'ai pu voir sur le site officiel de MySQL et sur les FAQ de ce forum, je dois donc installer ceci : http://dev.mysql.com/downloads/windows/installer/ pour la BDD et PHPMyAdmin pour plus tard mettre en ligne. Vu la multiplicité des outils (workbench, connector, for excel etc...) je voulais juste savoir si j'aurais tout ce qui me faut après cette installation pour faire ce que je dois faire, ou bien si il y a d'autres éléments dont je n'ai pas connaissance et que je dois impérativement prendre en compte.

On verra la partie php plus tard, une chose à la fois, mais je ne veux pas travailler inutilement avec une impossibilité de faire cette dernière étape en agissant mal au début. Au passage, je compte apprendre avec le manuel officiel du site de MySQL mais tout lien particulièrement pédagogique et bien fait m'intéresse.

Merci de votre attention et, d'avance, pour vos réponses.
Bien cordialement.
Alex

bonjour,

On ne choisit pas un SGBD parce-que l'option nous "séduit" mais parce-que ces fonctionnalités correspondent au besoin.

Faites un tour sur le forum "décision sgbd" et décrivez un peu mieux ces axes :
- volume (en Go) estimé (vous avez un historique, vous pouvez surement extrapoler même si sans modélisation ca peut changer)
- type d'utilisation (relationnelle, OLAP, ...)
- concurrence / charge utilisateur
- complexité des opérations au niveau de la base (la sans modélisation ca va être dur de répondre)
- j'en oubli ?

Bonjour et merci pour la réponse,

C'est typiquement pour ces raisons que j'ai voulu poster cette question avant de commencer. C'est-à-dire que je pars de zéro, donc potentiellement il y a beaucoup de choses à prendre en compte dont j'ignore tout. Au moins ai-je conscience de ce point là! Pour recentrer un peu le sujet, finalement j'ai besoin de conceptualiser cette BDD et savoir si je peux y répondre par moi-même (donc à l'aide d'un logiciel libre, c'est pour ça que je me suis tourné vers l'open source, mais effectivement je ne sais pas si les fonctionnalité MySQL sont adaptées). Peut-être que cette discussion aurait plus sa place dans le forum "décision sgbd", en ce cas n'hésitez pas à m'indiquer la marche à suivre pour faire migrer le sujet.

Point par point :
-l'historique en question ne m'est pas accessible actuellement et ne pourrai de toute façon conduire qu'à une estimation erronée. De ce que j'ai vu, les résultats envoyés par les labos le sont sous fichier excel sans architecture harmonique du tableau (cellules fusionnées fourre-tout, pas de cohérence dans les colonnes, format différents selon les labos etc...). Difficile donc de chiffrer en volume. C'est également pour ces raisons que l'on voudrai imposer les champs de saisie, typiquement par une interface à menu déroulant, mais je suis ouvert à toutes propositions, le but étant de forcer le format pour harmonisation. Globalement, la forme du tableau final comptera de nombreuses colonnes : une dizaine pour identifier le prélèvement, potentiellement des centaines pour les composés analysés car pour chacun il faut savoir s'il a été recherché, les limites de détection, et la quantification. Toutefois on partira de zéro et je ne pense pas que la taille de la BDD augmentera très vite, mais je fais peut-être des plans sur la comète. Au passage, quelles sont les contraintes imposées par la taille?

- Relationnelle si j'ai bien compris. Je vois bien un tableau unique et dont les requêtes ne seraient que de simples agrégations selon différents paramètres. On peux également imaginer un "tableau" par laboratoire avec les composés qu'ils sont en capacité d'analyser (variable d'un labo à l'autre). Il a été question de pouvoir réaliser rapidement des calculs simples du type : fréquence d'occurence ou recherche d'un composé dans l'ensemble des données implémentées. Etant en mesure de le faire sous R après requête, si ça complique, on oublie, je coderai un script regroupant ces opérations.

- Peu d'utilisateurs à prévoir, une dizaine qui correspond à des partenaires régionaux censés centraliser les données de leur région. Pas de concurrence logiquement puisqu'il n'y aura que de la saisie isolée, donc chaque nouvelle donnée implémente la base sans problème d'accès/écriture simultanée. Les requêtes ne seront faites que par nos soins pour les problèmes de confidentialité évoquées dans mon premier post.

-D'après ce que j'ai décris ce seront plutôt des opérations simples j'imagine.

J'espère avoir été assez complet pour cerner le problème.

Merci infiniment d'avoir pris le temps de me répondre.
Cordialement.
Alex

Citation:

---

Envoyé par Minided

- Relationnelle si j'ai bien compris. Je vois bien un tableau unique et dont les requêtes ne seraient que de simples agrégations selon différents paramètres. On peux également imaginer un "tableau" par laboratoire avec les composés qu'ils sont en capacité d'analyser (variable d'un labo à l'autre). Il a été question de pouvoir réaliser rapidement des calculs simples du type : fréquence d'occurence ou recherche d'un composé dans l'ensemble des données implémentées. Etant en mesure de le faire sous R après requête, si ça complique, on oublie, je coderai un script regroupant ces opérations.

---

Il n'y a pas de tableau dans une base de donnée.
Des tables oui et la conception de celles-ci différent grandement par rapport à un classeur xls.

Allez dans ce forum pour la partie modélisation : http://www.developpez.net/forums/f62...sation/schema/

http://Au passage, quelles sont les ...par la taille?

Au delà de 100go (voir même avant) je proscrirais les sgbd openSource.

Pour quelques raisons simple :
- mauvaise gestion du partitionnement
- pas de sauvegarde incrémentale
- Pour Mysql l'optimiseur trop simpliste qui ne fera pas tourner correctement les requêtes.
- Certaines fonctionnalité niveau indexation / vue non présente
- et y en a d'autre.


MySql n'est pas un très bon SGBD, mais qui peu suffire selon le projet.

Son optimiseur est à la ramasse totale (des que l'on sort des jointure simple tout à tendance à devenir lent), ces fonctionnalités limités par rapport à la norme sql.

Vous avez postGresql en libre qui est globalement de meilleur facture.

Sinon il y a aussi la version gratuite de SqlServeur que vous pourrez utilisez sur une appli commerciale (y a du bridage)


De mon point de vue, je vous recommanderai de faire la modélisation de la base.
Une fois ceci fait vous pourrez estimez la volumétrie de votre base.

Si celle-ci fait moins de 1-2go prenez le sgbd que vous voulez, sinon tournez vous vers postgresql / sqlserver

Bonjour,

Merci pour les liens! Effectivement je me suis rendu compte que je ne sais en fait pas du tout ce qu'est une base de données, seulement des pré-jugés et lieux communs. J'avais commencé à feuilleter ce forum "schéma", mais si vous avez un abc (du style "les bases de données pour les nuls" :) ) ou disons un document bien didactique pour commencer, je suis preneur. Sinon ce pdf m'a l'air d'être un bon début : http://www.info.univ-angers.fr/~gh/internet/cbd.pdf (cours de l'université d'Angers).

Merci aussi pour les informations diverses et, surtout, pour ne pas m'avoir envoyé bouler sur la base de mon ignorance :)

Cordialement