Au contraire c'est plus rapide avec les gros volumes de données Plusieurs gros projets l'utilise dont sugarcrm dans sa version saas
----------------------------------------- Régis Houssin Tél. +33633020797 http://www.dolibarr.fr http://www.dolibox.fr Le 2 oct. 2011 à 01:04, Cyrille de Lambert <[email protected]> a écrit : > Ce type de sujet revient régulièrement dans différents projets techniques. > Il y a 7 ans, on nous prédisait la mort du SQL au profit des bases XML qui > reprennent les avantages que tu décris hormis le fait de ne pas avoir besoin > de décrire ses documents. > Ce que j'en ai vu : > Performances catastrophiques pour des gros volumes de donnée > Pas très adapté à des applications métier. > Pour faire les tests, il faut le faire sur des dizaines de milliers > d'enregistrements en base sur une machine standard. > En effet, ce type de techno est très consommateur. > Je ne pense pas que ce soit mature pour l'instant. > > Cyrille > > Le 01/10/2011 21:48, Régis Houssin a écrit : >> >> au contraire, pas de jointure, un "document" contient toutes les >> informations >> un champ n'est créé que si il est renseigné >> de plus un module externe n'a pas besoin de créer ces propres tables >> pour rajouter des champs dans une fiche produit, il suffit qu'il rajoute >> ces enregistrement dans la fiche produit et le champ est créé >> automatiquement dans le "document" >> (un document est un enregistrement dans mongoDB, un document = une fiche >> produit par exemple) >> plus besoin d'avoir tout un tas de table avec jointure ! >> en natif tu peux modifier un champ seul, plus besoin de créer tout un >> tas de fonction et de requête php pour modifier un champ >> la sortie est au format json ou array, plus besoin de traitement, tu >> peux utiliser les données directement avec du jquery par exemple, >> (datatables !!) >> >> de toute façon je vais faire des tests et je mettrais une démo en ligne >> >> >> Le 01/10/11 20:08, Cyrille de Lambert a écrit : >>> Salut Régis, >>> >>> Je trouve que c'est un mauvaise idée pour une question de performance. >>> Je ne pense pas qu'un projet comme NoSQL soit conçu pour des systèmes >>> de gestion mais plutôt pour des outils de GED. >>> >>> Cyrille >>> >>> >>> >>> Le 01/10/2011 18:49, Régis Houssin a écrit : >>>> Bonjour, >>>> >>>> afin de mieux gérer les modules externes, la personnalisation des fiches >>>> ou des listes je suis en train de réfléchir à une méthode différente de >>>> stockage des données et je me penche actuellement sur le NoSQL >>>> >>>> http://fr.wikipedia.org/wiki/NoSQL >>>> >>>> et plus particulièrement à MongoDB >>>> >>>> http://fr.wikipedia.org/wiki/MongoDB >>>> http://lacantine.ubicast.eu/channels/mongofr/ >>>> >>>> Nous allons faire des tests sur un fork de Dolibarr tout en gardant une >>>> synchronisation entre les projets >>>> >>>> Si des développeurs ayant des connaissances en MongoDB ou très motivés >>>> par cette technologie sont intéressés pour participer à ce projet, merci >>>> de me contacter je vous associerai au projet Doliforge. >>>> >>>> Ce projet reste encore un test et n'a pas encore la vocation de >>>> remplacer la version actuelle ! >>>> >>>> Cordialement, >>> >> >> Cordialement, > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
