Por un lado, es bueno que hayas abierto una nueva pregunta. Pero, por otro lado, al extraer una consulta y preguntar si funciona más rápido, se pierde el contexto de la pregunta anterior, la nueva pregunta está demasiado aislada. Como estoy seguro de que sabe, la administración de una base de datos, la gestión de recursos (memoria/caché, disco, ciclos de CPU), la gestión del código (bueno o malo) que usa esos recursos, son parte de la imagen completa. El rendimiento es un juego comercial, nada es gratis.
-
El principal problema que tuve fue la duplicación de la columna EndDate, que se deriva fácilmente. Las columnas duplicadas equivalen a anomalías de actualización. Smirkingman ha proporcionado el ejemplo clásico:algunas consultas obtendrán un resultado y otras consultas obtendrán el otro. Eso simplemente no es aceptable en las grandes organizaciones; o en bancos (al menos en países desarrollados) donde los datos son auditados y protegidos. Has infringido una regla de normalización básica y hay sanciones que pagar.
-
Actualizar Anomailes; dos versiones (ya detalladas). Los auditores no pueden aprobar el sistema.
-
Tamaño de tabla
En cualquier tabla grande es un problema, y especialmente en series de tiempo o datos temporales, donde el número de columnas es pequeño y el número de filas es enorme. Entonces, qué, dirán algunos, el espacio en disco es barato. Sí, también lo son las ETS. Lo que importa es para qué se usa y qué tan bien se cuida.-
El espacio en disco
Puede ser barato en una PC, pero en un servidor de producción no lo es. Básicamente, ha agregado un 62% al tamaño de la fila (13 más 8 es igual a 21) y, por lo tanto, al tamaño de la tabla. En el banco al que estoy asignado actualmente, cada departamento que posee los datos se cobra de la siguiente manera, todo lo que hay es almacenamiento basado en SAN. Las cifras son por GB por mes (este no es un banco australiano de alto nivel):$1.05 por RAID5 sin espejo
(sabemos que es lento, pero es barato, simplemente no ponga información importante en él, porque si se rompe, después de que el nuevo disco esté caliente o frío, toma días para que se vuelva a sincronizar.)$2.10 por RAID5 Mirrored
En la SAN, eso es.$4.40 por RAID1+0
Mínimo para datos de producción, copias de seguridad de registros de transacciones y volcados nocturnos de bases de datos.$9.80 por RAID1+0 replicado
A un diseño SAN idéntico en otro sitio a prueba de bombas. Corte de producción en minutos; pérdida de transacción casi nula. -
Memoria/caché
Ok, Oracle no lo tiene, pero las bases de datos bancarias serias sí tienen cachés y están administrados. Dado cualquier tamaño de caché específico, solo el 62% de las filas caben en el mismo tamaño de caché. -
E/S lógicas y físicas
Lo que significa un 50 % más de E/S para leer la tabla; tanto la transmisión en caché como las lecturas de disco.
-
-
-
Por lo tanto, si la consulta funciona mejor o peor de forma aislada, es una cuestión académica. En el contexto de lo anterior, la tabla es lento y tiene un rendimiento un 62% peor, todo el tiempo, en cada acceso. Y está afectando a todos los demás usuarios del servidor. A la mayoría de los DBA no les importará (a mí ciertamente no me importaría) si el formulario de subconsulta funciona a la mitad de la velocidad, porque su bonificación está ligada a la aceptación de la auditoría, no solo al rendimiento del código.
-
Además, existe el beneficio adicional de no tener que volver a visitar el código y arreglar las transacciones debido a anomalías de actualización.
-
Y las transacciones tienen menos puntos para actualizar, por lo que son más pequeñas; menos bloqueos de bloqueo, etc.
-
-
De acuerdo, esa discusión en los Comentarios es difícil. En mi Respuesta, he detallado y explicado dos subconsultas. Hubo un malentendido:estabas hablando de esta subconsulta (en la cláusula WHERE, una subconsulta de tabla ) y estaba hablando de la otra subconsulta (en la lista de columnas, una subconsulta escalar ) cuando dije que funciona tan rápido o más rápido. Ahora que eso se ha aclarado, no puedo decir que la primera consulta anterior (subconsulta en la cláusula WHERE, una tabla) funcionará tan rápido como la segunda consulta (con la columna duplicada); el primero tiene que realizar 3 escaneos, donde el segundo solo realiza 2 escaneos. (Sin embargo, me atrevo a decir que el segundo escaneará la tabla).
El punto es que, además del problema del aislamiento, no es una comparación justa, hice el comentario sobre las subconsultas escalares. No sugeriría que una consulta de 3 escaneos sea tan rápida o más rápida que una consulta de 2 escaneos.
La declaración que hice sobre la subconsulta de la tabla de 3 escaneos (que cito aquí) debe tomarse en el contexto completo (ya sea esa publicación en su totalidad o la anterior). No me estoy alejando de eso.
Paso la mitad de mi vida eliminando alternativas ilegales como columnas duplicadas, que se basan en el tema del rendimiento, con los creadores cantando el mantra de que la mesa es lenta, por lo que se han "desnormalizado para el rendimiento". El resultado, predecible antes de comenzar, es una mesa de la mitad del tamaño, que funciona el doble de rápido en general . The Times Series es la pregunta más común aquí (el enlace enlaza con otra pregunta, que enlaza con otra), pero imagina el problema en una base de datos bancaria:
OpeningExposurediario yClosingExposureporSecurityporHoldingporUnitTrustporPortfolio. -
Pero permítanme responder una pregunta que no se ha hecho. Este tipo de interacción es normal, común cuando se trabaja con equipos de desarrollo internos; aparece al menos una vez al mes. Un desarrollador de emergencia ya ha escrito y probado su código, usando una tabla con una columna duplicada, vuela, y ahora está estancado porque no lo pondré en la base de datos.
No, lo probaré dentro del contexto de todo el sistema y:
-
la mitad de las veces, la tabla entra sin la columna EndDate porque no hay gran problema con una consulta de medio segundo que ahora se realiza en un segundo.
-
La otra mitad del tiempo, el rendimiento de [subconsulta de tabla] no es aceptable, por lo que implemento un indicador booleano (bit) para identificar
IsCurrent. Eso es mucho mejor que una columna duplicada y proporciona velocidades de 2 escaneos. -
Ni en un millón de años me harás duplicar una columna; agregando 62% al tamaño de la mesa; ralentizando la tabla en el contexto multiusuario completo en un 62%; y correr el riesgo de reprobar una auditoría. Y no soy un empleado, no recibo un bono.
Valdría la pena probarlo:consulta con una columna duplicada frente a consulta con
IsCurrentindicador, en el contexto completo del uso general de los recursos. -
-
Smirkingman ha mencionado un buen punto. Y lo replantearé claramente, para que no se fragmente y luego uno u otro fragmento sea atacado. Por favor, no rompa esto:
Una base de datos relacional,
normalizada por un modelador relacional experimentado, a la verdadera quinta forma normal
(sin anomalías de actualización; sin columnas duplicadas),
con pleno Cumplimiento Relacional
(IDEF1X, particularmente relacionado con la minimización deIdclaves primarias; y por lo tanto no paralizar el poder del motor relacional)
dará como resultado más tablas y más pequeñas, una base de datos más pequeña,
con menos índices,
requiriendo menos uniones
(así es, más tablas pero menos uniones),
y superará cualquier cosa que infrinja cualquiera de esas reglas
en el mismo hardware y empresa plataforma db
(excluye software gratuito, MS, Oracle; pero no deje que eso lo detenga),
en el contexto completo del uso de OLTP de producción
en al menos un orden de magnitud,
y será mucho más fácil de usar
y cambiar
(nunca es necesario "refactorizar").He hecho esto al menos 80 veces. Dos órdenes de magnitud no son raros, si lo hago yo mismo, en lugar de proporcionar el marco para que alguien más lo haga.
Ni a mí, ni a las personas con las que trabajo o que me pagan, nos importa lo que hará una consulta de forma aislada.
