Le non sens est plutôt de confondre Base de données et base de données relationnelles.
Par exemple, pour stocker les pages d'un wiki, utiliser postgresql me semble être une hérésie. Ceci étant dit, j'adore PostgreSQL pour sa puissance fonctionnelle ; mais ce n'est pas appliqué à tout type d'application ; tout dépend des besoins, des contraintes.
Je vais prendre un exemple concret, d'expérience. Au boulot, on gère des bases de données de blob de plusieurs millions d'entrées avec mots-clés associés. On doit tout charger en mémoire sur des applis spécifiques. On utilise des bases Postgresql pour gérer les bases de données "référence" (ie celles qui garantissent la qualité et la cohérence des données de nos clients) parce que c'est lié à notre système d'information et parce qu'on a besoin de gérer des requêtes complexes, des procédures stockées, etc ; mais les serveurs qui manipulent les données en question les chargent via des fichiers SQLite (on les convertit entre temps) parce que d'un point de vue performances au chargement, il n'y a pas photo. Pour tous les outils internes "courants" (bugzilla, wiki, etc) on utilise MySQL parce que ça ne nécessite pas d'administration courante (c'est plus autonome qu'une base PostgreSQL). Et pour la gestion du code source, on utilise CVS qui est aussi une base de données à part entière (et qui est basée sur des fichiers) (notez: CVS est obsolète, je dis pas le contraire, mais ça marche bien:).
Typiquement pour les outils de gestion de version, si les bases de données relationnelles étaient la poule aux oeufs d'or, on n'aurait plus de systèmes "non SQL".
C'est comme si on disait : "par pitié, parler de PHP ou Python comme un langage de programmation est un non sens". Ne pas admettre qu'à des besoins différents les meilleures solutions sont différentes, ça oui, c'est un non sens à mon avis.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: pitié ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 10.
Par exemple, pour stocker les pages d'un wiki, utiliser postgresql me semble être une hérésie. Ceci étant dit, j'adore PostgreSQL pour sa puissance fonctionnelle ; mais ce n'est pas appliqué à tout type d'application ; tout dépend des besoins, des contraintes.
Je vais prendre un exemple concret, d'expérience. Au boulot, on gère des bases de données de blob de plusieurs millions d'entrées avec mots-clés associés. On doit tout charger en mémoire sur des applis spécifiques. On utilise des bases Postgresql pour gérer les bases de données "référence" (ie celles qui garantissent la qualité et la cohérence des données de nos clients) parce que c'est lié à notre système d'information et parce qu'on a besoin de gérer des requêtes complexes, des procédures stockées, etc ; mais les serveurs qui manipulent les données en question les chargent via des fichiers SQLite (on les convertit entre temps) parce que d'un point de vue performances au chargement, il n'y a pas photo. Pour tous les outils internes "courants" (bugzilla, wiki, etc) on utilise MySQL parce que ça ne nécessite pas d'administration courante (c'est plus autonome qu'une base PostgreSQL). Et pour la gestion du code source, on utilise CVS qui est aussi une base de données à part entière (et qui est basée sur des fichiers) (notez: CVS est obsolète, je dis pas le contraire, mais ça marche bien:).
Typiquement pour les outils de gestion de version, si les bases de données relationnelles étaient la poule aux oeufs d'or, on n'aurait plus de systèmes "non SQL".
C'est comme si on disait : "par pitié, parler de PHP ou Python comme un langage de programmation est un non sens". Ne pas admettre qu'à des besoins différents les meilleures solutions sont différentes, ça oui, c'est un non sens à mon avis.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo