Je viens d'un fond de MSSQL, et quand je demande aux gens de ma compagnie s'ils ont créé des index sur certaines colonnes, ils diront oui, mais pointez-moi de ces éléments appellent des fichiers logiques.
Dans le navigateur ISERIES Ces fichiers logiques apparaissent sous la catégorie "Vues". Lorsque je clique sur la catégorie des «index», rien n'est là, ce qui me conduit à croire qu'il n'ya aucun index créé sur des colonnes, au moins comme je les comprends. Un fichier logique semble être une vue triée par certaines colonnes.
Donc, ma question est, sont des fichiers logiques et des index (index dans le sens de MSSQL) la même chose?
7 Réponses :
Selon ce Description , un fichier logique AS / 400 DB2 est appelé Vue dans la plupart des autres bases de données relationnelles. Je devrais dire que je ne pense pas qu'un fichier logique est identique à un index.
Incorrect. La description est inexacte de plusieurs manières. Peut-être que le plus grave est qu'il néglige que les fichiers logiques peuvent inclure un index tout en ayant d'autres caractéristiques en même temps. La page Description liée semble avoir été écrite par une personne qui n'était pas un expert AS / 400. Voir d'autres réponses à la place.
Sur le système basé sur les objets est un type d'objet de * fichier. Une variante du * fichier est un fichier de base de données. Et du fichier de base de données, il existe deux types: fichier physique (PF) et fichier logique (LF). De la vue SQL et de l'index SQL, chacun est une extension de [hérités de nombreux attributs de] le LF, et la table SQL est une extension de [hérités de nombreux attributs de] PF. Un LF peut être une séquence clé ou une séquence d'arrivée; Un index SQL est un LF clé. Le fichier Keyed a un chemin d'accès (ACCPTH) implémenté sous la forme d'un indice Index , en particulier un indice de dataspace (QDDSI) sur les données, un dataspace (QDDS)
tandis que les réponses précédentes ne sont pas nécessairement mauvaises , ils ne donnent pas la photo complète.
Voir, il existe deux types de «fichiers logiques» - clés et négligés.
Tous les fichiers logiques, touchés ou non, apparaissent réellement dans Iseries Navigator comme points de vue (je pense que les «réels» - SQL - indices apparaissent en tant qu'indices).
Je suis ... pas vraiment sûr de savoir comment savoir si un fichier logique est clé à partir de Navigator. Et sur les Iseries, mon entreprise a une commande personnalisée (ce que je suppose être) pour afficher les différents fichiers logiques (et leurs clés) pour un fichier physique donné (indices apparaître aussi). Cependant, la colonne clé est assez facile à repérer sur une définition de fichier logique - certains de vos copains de votre AS / 400 vous montrent les définitions et sur quoi rechercher.
du point de vue de l'interface SQL, les fichiers logiques sont identiques aux vues et index.
Il y a aussi cet article "" Index SQL et Native I / O - Aucune contradiction (2016) " qui parle des différences entre" Fichiers logiques "DDS-Key" et "Index SQL". Remarque: les fichiers logiques font partie du DDS, ils sont accessibles via «E / S natif». "DDS est une technologie obsolète" cependant.
Merci, bon à savoir. Il semble que la plupart de nos fichiers logiques soient effectivement clés.
En tant que note latérale, les fichiers logiques clés apparaissent comme «index utilisé» sur les plans d'explication, l'optimiseur produit (et des références de navigateur). Donc, une façon de les détecter consiste à exécuter une requête qui devrait utiliser l'index et vérifier le plan d'explication (sans toujours fonctionner, cependant).
Lorsque vous affichez des index sur une table, le résultat inclut des fichiers logiques et des index clés. Le type de colonne vous indique si le fichier logique est saisi.
Fichiers logiques Combinez les fonctionnalités des deux vues (sélection de colonne et jonction de table) et index (commande de ligne). Ils fonctionnent généralement comme un index mais font apparaître comme une vue dans Navigator. Comme une note latérale, un fichier physique (non du tableau) peut également avoir un index.
Les tables SQL, les vues et les index sont implémentées dans DB2 pour ISERIES à l'aide de fichiers physiques et logiques. La principale différence est que la base de données vérifie l'intégrité des données. Il est coché sur Write pour les tables et vérifiés pour lire des fichiers. Vous pouvez mettre des données de la corbeille dans un fichier mais pas dans une table.
Il existe en fait de nombreuses différences minuscules entre les index / vues créées par SQL et les fichiers logiques créés via DDS (c'est la manière de rédiger des fichiers source pour vos fichiers logiques (LF) et de les compiler à des objets LF).
Alors sont-ils la même chose la même chose? C'est une définition Ces différences sont liées au fait que le système IBMS DB2 / 400 a été créé il y a longtemps, lorsque personne ne parlait de SQL et développé depuis. Mais comme SQL est devenu important, IBM a également introduit SQL-support pour leur DB bien utilisé. Donc, les indices / vues doivent prendre en charge la substance, SQL les exige. Par contre, il doit rester compatible vers le bas avec l'histoire AS / 400S. Ceux diffèrent. Et ainsi, ils ne peuvent pas être les mêmes sans laisser tomber le support pour un. Mais ils essaient de venir assez près.
est tombé sur cette discussion tout en recherchant quelque chose d'autre, alors pensais que j'avais contribué. Un fichier logique clé fournit la fonctionnalité d'un index. Cependant, les index fonctionnent mieux que les fichiers logiques, l'optimiseur de requête dans DB2 pour IBM I est plus susceptible d'utiliser le SQE (moteur de requête SQL) plutôt que le CQE plus ancien et moins efficace (moteur de requête classique) pour optimiser la requête si elle peut utiliser un index. Par défaut, les index ont une taille de page plus importante que les fichiers logiques, ce qui aide à la performance. Dans des versions plus récentes du système d'exploitation IBM I, la taille de la page d'un fichier logique peut être spécifiée, de sorte que l'avantage des index n'était pas important comme précédemment. La direction stratégique d'IBM consiste à concentrer les efforts d'amélioration des performances de la base de données sur les nouveaux objets de base de données définis SQL DDL (tableaux, index, etc.) et à ignorer les objets définis de DDS hérités plus âgés (fichiers physiques et logiques.)
Les améliorations apportées à l'optimiseur SQE ont des situations pratiquement éliminées dans lesquelles des fichiers logiques causeraient DB2 revenir à l'utilisation de l'optimiseur CQE.
est tombé sur cette discussion tout en recherchant quelque chose d'autre, alors pensais que je voudrais simplement ajouter une contribution aussi. Les PFS et les LF sont généralement appelés «fichiers natifs» en raison du fait qu'ils sont nés avec ce système ancêtre (S / 38, pas sûr si même avant), tandis que les tables / vues ont été introduites ultérieurement avec SQL. Bien que de nos jours, SQE considère que les PFS / LFS et les tableaux / tables / vues dans le processus d'optimisation, une autre différence énorme parmi les deux est que, tandis que les deux peuvent être utilisées dans toutes les instructions SQL, même si elles sont intégrées dans des programmes compilés, seuls PFS / LFS peuvent être utilisés de manière native programmes compilés. Considérant les programmes compilés, les modifications apportées aux formats d'enregistrement PFS / LFS impliquent le processus de rebonding / de recompilation, tandis qu'il n'y ait pas besoin de celui-ci en cas de modifications de tables / vues, à moins qu'elles ne soient mentionnées de l'instruction SQL extérieure.
Ce fichier PDF d'IBM qui explique les méthodes d'indexation dans DB2 a été utile pour moi afin de comprendre les différences entre les tableaux créés à l'aide de SQL ou de fichiers physiques sur les systèmes AS400.
Je ne connais pas la première chose à propos du monde AS / 400, mais essayez de regarder Fichiers logiques . Ils sont décrits comme étant comme un index - mais pas dans le sens de la MSSQL du mot (semblent plus comme des "vues" pour moi)
Je ne pense pas que la "meilleure réponse" actuelle soit suffisamment argumentée, car le support de liaison est brisé et il n'y avait pas de résumé fourni en 2011, et la phrase "Je ne pense pas ... est la même" n'est pas aussi Normes de dépassement de pile. Je recommande donc d'accepter l'une des autres réponses plus intéressantes.