Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 10
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
J'essaie à nouveau.
Nous avons trois dossiers.
1. L. Tolstoï. Guerre et Paix, Volume 1.
2. L. Tolstoï. Guerre et Paix, Volume 2.
3. F. Dostoïevski. Crime et châtiment.
Nous emballons chacun d'entre eux.
Nous avons trois fichiers emballés sans nom (ne me demandez pas comment j'imagine un fichier sans nom). Nous avons aussi un dossier non emballé, que ce soit "Crime et Châtiment".
Comment trouver ce fichier dans les trois fichiers compressés de la manière la plus économique ?
Option 1 : Je dois compresser les trois fichiers et trouver le fichier que je cherche.
Option 2. Compressez le fichier que vous recherchez et trouvez exactement le même fichier parmi les trois fichiers compressés.
Mm-hmm - donc celui que vous proposez n'est pas bon
Oui, je sais que si les données sont courtes, la taille augmente lors de l'archivage.
Si vous voulez continuer dans cette direction, vous pouvez également utiliser le hachage ou la somme de contrôle pour la recherche, vous n'avez pas besoin d'utiliser le codage de compression. Créez un index de hachage et faites une recherche par dichotomie.
Mais c'est si la portion source est disponible en taille réelle.
Par exemple, dans de tels cas, j'utilise le SGBD sans aucune astuce. Je consacre moins de temps au développement et le produit est stable.
Vous dites tout ce qu'il faut, et cela souligne une fois de plus que l'option de compression doit être justifiée pour cette tâche.
Vous devez vous appuyer sur l'énoncé du problème.
Si vous voulez continuer dans cette direction, vous pouvez également utiliser le hachage ou la somme de contrôle pour la recherche, vous n'avez pas besoin d'utiliser le codage de compression. Créez un index de hachage et faites une recherche par dichotomie.
Mais c'est si la portion source est disponible en taille réelle.
Par exemple, dans de tels cas, j'utilise le SGBD sans aucune astuce. Je consacre moins de temps au développement et le produit est stable.
Ce n'était donc pas ma suggestion. En tout cas, l'idée est intéressante.
>>> Je parle de la comparaison de deux séquences compressées.
Dima ! Rappelle-moi - c'est ce dont nous parlions.
>>> c'est exactement ce dont nous avons discuté dans la pratique.
>>> Oui, je sais, si les données sont courtes, cela augmente la taille lors de l'archivage.
>> C'est pour ça que ce n'est pas bon.
--
c'est pourquoi les bases de données industrielles n'ont pas cette idéologie.
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Entier:
Bonne idée.vous pouvez l'essayer
>>> Par exemple, dans de tels cas, j'utilise le SGBD sans aucune astuce. Il faut moins de temps pour le développer et le produit est stable.
mais il est préférable d'utiliser une base de données SQL industrielle prête à l'emploi.
>>> Je parle de la comparaison de deux séquences compressées.
Dima ! Rappelle-moi - c'est ce dont nous parlions.
>>> c'est exactement ce dont nous avons discuté dans la pratique.
>>> Oui, je sais, si les données sont courtes, cela augmente la taille lors de l'archivage.
>> C'est pour ça que ce n'est pas bon.
--
c'est pourquoi les bases industrielles n'ont pas non plus cette idéologie
...
vous pouvez essayer celui-ci
>>> Moi, par exemple, dans de tels cas, j'utilise un SGBD sans aucune astuce. Je consacre moins de temps au développement et le produit est stable.
mais il est préférable d'utiliser des bases de données SQL industrielles prêtes à l'emploi.
Yurichik, je veux dire sans rebondissements avec le traitement des fichiers, la compression, etc. Je voulais dire travailler avec SQL et la logique des robots/indicateurs. J'ai travaillé avec de nombreuses bases de données, le seul problème était de faire fonctionner ensemble MQL et SQL)). J'ai créé une solution agréable à regarder sans tableaux et structures.
En général, je préfère ne pas réinventer la roue et résoudre les problèmes par les meilleurs moyens.
Je pense que c'est pour une autre raison. Comme le problème du chargement des données volumineuses dans le système d'exploitation y est résolu différemment, elles ne sont pas chargées, mais lues directement sur le disque. (je suppose)
le serveur le fait... très efficacement.