¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 10
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Lo estoy intentando de nuevo.
Tenemos tres archivos.
1. L. Tolstoi. Guerra y Paz, volumen 1.
2. L. Tolstoi. Guerra y Paz, volumen 2.
3. F. Dostoyevski. Crimen y Castigo.
Empaquetamos cada uno de ellos.
Tenemos tres archivos empaquetados sin nombre (no me preguntes cómo me imagino un archivo sin nombre). También tenemos un archivo no empaquetado, que es "Crimen y Castigo".
¿Cómo encontrar este archivo en los tres archivos comprimidos de la manera más económica?
Opción 1: Tengo que comprimir los tres archivos y encontrar el archivo que busco.
Opción 2. Comprime el archivo que buscas y encuentra exactamente el mismo archivo entre los tres comprimidos.
Mm-hmm - así que la que propones no es buena
Sí, sé que si los datos son cortos, el tamaño aumenta al archivar.
Si quieres seguir en esta dirección, también puedes usar hashing o checksum para buscar, no tienes que usar codificación de compresión. Crear un índice hash y buscar por dicotomía.
Pero esto es si la porción de la fuente está disponible en tamaño completo.
Por ejemplo, en estos casos utilizo el SGBD sin ningún tipo de trucos. Dedico menos tiempo al desarrollo y el producto es estable.
Ustedes dicen todo lo que es correcto, lo que pone de relieve una vez más que la opción de compresión debe estar justificada para la tarea.
Hay que basarse en el planteamiento del problema.
Si quieres seguir en esta dirección, también puedes usar hashing o checksum para buscar, no tienes que usar la codificación de compresión. Crear un índice hash y buscar por dicotomía.
Pero esto es si la porción de fuente está disponible en tamaño completo.
Por ejemplo, en estos casos utilizo el SGBD sin ningún tipo de trucos. Dedico menos tiempo al desarrollo y el producto es estable.
Así que esa no era mi sugerencia. En cualquier caso, la idea es interesante.
>>> Hablando de comparar dos secuencias comprimidas.
¡Dima! Recuérdame - esto es lo que estábamos hablando
>>> eso es exactamente lo que discutimos en la práctica.
>>> Sí, lo sé, si los datos son cortos, aumenta el tamaño al archivar.
>> por eso no es bueno
--
por eso las bases de datos industriales no tienen esa ideología.
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Entero:
Buena idea.puede probarlo
>>> Por ejemplo, en estos casos utilizo el SGBD sin ningún tipo de trucos. Se tarda menos en desarrollarlo y el producto es estable.
pero es mejor utilizar una base de datos SQL industrial ya hecha
>>> Hablando de comparar dos secuencias comprimidas.
¡Dima! Recuérdame, esto es de lo que estábamos hablando.
>>> eso es exactamente lo que discutimos en la práctica.
>>> Sí, lo sé, si los datos son cortos, aumenta el tamaño durante el archivo.
>> por eso no es bueno
--
por eso las bases industriales tampoco tienen esta ideología
...
puede probar este
>>> Yo, por ejemplo, en estos casos, utilizo un SGBD sin trucos. Dedico menos tiempo al desarrollo y el producto es estable.
pero es mejor utilizar bases de datos industriales SQL ya hechas
Yurichik, me refiero a sin vueltas con el procesamiento de archivos, la compresión, etc. Me refería a trabajar sólo con SQL y la lógica del robot/indicador. Trabajé con muchas bases de datos, el único problema era hacer que MQL y SQL funcionaran juntos)). Creé una solución de buen aspecto sin arrays ni estructuras.
En general, prefiero no reinventar la rueda y resolver los problemas con los mejores medios.
Creo que es por otra razón. Como el problema de la carga de datos grandes en el sistema operativo se resuelve allí de forma diferente, no se cargan, sino que se leen directamente del disco. (Supongo)
el servidor lo hace... muy eficazmente.