Discussion :

[doppler]

Bonjour à toutes et tous,

L'association pour laquelle je travaille prépare un festival assez... dingue...
Nous avons besoin de gérer une base de donnée aussi folle que le projet, à savoir:
Nous avons des centaines d'artistes référencés, ils peuvent être plasticiens, musiciens, théâtreux etc...
Chaque catégorie peut être redivisée selon des dizaines de facteurs (précision du style artistique, localité, degré d'adhésion à l'assos etc...)

Nous voulons pouvoir filtrer notre listing selon n'importe quelle combinaison de critères (recherches croisées je crois...) et appliquer des actions au résultat du filtrage (envoyer des mails, créer de nouvelles fiches incluant d'office les mêmes critères...)

Pour l'instant nous bossons avec une simple base MySQL qui est raide comme la justice, quel systèmes et outils super flexibles nous conseillez vous ?
Quelques facteurs qui peuvent vous aider à mieux nous cerner...
- Une vingtaine d'utilisateurs accederont à la base via une interface en ligne
- La solution sera hébergée, sans doute par infomaniak ou ovh
- La base devra supporter à terme "quelques" milliers de fiches
- Nos moyens économiques sont très bas


D'avance, merci (énormément) pour votre aide !

[Manuk]

Pour l'instant nous bossons avec une simple base MySQL qui est raide comme la justice, quel systèmes et outils super flexibles nous conseillez vous ?

Mysql est une très bonne base de données qui peut résister à des charges bien supérieures à celle de ton projet

- Une vingtaine d'utilisateurs accederont à la base via une interface en ligne
- La base devra supporter à terme "quelques" milliers de fiches
- Nos moyens économiques sont très bas

Toutes les conditions sont réunies pour utiliser MySQL

Si tu trouve que MySQL est trop "lent" (rigide ?), je crois que tu devrais repenser le design des tables et les relations entre les tables.
Bien souvent un mauvais design ou des requetes peu optimisées peuvent faire exploser la charge de travail de la base et augmenter le temps de réponse.

Courage

[Marc Lussac]

1) si tu es hébergé en mutualisé tu ne va pas avoir grand choix pour le SGBD, ca sera sans doute imposé par l'hébergeur, et ca sera sans doute MySQL avec en option PostGreSQL.

2) A te lire je n'ai pas du tout l'impression que tu bute sur un vrai problême SGBD mais bel et bien sur un problême de manque d'éxpérience en SGBD et en développement.

C'est un grand classique, les non professionels arrivent à se débrouiler avec word, voir avec Excel, mais dès qu'ils arrivent su rles SGBD la c'est la catastrophe

Pour etre développeurs SGBD et faire des analyses correctes c'est plusieurs années d'études.

En clair ca ne sert à rien de "maudire" ton SGBD ou de changer son SGBD, le problême ne viens pas du tout du SGBD. Ton problême est parfaitement fesable avec MySQL si tant est que tu définisse la bonne structure de base et les bons algos dans l'application.