Un subtaller para completar las FAQ (preguntas frecuentes). ¡Ayudemos a los compañeros! - página 14
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
Y lo correcto, en mi opinión, es pedir siempre al terminal la información más actualizada.
El estado de los pedidos (array) se consulta precisamente cuando hay que gestionarlos.
No sostengo que podamos prescindir de ella, ni que necesitemos una masiew de antemano. Y analizar inmediatamente el estado de los pedidos a la carta después de OrderSelect y filtrar los no deseados por mago, símbolo, etc.
Pero usted sostiene que la matriz de billetes es una UG. Justifique por qué.
-------------
Taras sugirió la opción "ultra" cuando toda la información sobre el pedido se escribe en el array. Sólo puedo estar de acuerdo con esto en la posición de que toda esta información no es necesaria. Y en la versión simplificada, en su mayor parte, sólo se necesitan billetes.
Yo no lo sugeriría. En la mayoría de los casos, no se necesita una serie de entradas. Y lo correcto, en mi opinión, es pedir siempre al terminal la información más actualizada posible.
Y en general, este es su punto de vista personal y el mío. Y siempre hay que dar al usuario el derecho a elegir, cuyos argumentos son más sensatos. ;)
P.D. Y sólo he dado MI respuesta a la pregunta planteada en las FAQ. :)
OK, IMHO UG porque IMHO es correcto tener la información más actualizada del pedido. Y, en mi opinión, se puede prescindir de una serie de órdenes el 95% de las veces.
Quieres... añadir algo, yo sólo estaba dando mi opinión.
Digámoslo así:
- En términos de conveniencia y abstracción del modelo, es mejor usar arrays.
- Para acelerar el trabajo - sin matrices.
La relevancia de la información no tiene nada que ver. En ambas variantes -con o sin matrices- la relevancia es 100% fresca
-------------
Taras sugirió la opción "ultra", en la que toda la información sobre el pedido se escribe en el array. Puedo estar de acuerdo con esto sólo en la posición de que toda esta información no es necesaria. Y en la variante simplificada, la mayoría de las veces sólo se necesitan billetes.
¿O he entendido algo mal?
Alexey! Estoy lejos de pensar que al introducir esta pregunta en las FAQ (Obtención de un conjunto de tickets de órdenes "propias"), te referías a la "posición de que toda esta información no es necesaria" - ¡como para jugar!
¿O he entendido algo mal?
Por alguna razón, ha incluido todas las propiedades en el concepto de "su billete" además del billete.
Pero definitivamente he hecho tu sugerencia como una extensión de la función "sólo un billete".
También se necesita con frecuencia, sobre todo cuando se analizan y comparan los datos históricos de los pedidos.
Digámoslo así:
- En términos de conveniencia y abstracción del modelo, es mejor usar arrays.
- Para acelerar el trabajo - sin matrices.
La relevancia de la información no tiene nada que ver. En ambas variantes -con o sin matrices- la relevancia es 100% fresca
La simple lógica sugiere que el acceso extra al servidor para obtener "información fresca" es un tiempo extra. Y no puede competir en tiempo con la obtención de la misma información de la matriz.
Hay un experto en la velocidad del código - Victor (Vinin), ¡su opinión sería interesante!
Sobre lo segundo ("no hay matrices para agilizar el trabajo"), no me apresuraría a ser categórico.
La simple lógica sugiere que el acceso extra al servidor para obtener "información fresca" es un tiempo extra. Y no puede competir en tiempo con la obtención de la misma información de la matriz.
Hay un experto en rendimiento del código, Victor (Vinin), ¡su opinión sería interesante!
Una vez más, al trabajar con las propiedades de los pedidos, no hay ningún servidor con el que contactar.
En el comercio, la regla más importante es la relevancia (para no convertirse en el UG del que escribió TheXpert).
Por lo tanto, si se remite a la lista de órdenes en cada función y se crea un array de nuevo, definitivamente causará una ralentización. Causará el llenado de la matriz.
Así, podemos ahorrar dinero en la actualización de arrays y en la repetición de OrdeSelect (ya en el billete).
Si tienes 1-2 órdenes de trabajo, el conjunto no es crítico, pero si tienes 50-100, ya es significativo.
No estoy imponiendo este enfoque a nadie, simplemente veo la lógica que hay detrás y utilizo este principio en mis diseños.
P.D. Esto no es para iniciar una disputa sobre este tema, es simplemente un argumento a lo anterior.
Por lo tanto, si se consulta la lista de pedidos en cada función y se vuelve a crear la matriz, se producirá definitivamente una ralentización. Por el llenado de la matriz.
Selecciono en
o:
dependiendo de cómo me sienta más cómodo con una u otra función.
Estoy de acuerdo en que la racionalidad de este planteamiento se nota más en los sistemas multidivisa, que son una minoría.