On 02/10/2011 09:13, Régis Houssin wrote:
Nous avons des clients avec une base de 30000 produits et c'est tout aussi catastrophique avec le fonctionnement actuel de Dolibarr

Cela ne devrait pas. Il faut identifier la requete sql qui pose pb et me l'indiquer. Je l'optimiserais. A 30 000 produits (soit rien du tout), les temps de réponses devraient etre immédiat. Ce n'est pas un pb de SQL ou noSQL mais de conception ou requetage.

Donne moi les requetes SQL qui trainent (il suffit d'activer l'option slow_query de mysql avec un délai de 3 secondes comme seuil pour identifier toutes celles qui dure plus de 3 secondes) et envoi les moi. Je corrigerais le code en conséquence.


-----------------------------------------
Régis Houssin
Tél. +33633020797
http://www.dolibarr.fr
http://www.dolibox.fr

Le 2 oct. 2011 à 09:01, olivier geffroy <[email protected] <mailto:[email protected]>> a écrit :

Bonjour,

Je suis d'accord avec cyrille, je sors d'une implantation d'openerp qui fonctionne sur ce modèle et les performances sur de gros volumes (40 000 clients) sont catastrophiques

Par contre pour les utilisateurs et les codeurs c'est beaucoup plus souples, mais personnellement ce que j'apprécie dans mon dolibarr et ce depuis 6 ans c est la rapidité et la simplicité du produit.



Le 2 octobre 2011 07:52, Régis Houssin <[email protected] <mailto:[email protected]>> a écrit :

    Quoi qu'il en soit ça reste un test :-)


    -----------------------------------------
    Régis Houssin
    Tél. +33633020797 <tel:%2B33633020797>
    http://www.dolibarr.fr
    http://www.dolibox.fr

    Le 2 oct. 2011 à 01:04, Cyrille de Lambert
    <[email protected]
    <mailto:[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] <mailto:[email protected]>
    https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

    _______________________________________________
    Dolibarr-dev mailing list
    [email protected] <mailto:[email protected]>
    https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




--
Olivier GEFFROY
JEFFINFO Sarl

Tel : 06 08 63 27 40
Mail : [email protected] <mailto:[email protected]>
_______________________________________________
Dolibarr-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: [email protected]
Web: http://www.destailleur.fr

Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: [email protected]
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: [email protected]
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

Répondre à