Esta es la solución más completa que encomtrarás compartir, sin embargo mírala pausadamente y analiza si se adapta a tu trabajo.
Solución:
Si bien las respuestas anteriores no son necesariamente equivocadono dan la imagen completa.
Mira, hay dos tipos de ‘Archivos Lógicos’ – con y sin clave.
- Los archivos lógicos sin clave son de hecho equivalentes a una vista y no actuarán como un índice.
- Los archivos lógicos con clave son equivalentes a un índice (por lo que recuerdo, en realidad están implementados de la misma manera en el sistema subyacente). Estos será actúe como espera para un índice.
Todos los archivos lógicos, con o sin clave, aparecen en iSeries Navigator como vistas (creo que sólo los índices ‘reales’ – SQL – aparecen como índices).
No estoy… realmente seguro de cómo averiguar si un archivo lógico está codificado desde Navigator. Y en el iSeries, mi empresa tiene un comando personalizado (lo que supongo que es) para mostrar los diversos archivos lógicos (y sus keys) para un archivo físico dado (los índices también aparecen). Sin embargo, la columna con clave es bastante fácil de detectar en una definición de archivo lógico: haga que algunos de sus amigos AS/400 le muestren las definiciones y qué buscar.
Documentación de IBM DB2:
Desde la perspectiva de la interfaz SQL, los archivos lógicos son idénticos a las vistas y los índices.
También está este artículo “Índices SQL y E/S nativas: sin contradicciones (2016)” que habla sobre las diferencias entre los “archivos lógicos con clave DDS” y los “índices SQL”. Nota: los archivos lógicos son parte de DDS, se accede a ellos a través de “E/S nativas”. Sin embargo, “DDS es una tecnología obsoleta”.
Los archivos lógicos combinan las funciones de vistas (selección de columnas y unión de tablas) e índices (ordenación de filas). Por lo general, funcionan como un índice, pero se muestran como una vista en Navigator. Como nota al margen, un archivo físico (no una tabla) también puede tener un índice.
Las tablas, vistas e índices de SQL se implementan en DB2 para iSeries mediante archivos físicos y lógicos. La principal diferencia es cuando la base de datos comprueba la integridad de los datos. Se verifica en escritura para Tablas y se verifica en lectura para Archivos. Puede poner datos basura en un archivo pero no en una tabla.
En realidad, hay muchas pequeñas diferencias entre los índices/vistas creados por SQL y los archivos lógicos creados a través de DDS (esa es la forma de escribir archivos fuente para sus archivos lógicos (LF) y compilarlos en LF-Objects).
Así son ellos mismo ¿cosa? eso es una definición no allí. Pero hay cosas muy parecidas y en la mayoría de los casos puedes usar cualquiera. Es posible que nunca experimentes ninguna diferencia, pero también es posible que un día te encuentres ante una situación inexplicable, debido a las diferencias. Aquí hay algunas diferencias que he aprendido hasta ahora (y recuerdo ahora mismo). (Hablaré sobre LF, que son archivos lógicos, y PF (archivos físicos) aquí. Un PF es más o menos lo que llamaría una tabla en SQL, pero al igual que con LF e índices/vistas, no llamaría ellos lo mismo)
- Los LF pueden tener declaraciones de selección/omisión, que filtran qué filas del PF. ¡Cuidado con esos! No solo son a menudo confusos, sino que también pueden tener un impacto significativo en sus consultas SQL. Dichos LF son ignorados por el optimizador de consultas moderno (SQE) e incluso pueden conducir a que el SQE no se use en absoluto, solo porque existen (dependiendo de su configuración de SQL). Normalmente puede obtener el mismo comportamiento con un índice de clasificación y una selección.
- Los LF pueden compartir rutas de datos (LF A con índice col1, col2, col3 y LF B con índice col1, col2, col4 deberían compartir la indexación afaik), los índices sql no hacen eso (pero se supone que esa ventaja no es tan importante como la siguiente desventaja)
- Los índices pueden tener un tamaño de página mayor. Por lo que sé, eso puede marcar la diferencia en mesas enormes).
- Los índices y los LF pueden actuar de manera diferente cuando cambia el nombre de un PF y lo vuelve a crear desde su fuente DDS. Los índices deben permanecer en el objeto renombrado, mientras que los LF deben hacer referencia al nuevo objeto con el nombre anterior
Estas diferencias están relacionadas con el hecho de que el sistema DB2/400 de IBM se creó hace mucho tiempo, cuando nadie hablaba de SQL y se desarrolló desde entonces. Pero dado que SQL se volvió importante, IBM también introdujo el soporte de SQL para su base de datos bien utilizada. Entonces, los índices/vistas deben admitir las cosas, SQL requiere que lo hagan. Los LF, por otro lado, deben seguir siendo compatibles hacia abajo con la historia del AS/400. Esos difieren. Y por lo tanto, no pueden ser lo mismo sin dejar de apoyar a uno. Pero tratan de acercarse bastante.