Nous sommes dans notre WIT-e, bien sûr, des amateurs. Propre système ERP (écrit à ce sujet ici - Comment pouvons-nous nous passer de 1C? ), Son propre système CRM, son propre M2M pour la communication avec les distributeurs ("quels autres mots et abréviations intelligents connaissez-vous?"). Et, bien sûr, votre approche de WWW, pour rester dans le cadre de ce paradigme à 3 lettres.Tout a commencé avec l'amour de Microsoft, et certaines des premières versions du site à la fin des années 90 ont été créées à l'aide de la technologie ASP, et en tant que base de données, il contenait un fichier MS Access standard. Soit dit en passant, les fournisseurs proposent toujours l'hébergement sur le bon vieux ASP, 18 ans après sa mise à niveau vers ASP.NET - ici, vous avez des systèmes hérités dans toute sa splendeur.En général, cela est assez pratique - puisque la base de données interne est également écrite en MS Access, la procédure de préparation des données pour le site était très simple, pas de retraductions d'un format de données à un autre (MySQL par exemple). Access prend en charge une extension du langage SQL de la forme «IN <nom de la base de données externe>», qui peut être ajoutée après toutes les instructions DML: INSERT, UPDATE, DELETE (voici une autre abréviation de 3 lettres).Au fur et à mesure que ce lien s'est développé, il a commencé à freiner sans vergogne (en plus, il n'est pas clair quand le fichier mdb se verrouille avec les verrous de la base de données, asservissant tout le site). La traduction du site en ASP.NET n'a pas résolu fondamentalement le problème, et il était également nécessaire de passer à MS SQL Server en tant que base, mais le processus est ensuite allé dans une direction différente. Examinons le problème de l'amélioration des performances du site Web dans une perspective légèrement différente.(Soit dit en passant, mon fournisseur 1Gb.ru écrit qu'ASP.NET est en moyenne plus rapide que le bundle LAMP standard (Linux / Apache / MySQL / PHP), qui est devenu une révélation pour moi. Mais à qui puis-je faire confiance ici si ce n'est l'opérateur de tout? )Avertissement - les idées suivantes représentent, d'une part, une construction théorique élevée à l'absolu, ce qui signifie souvent réduit à l'absurdité, d'autre part, la mise en œuvre concrète, de sorte que l'on ne peut pas dire que l'auteur est dans ses fantasmes et complètement détaché de réalité.Question 1. Pourquoi devrait-il y avoir une base de données sous le site?Eh bien, vraiment, vous admirez tous la vitesse des bases de données en mémoire, non? Alors pourquoi aller loin, procurez-vous-en un sous votre site Web. Et encore plus. Lors de l'initialisation initiale, chargez toutes les données dans des tableaux disponibles au niveau du site dans son ensemble (objet Application dans ASP.NET, Variables globales en PHP, ci-après partout), et au lieu d'écrire des requêtes dans la base de données, parcourez simplement ces tableaux. Tout est adapté au chargement initial des données - la même base de données MS Access, mais au moins des fichiers CSV texte! - l'opération est rarement effectuée et son temps d'exécution ne joue aucun rôle.Il y a des questions, mais nous avons déjà des réponses toutes faites.- , - , ? – ( , -), — ,
- ( ) . . – ( ) , ? , – / , – , . . Catalog ( -!) 2 – :
MinIndex MaxIndex. , - ( ) – Parts ID Catalog, – .
Notez que cette idée peut être poursuivie davantage. De la même manière que les données sont transférées de la base de données sous le site vers la structure de données du site lui-même, lors de la génération d'une page Web, les données dont il a besoin doivent être placées dans sa structure elle-même - c'est-à-dire dans des tableaux JavaScript. Et pas d'AJAX, asynchronie, gestion des erreurs de communication, etc. Et donc cela a été fait sur notre site sur des pages contenant toutes sortes de configurateurs.Soit dit en passant, contrairement aux fichiers de base de données, les tableaux dans la mémoire du serveur Web (et le navigateur Web aussi, bien qu'avec des réservations) occupent une taille approximativement égale à leur représentation binaire, tandis qu'une base de données vide avec une seule table en elle s'appuie déjà sur plusieurs centaines de kilo-octets.Question 2. Pourquoi dois-je utiliser des scripts sur un serveur Web?J'apporte un fragment de code en plusieurs lignes, délibérément simplifié et dans le plus fou des langages de programmation - VBA (sauf pour 1C) Set IE = CreateObject("InternetExplorer.Application")
IE.Navigate "wit.ru"
While IE.ReadyState < READYSTATE_COMPLETE
Wend
Set str = IE.Document.DocumentElement
HTML = str.innerhtml
Le code fait ce qui suit: exécute la page via le navigateur autrefois très populaire d'une entreprise bien connue et enregistre le résultat de l'élaboration du script de serveur au format HTML pur. Vous l'avez deviné, probablement, qu'est-ce qui sera proposé ensuite? Très bien - il est tout à fait possible de rendre un site purement HTML dans les années 90.(Encore une fois à partir de 1GB.ru: «IIS traite très rapidement et efficacement les demandes de fichiers statiques»)Dans le même temps, vous devrez peut-être vous soucier du transcodage d'adresses telles quewit.ru/card.aspx?id=23&prodid=1022985en adresses Web statiques Les pages Web sont également une technologie de mise au point de serveur Web bien connue, inventée à l'origine pour tromper les moteurs de recherche et l'optimisation Web.Ici, il est probablement nécessaire de formuler le principe de base dont dérivent tous les autres. Plus nous consacrerons de temps et de ressources à la préparation des données pour le site Web, plus il lui sera facile de les afficher et plus vite il pourra le faire. Dans ce cas, notre back-end peut fonctionner en mode continu, crachant des données prêtes sur le site avec la fréquence dont nous avons besoin. Et cette approche fonctionnera dans tous les cas, sauf, bien sûr, pour échanger des résumés ou des fenêtres d'Amazon ou d'Alibaba, où les données changent à chaque seconde.Conclusion
Je suis conscient que les problèmes de l'article sont trop pointus et une solution non standard est proposée. Je vais oser suggérer (ce n'est pas mon sujet du tout) qu'une telle approche pourrait fonctionner pour tous les systèmes embarqués, où sinon, sur un appareil informatique faible, vous devez placer un mini moteur de base de données et un gestionnaire de script au lieu du serveur Web le plus simple (au prix de plus de consommation de mémoire - opérationnelle et constante).