Bonjour,
je compte maintenant me lancer serieusement (Ms2 v2 derniere version j espere) mais avant je voudrais m assurer sur la fiabilite de la base de données de oscommerce.

J ai deja lu sur 2 ou 3 sujets differents (ici même) parlant de la lenteur d affichage des pages et dont la conclusion etait la non optimisation de la bdd de oscommerce.

J essayerai de retrouver au moins un sujet en question pour soutenir mon argument, surtout celui ou Mateo je crois ou un autre modererateur tres actif du forum avait confirmé ce probleme (bdd oscom non optimisée).

Ma question est de savoir :

1/ Est ce vraie ?

2/ Son impacte est il tres visible (genant) ?

3/ A partir de quel moment son impact se ressent ? en nombre de connexions simultannées ou en quantités de donnes dans la base.

4/ En quoi consiste cette non optimisitation ? niveau structurel ou niveau requette vers la bdd, ou autre ?

5/ Et pour finir, Avez-vous connu se probleme vous aussi ? si oui, comment l avez-vous resolu (l optimisation en question)

Merci infiniment pour vos reponses sans oublier toute la communauté de développeurs benevols.

A tres bientôt !

Voici un lien sur un sujet sur la lenteur d affichage des pages causee par la non optimisation de la bdd
http://www.oscommerce-fr.info/forum/index....mp;#entry342071

Bien sur qu'on peut optimiser la bdd. Mais ça devient une affaire de puriste, pas forcément géniale question gain.
La bdd osCommerce est assez bien faite et les jointures pas mal optimisées déjà. On peut sûrement mieux faire.

Coté requêtes, elles sont aussi assez bien conçues même si certaines mériteraient d'être carrément supprimées pour accélérer les pages.
C'est vrai qu'il existes dans certaines pages des requêtes dont on peut se passer ou alléger. Mais là encore c'est affaire de puriste!

En l'état, osCommerce peut gérer des milliers d'articles et si tu utilises le système de cache intégré, le nombre de requêtes par page diminue considérablement avec la mise en cache de la construction du catalogue.

A noter qu'une boutique peut tourner sans problème sur un hébergement mutualisé (un vrai, pas un truc de base de chez OVH) avec un gros catalogue et encaisser jusqu'à 50 à 60 clients simultanés en pointe. Si on rapporte ça au nombre de visiteurs par jour ça doit faire à peu près entre 5.000 à 6.000 visiteurs/jour : c'est vraiment top!

Le risque de ralentissement des pages pourrait alors venir du poids des pages.
Mais coté BDD, si le serveur de bdd n'est pas trop lent, ça peut passer.
Cela dit, avec une telle fréquentation, un serveur dédié est souhaitable voire indispensable.
Mais si on ramène ce chiffre de fréquentation en CA avec un taux de transformation de 1% (c'est bas) et un panier moyen à 50€ (c'est aussi très bas) ça donne environ 2500 € de ca/jour! Tu dois pouvoir te payer un gros dédié avec ce chiffre! d'autant que si ton site est bien fait, tu dois pouvoir espérer 4 fois plus (transformation à 2% et panier à 90€)

Allez, revenons à des chiffres plus réalistes : une fréquentation de 2000 visiteurs/jour (c'est un bon site marchand déjà) peut amener des pointes à 20 clients simultanés mais en moyenne tu auras entre 5 et 10 clients simultanés.
Là, pas de problème sur un mutualisé bien dimensionné, même si aux heures de pointe ça risque de trainer un peu.

C'est pas tant la bdd que le poids de tes pages qu'il faudra optimiser.
D'ailleurs le post que tu donnes en lien parle justement de cette optimisation et pas d'optimisation de la base.

Je tombe sur ce topic par hasard, et, rhaaââa :

Je sais tu vas me dire que je suis toujours aussi rebel, mais tu te permets d'aller à l'encontre de tes precéptes de modération !

Donc en bref : juger et qualifier un fournisseur d'hébergement

En effet toujours aussi ...
"Cochon qui s'en dédie" affirme le dicton!
Mais aucune dérive par rapport à des préceptes de modération!

Il convient de savoir qu'un hébergement "de base" chez OVH risque de présenter des lenteurs très perceptibles pour une boutique en ligne ou tout autre site dynamique.
Cela ne signifie pas qu'OVH ne soit pas en mesure de proposer des formules adaptées. Mais il faudra prendre une taille suffisante.

Pour compléter, je me suis livré à un petit test de rapidité d'exécution de scripts sur différents types d'hébergement :
Une boucle de calcul assez simple (incrément à quelques centaines de milliers d'occurrences)
sur ma machine : un Intel Quad à 3Ghz sous Vista 64 le script met 2.8 secondes. (assez stable même après 10 tests successifs)
Testé sur plusieurs formules d'hébergement chez OVH ou ailleurs j'ai obtenu des résultats allant de 2.4 secondes à 23 secondes.
Ce type de test n'ayant aucune validité sur l'ensemble des capacités d'un hébergement je ne donnerais pas plus de détails sur qui donne quoi.
Toutefois le rapport est de 1 à 10 sur la vitesse d'exécution (variable d'ailleurs pour le pire entre 18 et plus de 30 secondes) cela donne une indication sur la charge du serveur. J'avais d'ailleurs commencé avec une boucle bien plus longue qui passait au delà des 30 secondes sur la plupart des serveur j'ai donc réduit pour ne pas être timeout.
Il convient de savoir que la grande majorité des mutualisés de bon niveau sont dans un mouchoir autour des 3 secondes (y compris les dédiés milieu de gamme) .
Mais dès qu'on descend en gamme, patatras! En réalité, je pense que le test que j'ai envoyé devrait donner des résultats variables de 2 à 5 secondes (un écart à 2.5 pour 1) selon le type de machine et de processeur (mais sur les gros mutualisés, c'est généralement musclé de ce coté). Des temps au delà de 6 secondes signalent simplement un partage excessif des ressources.

Donc point de devoir de réserve en ce qui concerne les capacités d'un hébergement mutualisé, juste un devoir de conseil à partir d'un avis éclairé.

Bonsoir cher ami.
Merci pour ton intervention. Mais je ne vois pas trop pourquoi il aurait fallut privilégier le fanatisme a la vérité !

Au contraire, je dirai qu un bon mederateur c est celui qui est sincere. De plus, il n a pas dit que toutes les formules d hergement d ovh ne sont pas fait pour ce genre de besoin mais seulement les plus bas. C est ce qu on appel du entrée de gamme : conseillé pour les sites perso, sites de présentation rapide d une société, association, etc avec des pages web, en grande partie statiques et/ou ayant très peu de visites/jr.

Et ca, c est normal car même les hébergeurs eux même le savent que quand il s agit d un site pouvant générer environ 10 connexion simultanées (donc environ 2000 visites/jr comme l a dit l admin), ils conseillent de passer aux offres plus sérieuses. ce n est d ailleurs pas par hasard qu il ya plusieurs offres d hébergement chez ovh.

Bref, mais je suis étonné de voir que tu prennes un peu mal le faite que quelqu'un nous dise la vérité. Et ce qui est bizarre c est que tu as l air de savoir que c est la verite mais par principe de fanatisme tu aurais prefere qu il ne nous dise pas ca.

A ta place, je le dirai merci. Car avant tout, nous sommes sur un forum : une plate-forme d entre aide. Et si l on privilégie le mensonge juste pour garantir son amitié avec ovh ou pour des une simple raison de fanatisme, a quoi servirai ce forum ? mieux encore, a quoi ca sert d être modérateur ?

J espère que tu prendra pas mal cela mais je privilégie l esprit d équipe donc l esprit du forum = le partage sincère.

Bonsoir grand maitre
Merci infiniment pour ton secours et ta disponibilité.

A propos des test, je trouve ca très motivant de voir quelqu'un qui prends le temps de faire tout ca juste pour mieux nous aider et nous apporter des arguments solides basés sur les faits et par ce qu il a lui aussi entendu dire.
Vraiment merci pour tout.

Par contre, je suis d accord que tu ne publies pas les résultats détaillées /hébergeurs mais peut tu nous communiquer au moins le nombre exact en approximatif de la boucle en question ? histoire de se faire une idée globale des performances d un bon mutualisé ou dédié milieu de gamme (3 secondes en moyenne).

Merci encore pour ton assistance.

Il ne faudrait pas que ça vire au troll dans ce post,
j'ai étayé mes propos pour répondre à telede.
En ce qui concerne le script de test, je ne communique pas pour 2 raisons :
1/ ça n'a pas valeur de benchmark
2/ si tout le monde se met à envoyer ce genre de script sur son hébergement, ça risque de mettre en vrac un certain nombre de sites sans raison valable. (occupation CPU inutile sur un mutualisé)
Chacun peut se livrer à ce genre de test, selon sa propre méthode et avec ses propres scripts, mais je le déconseille fortement.

Ca me rassure enormement puisque je me demandais deja s il fallait refaire cette base ... Ta reponse est claire.



Quand tu dis : < carrément supprimées pour accélérer les pages >, c est dans le cas ou l on veut se passer d un fonctionnalité (une boxe quelconque par exemple) ou bien c est vraiment supprimer la requête sans supprimer une fonctionnalité (je dirai donc : amélioration de la raquette) ?

Quelles requêtes par exemple peu tu prendre en exemples ?




Je ne sais pas si la liste sera longue mais j aurai bien voulu les connaitre. C est vrai que suis aussi un peu puriste, mais même si le gain ne sera pas considérable, ce qui m intéresserait c est de bien connaitre cet outils (oscommerce) car je veux travailler sérieusement et je me dis que c est toujours mieux de savoir, ca pourrait peut-être me permettre de comprendre d autres choses demain et etre capable moi aussi de pouvoir d aider d autres personnes a la communauté. J ai envie de devenir autonome sur Oscommerce, c est pour ca que ca m intéresserait quand même de connaitre ces pages. Je lourai peut-etre les découvrir moi même, mais c est toujours mieux de profiter des expériences de ceux qui sont déjà passer par la et surtout, ceux qui ont déjà réussi.




C est claire, rien a dire, C est un pur concentré de bonheur : Tres rassurant



Dans le message 7 de son post, il dit ceci :
< bonjour,
merci pour tes conseil chti_poupon, mais g réussi a résoudre mon problème, en fait j'ai optimiser ma bdd , ca a enlever les pertes et tout marche comme avant voir mieux !!!! >

lien http://www.oscommerce-fr.info/forum/index....st&p=342268

Par contre je me demande pourquoi il dit : < ... tout marche comme avant ... > cela sous entend que la lenteur a commencé après qu il ait fait quelque chose (bidouiller le code ou simplement ajouter beaucoup de données dans la base).

Pour être sûr, je vais lui poser la question directement pour qu il nous confirme la cible de son intervention (page ou base ?) et éventuellement ce qu il a modifié.

En tout cas, merci d avoir prêté attention a mes questions et merci d avance pour les reponses.

A bientôt !

Effectivement, ce n est pas le but, loin de la.
Parcontre, quand j ai comencee a rependre a telede, ta reponse n etait pas encore la. j etait surpris de voir que tu avais repondu pendant que j ecrivais. Une idee m est d ailleurs venu en tete, celle de modifiee mon post en ecrivant ecrivant complement quelque chose qui n aurait aucun rapport avec le post de telede mais je n ai pas trouve de bouton de redition pour modification, bref.




Je n ai pas du tout demande le script. Au contraire jai même dis que je soutenais ton idee de ne pas publier les résultats détaillés /hébergeurs. (même pensé pour le script).

Jai juste demande le nombre de boucle, juste par curiosité.

Ce n etait pas dans le but de refaire la même chose mais au contraire, je pense que les lecteurs de cette expérience n auraient même plus besoin de la refaire d eux même puisqu ils auraient deja su a peu près la vitesse d exécution d une simple boucle de x (avec x=5000 par exemple) dure en moyenne 3s sur un bon serveur mutualisé.

Je ne sais pas si je me suis mieux fais comprendre. Mais je n insiste pas non plus pour avoir ce nombre, c etait juste pour donner plus de precision a propos de ma demande.

Dans tout les cas, je respecte ton choix et je comprends.

Au plaisir !

de part sa généricité, oscommerce, dans sa version actuelle, n'est pas optimale.
d'autre part le script doit aussi bien fonctionner sur des hébergements partagés que dédiés, les choix de développement en sont donc limités.
la conséquence directe est une sous exploitation du sgbd qui lui est rattaché, en l’occurrence mysql.
aucune intégrité référenciel au sein de la base.
tout repose (ou presque) sur les épaules du client.

la prochaine version d'oscommerce corrigera quelques une de ces faiblesses.(entre autre, une mise en cache des requêtes ... un comble, quand on sait que mysql possède son propre système de cache de requètes à ne pas confondre avec le systeme de cache actuellement en place sur la version en cours)

Rapidement :
il existe en effet des requêtes qu'on peut alléger.
Si tu n'utilises pas les fabricants par exemple, tu peux éliminer les filtres par "manufacturers" voire supprimer les tables et les requêtes jointes.
Et en effet, certains blocs consomment des requêtes superflues : si tu ne veux pas les promos dans ta page par exemple, autant virer le bloc.
Voilà pour les bases. Il n'y a rien à enlever pour optimiser dans une utilisation standard. Après, consulte les posts dans nos forum. L'un reprends les travaux de notre regretté Chemo qui avait listé certains points d'optimisation coté scripts et requêtes.
Quand dans le post que tu cites, il parle d'optimiser sa bdd c'est optimiser les tables avec phpmyadmin
En effet, le serveur sql est optimisé pour accéder rapidement aux enregistrements. Il se rajoute alors des pointeurs sur les requêtes les plus fréquentes ce qui peut laisser un peu de désordre. Alors à la manière d'un disque dur, le stockage peut dans le temps se trouver fragmenté. Une optimisation remet alors les tables en ordre et élimines les pertes par pointeurs provisoires (je simplifie, mais c'est l'image). C'est la seule optimisation à faire!
Enfin, rapport à l'intervention de FoxP2, il est évident que le moteur sql n'est pas forcément le plus efficace ni exploité de manière la plus performante. Mais comme il le souligne, ça doit fonctionner partout y compris sur des serveurs aux capacités restreintes (pour faciliter le partage entre autres)
Toutefois, à moins de tout changer et de reprendre le développement très bas, il n'y a pas d'astuce géniale qui permettrai une optimisation radicale.

Quant à la boucle de calcul, il est question de faire le md5 d'un nombre de 1 à 3000000 et de comparer chacun au md5 de 3000000. Quand on arrive à l'égalité, on stoppe. Il y a donc plusieurs instructions dans la boucle (dont celle de marquage du chrono). ça n'est pas un bench et ne peut servir d'étalon. J'avais juste donné cette info pour souligner qu'un serveur mutualisé d'entrée de gamme est vraisemblablement très occupé par des milliers de sites en charge CPU et de surcroit, le serveur sql couplé (qui est généralement sur une autre machine) sera aussi à la limite. Or, cette boucle ne teste pas le serveur sql.

Enfin, pour les vagues initiées par Telede, laissons passer, c'est un vieil habitué ici (dont on regrette parfois le talent technique) qui aime bien la provoc, ce qui lui a valu quelques déboires

Bonjour cher ami et merci pour ton intervention.
A moins que je ne sache pas ce que c est que l intégrité référentielle, mais j estime que c est l ensemble des mécanismes automatiques qui permettent de garantir la cohérence entre données (champs) ayant une relation (directe). Ce mécanisme est par exemple l utilisation des clés étrangères.

Or je constate qu il y a pas mal de clés étrangères dans les tables. par exemple, la table qui sert de jonction entre les produits et catégories, nommées : products_to_categories.

On voit bien que qu elle contient 2 champs : products_id et categories_id qui sont des clés primaires des tables products et categories.
En plus, pour garantir l unicité de chaque éléments de ces 2 champs (et aussi accelerer la vitesse de recherche) dans cette table de jonction, ces 2 champs sont egalement déclarés en clés primaires.

Je pensais que cela suffirait pour mettre en place l intégrité référentielle de la relation (produits - catégories).

Peut-être quil faut en plus déclarer cette table (products_to_categories) en type InnoDB et non MyISAM qui ne reconnait pas les clés étrangères ?

Qu en penses-tu ?




A qui fais tu allusion, ici : le programmeur, qui doit faire lui même des test de validation lors de chaque mise a jour de la base (écriture d un script pour garantir l intégrité ref.) ou tu parles vraiment du client final (internaute) ?

Si c est du webmaster que tu parles, je me demande si il devrait vraiment fournir cet effort puisque je ne vois pas trop comment une erreur d incohérence pourrait subvenir car je me dis que oscommerce a du déjà assurer au moins, ce minimum de chose.

En exemple, losrqu on ajoute un nouveau produit (depuis la partie admin), on est oblige de choisir (sinon de créer une nouvelle) catégorie pour ce produit. Et donc logiquement, tant que le webmaster utilisera son espace admin pour gérer les produits/categories, (et non PhpMyAdmin) il ne devrait y avoir de problème d incompatibilité.
N hésitez surtout pas de me corriger si je me trompe.




Merci pour l information.
Toujours dans le cadre de l optimisation des performances (bdd et autres), je me demandais si ca valait le coup d activer le cache intégré au SGBD (mysql) lorsque le cache de oscommerce (celui du du serveur web je suppose) est déjà activé ?
Je trouve que ca ne servira a rien puisque le cache oscommerce conserve des pages (ou des bouts de pages) directement en html (statique) donc ces pages n auront plus besoin d envoyer des requêtes sql puisque le code html en cache serait déjà complet.

Dans ce cas, je ne vois pas l importance de créer un cache spécial sql (ou d activer celui du SGBD) sauf si l on veut soulager le serveur de bdd dans le cas ou l on ne veut pas activer le cache de page web).


Une question, juste par curiosité :
Le cache dont on parle (pas celui du sql), est t-il géré complètement par oscommerce ou plutôt par le serveur web ?

Merci encore pour votre aide

Je ne suis pas sur qu'InnoDB soit la solution au vu de l'architecture de la base. Ca risque même d'être un frein sur un mutualisé. InnoDB est gros consommateur de ressources il me semble, sauf si la base à été conçue pour son usage.
Enfin rien n'interdit de coupler le cache osc (qui élimine de fait des requêtes car il stocke des portions en html sur le disque) avec un cache sql s'il est accessible.
Et là encore, pas sur que cette option soit utilisable sur un mutualisé.

Je suis daccord sur son caractere gros consomateur de ressources (stockage, Ram et/ou processeur ? Et sous quelle proportion ? environ 1,5 , 2, 3 ou 4x plus que MyIsam ?).

Ok si on choisi de rester sur MyIsam, on reconnait donc que l intégrité référentielle n est pas garantie dans notre base. Sachant que c est une des fonctions qui ont révolutionnées le monde des SGBD et qu elle est capitale pour la bonne sante d une bdd, quelqu'un auraient des solutions alternatives pour éviter l incohérence des données dans la base ?
(comment assurer l intégrité ref. sans prise en compte des clés étrangères ?)



Ya til donc un moyen d utiliser InnoDB et ne pas consommer énormément de ressources ?



Merci mais je ne comprends toujours pas pourquoi utiliser le cache sql sachant le cache osc règle déjà le problème ?

merci encore a tous

Dans la théorie oui, mais le fonctionnement de la bdd osc ne présente pas de problème de fonctionnement ou de stabilité.


Pas vraiment, mais optimiser une architecture de bdd en fonction du moteur permet de gagner un peu mais surtout de ne pas perdre. Cela obligerai je pense à revoir tout l'ensemble tables/jointures/requêtes d'osc. Ce qui ne présente guère d'intérêt dans le but que tu poursuis (optimiser pour accélérer) puisque justement InnoDB n'accélèrera rien sur un serveur mutualisé. Cela pourrait se présenter autrement sur un dédié à condition que le serveur sql soit sur une machine dédiée. Dans ce cas, on pourrait utiliser toute la puissance du serveur sql. Mais il faudrait donc revoir l'architecture de la bdd car elle n'est pas vraiment optimale pour InnoDB. (voir pour cela les docs en ligne sur MySQL qui traitent de ce sujet)
Le cache osc règle le problème de certaines requêtes sur le catalogue qui sont répétitives en les supprimant pour les remplacer par une lecture de cache sur disque. Cela n'empêche pas de demander à sql de gérer les autres requêtes dans son propre cache. Il n'y a pas redondance puisque le cache osc désactive les requêtes qu'il gère.
Ensuite, tu pourrais aussi transférer certaines tables comme "configuration" sur disque et ainsi éliminer complètement une requête dans chaque page. Mais je ne sais pas quel serait le gain.
En somme, l'optimisation d'un site ne se résume pas à optimiser la bdd ou à éliminer des requêtes pour déplacer la charge vers le serveur web mais à optimiser la répartition des charges en fonction de l'architecture dont tu disposes.
En mutualisé on a généralement 2 serveurs : 1 pour le web 1 pour la bdd, chacun pouvant avoir des charges variées selon le système de partage de l'hébergeur.
En dédié, ces deux services peuvent se trouver sur la même machine.
Mais chez certains hébergeurs tu peux aussi mutualiser le web et prendre un serveur pour la bdd...

En l'état, comme le souligne FoxP2, la BDD de la version actuelle peut être améliorée et les prochaines versions vont dans ce sens. Mais la version actuelle ne mérite pas vraiment d'être le sujet d'une optimisation draconienne.

J aimerai savoir, toujours par curiosité, si on devrait remettre en question la structure globale de la base, notamment la définition des tables.
Pour être concret, je me demandais si quelqu'un a déjà pense que certaine tables actuellement présentes n avaient pas de raisons d y être et qu il aurait fallut les fusionner avec d autres pour tables des raisons que j ignore.

Je prendrais par exemple les tables :
- categories_description qui pouvait être fusionner avec la table < categories >
- manufacturers_info qui pouvait être fusionner avec < manufacturers >
- Idem pour les tables : products_description, products_options, products_attributes et products_to_categories qui pouvaient être carrément inclues dans la table < products >
- et ainsi de suite pour les autres tables.


Je souligne que cette architecture est ce qui serait la meilleure d après un ami diplômé en bases de données (6 mois de formation d administrateur de bdd). Mais personnellement, je ne suis pas d accord avec lui et je pense que la répartition actuelle des tables dans la base est très bien.

Je vous laisse nous départager, avec des arguments a l appuis bien sûr

Je rappel que pour lui, ses arguments sont : moins il y aura des tables (liées), moins il y aurait des contraintes et donc moins de consommation des ressources processeurs (du serveur sql). Son autre argument c est la simplicité des requêtes car plus besoin de faire des jointures puisque tout les champs seront cote a cote (dans la même table).

Et moi je le contredis en avançant les arguments suivants :

Argument 1 :
l architecture actuelle (segmentée) permet une bonne lisibilité et maintenance de la base facilite les sauvegardes (petite table = petite taille) en évitant les time out dû aux tables trop grosses par exemple.


Argument 2 :

Le faite de créer des tables dédiées permet d indexer ces champs sans consommer trop d espace disque. car 5 indexes sur 5 champs unitaires dans une même table contenant 25 champs au total, consommerait beaucoup plus d espace disque (x3 ou x4) que si l on fessait 5 tables (liées) et ayant 5 champs et un index chacune .

Je m explique :
Je part du principe où chaque index crée une image de la table a laquelle il est lié (avec tout ses x champs) mais classés par ordre croissant par rapport au champs indexé.

Ce qui fait que :
- cas 1:
1 table de 20 champs ayant 5 index devrait générer 5 images de 20 champs = 5x20 = 100 champs.

- cas 2:
5 tables de 5 champs ayant 1 index (clé primaire et étrangère) chacune devrait générer 5 images de 5 champs = 5x5 = 25 champs seulement


Analysons les impacts :
Supposons que chaque champs contienne 1Mo de donnees.
Les fichiers d index générés pour le 1er cas (1 table de 20 champs) consommeront environ 100Mo contre 25Mo pour ceux du 2ieme cas (5 table de 5 champs).

Conclusion personnelle : économie considérable de l espace disque, en utilisant le cas 2 (configuration actuelle des tables de osc).


Un autre avantage, dans le 2ieme cas, les mises a jours qui ne concerneront que les champs de 1 table parmi les 5 se feront très très rapidement puisque seuls les fichiers relatifs aux index de ces tables (réduites) devraient être modifiés et re-indexés (donc seulement 5 champs sollicités).

Or les mises ajour dans le 1er cas (1 table de 25 champs) seront très lentes (3 a 4x plus lent que le cas 2) car même si l on met a jour un seul champs, c est l ensemble des 25 champs qui devront être re-indexés (re-ecriture de chacun des 5 fichier d index de 25 champs chacun)

En résumer :

- cas 1 :
si on met ajour un seul champ de la table, chacun des 5 fichiers relatifs aux 5 index ( de 25 champs) vont être re-ecrits et donc re-indexes >> re-indexation et réécriture de 5 fichiers de 25 champs chacun.

- cas 2 :
si on met a jour un seul champ d une table parmi les 5, seul le fichier d index relatif a cette table (de 5 champs) sera re-indexé et re-écrit.


Conclusion : les mises a jour dans le cas 2 se ferons beaucoup plus rapidement (1x5 champs a re-indexer) que dans le cas 1 (5x25 = 125 champs a re-indexer).



Merci encore pour vos réponses, et n oubliez pas que je ne suis pas sur a 100 % des mes arguments ni des siens. C est pour cela que je veux avoir vos avis pour ne plus rester dans l ignorance.


A bientôt

Ok merci pour ta reponse. cela se verifit aussi part les faits puisque jai vu des postes ou des gens disaient que ca fait 3 ou 4 ans qu ils utilisaient osc en exploitation avec la même base, et pas de probleme, puisque qu ils ont deja eu 5000 et 6000 clients a chacun !
C est tres rassurant .



Qu appelez-vous par toute la puissance du sql ? le faite de prendre en compte l intégrité référentielle ? puisqu il parait que les recherches et les mises a jours sont plus rapide avec MyIsam qu avec InnoDB qui doit vérifier a chaque fois que l intégrité ref. est bien ok.

Désoler, je sais que ce n est pas un forum destine spécialement aux base de données, mais je profite un peu puisqu on en parle déjà.



Ok super


Bien, je pense que c est résolu.
J ai compris que la version actuelle de la base de données ne nécessite pas d être retouche mais rien empêche de le faire surtout si l on travail sur un serveur dédiée.

J attends de voir s il y aura des autres réponses a mes questions du poste 17 (pour me départager avec mon ami) puis je passerai le poste en résolu.

Bonne soirée et merci pour tout vos efforts.

ton ami oublie le point essentiel : oscommerce est conçu pour être appréhendé par tous, et non pas à une certaine catégorie 'élitiste' : les dba.
de plus, le rapidité ne passe par que par l'architecture d'une db mais aussi par l'intelligence de la programmation sur celui ci.(function udf/stored procedure/triggers/events, etc ...)
j'ai reçu moi même pendant plusieurs mois une formation 'conception/architecture/déploiement' de base de données sur des outils de génie logiciel par des ingénieurs spécialistes oracle/sql server/mysql.
oscommerce n'a pas pour but d'être optimisée pour 1 projet particulier qui répond à 1 cahier des charges, mais pour x projets. et ça change tout.
c'est la généricité qui entraîne une limitation.
tout le reste n'est que branlette intellectuelle.

Faut pas prendre les développeur de solutions open source que pour des bricoleurs du dimanche
La segmentation des tables est ce qui convient le mieux pour les besoins de rapidité de légèreté et compte tenu des besoins évolutifs et en plusieurs langues d'osCommerce.

Dans le principe SGBDR, dès qu'une valeur est amenée à se répéter, elle devrait être externalisée dans une autre table et ses occurrences remplacées par un un index relationnel. Ou du moins cette option doit sérieusement être envisagée. C'est un gage de rapidité dans le traitement des données par un cerveau qui manipule les valeurs numériques et les liens bien plus vite que les données analogiques. C'est le cas des ordinateurs.
Après on peut s'amuser à dupliquer ces données pour faire des tables à rallonge. On gagnerait en lisibilité ce qu'on perdrait en vitesse.
C'est à ça même que sert le relationnel d'une bdd. Voir les base d'nfo sur SGBDR
Donc je ne sais pas où ton pote a fait ses études mais je ne partage pas ses affirmations. A moins que ce ne soit encore un délire théoricien de technocrate dans un but de luxure artificielle.

Quant à vouloir changer l'architecture de la bdd osC, c'est comme vouloir changer le châssis d'une voiture qui fonctionne parfaitement bien : une idée farfelue qui n'aurait d'intérêt que dans le fait de la réaliser. De l'art peut-être ?

Il existe des milliers de boutiques fonctionnant sous osC, certaines gérant des milliers d'articles depuis plusieurs années. J'en connais une dont la base produit compte plus de 5000 entrées et la base clients plus de 15000 individus. Et ça fonctionne sur du mutualisé chez un hébergeur en 3 lettres commençant par O et terminant par H (avec un V au milieu pour ceux qui auraient encore besoin de cet indice).
On constate juste quelques lenteurs sur le moteur de recherche car un développeur a eu la mauvaise idée de tripatouiller les index de la bdd (il a ajouté des index à toutes les colonnes) Ce qui doit je pense provoquer quelques hics.
Malgré ce bricolage d'un ingénieur qui doit être de la même école que ton ami, ça fonctionne encore très bien. Alors oublie tes velléités de révolutionner osC en changeant la bdd. Je ne crois pas que ça soit bien fondé.

pfff, t'es bien un admin, tu comprends rien à la MACRO relation ...

en effet j'y comprends rien, ça doit être une relation qui sent le poisson!

Ok super !
Jai le maximum d infos très intéressantes.

Merci infiniment a tous les participants, même a ceux qui on eu juste l intention de repondre mais sans passer a l acte et plus particulièrement a FoxP2 et au grand maître (Gnidhal)


J adore car ca soutient bien mes arguments d appréciation de l architecture segmentée des tables osc.


Je conclu que ma question est résolue et je retient que :
- La structure de base de données de osc + le code des requêtes associées, sont très bien pensés,
- et que osc fonctionne très bien (en exploitation sur des milliers de boutiques ayant des milliers de produits et de clients) sans modifier la structure de sa bdd,
- qu on peut tout de même la renforcer en passant par exemple certaines tables en InnoDB dans le cas des projets spécifiques (pour exploiter a fond son sgbd) ... mais le code et la machine serveur devraient eux aussi faire l objet de révision, dans ce cas.

Mais, pour ceux qui souhaiteraient partager encore leurs expériences ou apporter d autres arguments, précisions, etc, je suis toujours preneur et de toutes les façons, ca ne fera que enrichir notre connaissance sur les possibilités cachées de osc .