après il ne faut pas faire d'amalgame avec cassandra, couchdb, mongodb, etc..
Le 03/10/11 21:46, Cyrille de Lambert a écrit : > Oui mais le mode NoSQL est inadapté à la liaison entre éléments > (client <-> commande <-> facture) > Dans ces cas, les performances seront fortement dégradées et beaucoup > moins bonnes qu'en SQL. > Par contre, ça peut-être bien pour la partie GED de Dolibarr. > Les jointures sont très performantes lorsqu'elles sont bien faites. > > > Le 03/10/2011 20:18, Régis Houssin a écrit : >> ce n'est pas tant que pour les performances, quoi que nous avons de plus >> en plus de grosses structures qui s'intéressent à dolibarr, et qui dit >> grosse structure dit forcément beaucoup d'enregistrement, et les >> jointures c'est l'horreur. >> mais aussi pour faciliter l'ajout de fonctionnalité. >> >> pour expliquer le principe: >> >> dans MongoDB un document est un objet (client, produit, facture) >> tout ce qui concerne cette objet est stocké dans le document. >> les tables et les champs sont créés au fur à mesure des besoins. >> si un module externe ou une fonctionnalité de personnalisation veux >> rajouter des éléments dans un object il le fait dans cette objet, pas >> besoin de créer d'autres table avec jointure (gain de performance) >> >> pour le moment je suis en train de revoir la structure des données et je >> vais faire des tests. >> quoi qu'il en soit si c'est positif je ne pourrais pas inclure ceci dans >> le projet actuel, trop de différence de schéma >> cette version sera un fork... >> >> >> Le 03/10/11 19:18, Laurent Destailleur (eldy) a écrit : >>> On 01/10/2011 20:08, Cyrille de Lambert wrote: >>>> 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 >>> Je plusois. >>> >>> Le NoSQL est concu pour les base de très gros volumes (disons au dela >>> de 100 Go). Loin de la cible de dolibarr. >>> De plus il n'est pas du tout adapté a une application de gestion >>> métier transactionnelle, par essence meme. >>> Il est concu par définition meme, conçu pour les autres cas (plutot le >>> stockage de flux ou de message de réseau sociaux par exemple). >>> >>> Meme si les avantages pour dolibarr me semble plus faible que les >>> contraintes que cela amene et que donc je n'y crois pas trop, >>> l'experience peu etre tres "fun". >>> Tiens nous au courant. >>> >> 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 Cordialement, -- Régis Houssin --------------------------------------------------------- Cap-Networks 30, quai de Verdun 71700 Tournus FRANCE VoIP: +33 1 83 62 40 03 GSM: +33 6 33 02 07 97 Web: http://www.cap-networks.com/ Email: [email protected] Dolibarr developer: [email protected] Web Portal: http://www.dolibarr.fr/ SaaS offers: http://www.dolibox.fr/ Shop: http://www.dolistore.com/ Development platform: https://doliforge.org/ ---------------------------------------------------------
<<attachment: regis_houssin.vcf>>
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
