Le 2 oct. 2011 à 19:43, Cyrille de Lambert <address@hidden> a écrit :
OpenERP est trop lord pour pas mal d'entreprise. Très coûteux à
mettre en place pour des petites PME/TPE.
Dolibarr représente un atout important, tant en terme d’ergonomie
qu'en terme de performances.
Par contre, il manque des atouts importants pour les entreprises :
Règles de prix impossibles à utiliser en masse
Produits déclinables inexistants
Export non filtrables
etc ...
Ça fait partie des thèmes sur lesquels on dois bosser et qui me
semblent plus urgents que les aspects purement techniques.
C'est le fonctionnel qui attire l'utilisateur final.
Le 02/10/2011 10:28, olivier geffroy a écrit :
Nous étions en offre saas "openerp online" pour un
client et je suis extrêmement déçu à la fois par ce projet
"open-source" et la société Openerp
Il manquait a dolibarr pour ce client :
module compta
Ce module fobctione très bien mais il faut configurer le plan
comptable
module POS
Exacte. Comme sur Dolibarr, l'idéal est d'intégrer OpenBravo POS.
Nous avons déjà fais une intégration OpenERP/OpenBravo POS. Nous le
faisons dès que nous pouvons avec Dolibarr.
Hors ces modules existent sous Openerp mais sont loin,
très loin d'être fonctionnels
Le 2 octobre 2011 10:07, Cyrille de Lambert <address@hidden>
a écrit :
Nous avons plusieurs
implémentations OpenERP et il est vrai que cette application
rame très rapidement.
Ce n'est pas un problème de base (relationnelle PostgresSQL)
mais plutôt de framework qui est très consommateur en
ressource.
C'est une application qui ne donne pas satisfaction sur
l'aspect perfs. Ça commence à peiner avec 3 utilisateurs,
même en faisant des efforts d'indexation importants.
Le 02/10/2011 09:29, olivier geffroy a écrit :
Il est clair que ces
technologies consomment beaucoup plus de ressources,
ce qui n'est pas très grave vu la montée en puissance
des serveurs et la virtualisation
Le gros problème chez Openerp était la non utilisation
de cette puissance (pour résumé que ce soit sur un
céleron ou sur un octoprocesseur, l'erp tourne de la
même façon)
En utilisant une base de donnée postgres (optimisé
régulièrement pour les requêtes) et un système
virtualisé sous proxmox (avec un serveur de donnée, un
serveur apache ....) cela devrai améliorer les
performances.
Le 2 octobre 2011 09:13,
Régis Houssin <address@hidden>
a écrit :
Nous avons des clients avec une base de
30000 produits et c'est tout aussi
catastrophique avec le fonctionnement actuel
de Dolibarr
Le 2 oct. 2011 à 09:01, olivier geffroy <address@hidden> 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 <address@hidden>
a écrit :
Le 2 oct. 2011 à 01:04,
Cyrille de Lambert <address@hidden>
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/MongoDBhttp://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,