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
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
address@hidden
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: address@hidden
Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------
|
regis_houssin.vcf