AS / 400 Db2 логический файл vs индекс таблицы

в то время как предыдущие ответы не обязательно неправильно, они не дают полной картины.
Смотри, есть два типы "логических файлов" - keyed и unkeyed.

1. неключевые логические файлы действительно эквивалентны представлению и не будут выступать в качестве индекса.
2. ключевые логические файлы эквивалентны индексу (насколько я помню, они фактически реализованы таким же образом в базовой системе). Эти будет действовать так, как вы ожидаете для индекса.

все логические файлы, введенные или нет, фактически отображаются в навигаторе iSeries как представления (я думаю, что только "фактические" - SQL - indicies отображаются как indicies).
Я... на самом деле не уверен, как узнать, если логический файл набирается из Navigator. И на iSeries у моей компании есть (что я предполагаю) пользовательская команда, чтобы показать различные логические файлы (и их ключи) для данного физического файла (indicies тоже появляются). Тем не менее, ключевой столбец довольно легко обнаружить в логическом определении файла - некоторые из ваших друзей AS/400 покажут вам определения и что искать.

логические файлы объединяют функции обоих представлений (выбор столбцов и объединение таблиц) и индексов (порядок строк). Они обычно функционируют как индекс, но отображаются как представление в Navigator. В качестве примечания физический файл (не таблица) также может иметь индекс.

таблицы, представления и индексы SQL реализованы в DB2 for iSeries с использованием физических и логических файлов. Основное различие заключается в том, что база данных проверяет целостность данных. Он проверен на write для таблиц и проверен на читать файлы. Вы можете поместить данные корзины в файл, но не в таблицу.

на самом деле существует много крошечных различий между SQL, созданными индексами/представлениями и логическими файлами, созданными с помощью DDS (это способ записи исходных файлов для ваших логических файлов (LF) и компиляции их в LF-объекты).

вот это то же самое вещь? Это определенно нет там. Но есть очень похожие вещи и в большинстве случаев вы можете использовать либо. Возможно, вы никогда не почувствуете никакой разницы, но также возможно, что однажды вы стоите перед необъяснимой ситуацией из-за различий. Вот некоторые различия, которые я узнал до сих пор (и я помню прямо сейчас). (Я буду говорить о LFs-это логические файлы-и PFS (физические файлы) здесь. PF-это более или менее то, что вы назвали бы таблицей в SQL, но, как и с LFs и индексами/представлениями, я бы не назвал их одинаковыми)

• LFs может иметь операторы select/omit, которые фильтруют, какие строки PF. будьте осторожны с этим! Они не только часто сбивают с толку, но и могут оказать значительное влияние на ваши SQL-запросы. Такие LFs игнорируются современным оптимизатором запросов (SQE) и могут даже привести к тому, что SQE вообще не используется, только потому, что существует (в зависимости от вашей SQL-конфигурации). Вы можете обычно получить такое же поведение с индексом сортировки и выбора.
• LFs может обмениваться данными (LF A с индексом col1, col2, col3 и LF B с индексом col1, col2, col4 должен делиться индексированием afaik), sql-индексы этого не делают (но это преимущество должно быть не так важно, как следующий недостаток)
• индексы могут иметь больший размер страницы. Из того, что я знаю, это может сделать разницу на огромных столах).
• индексы и LFs могут действовать по-разному, когда вы переименовываете PF и записываете его из источника DDS. Индексы должны оставаться на переименованном объекте, в то время как LFs должна ссылаться на новый объект со старым именем

эти различия связаны с дело в том, что IBMs DB2/400-система была создана давно, когда никто не говорил о SQL и разрабатывалась с тех пор. Но поскольку SQL стал важным, IBM также представила SQL-поддержку для своей хорошо используемой БД. Поэтому индексы / представления должны поддерживать материал, SQL требует от них этого. С другой стороны, LFs должна оставаться совместимой с историей AS/400s. Они отличаются. И таким образом, они не могут быть одинаковыми, не опуская поддержки. Но они стараются подойти очень близко.

наткнулся на эту дискуссию, ища что-то еще, поэтому подумал, что я просто добавлю свой вклад. PFs и LFs обычно называют "собственными файлами" из-за того, что они родились с этим системным предком (S/38, не уверен, что даже раньше), тогда как таблицы/представления были введены позже с SQL. Хотя в настоящее время SQE рассматривает как PFs / LFs, так и таблицы/представления в процессе оптимизации, еще одна огромная разница между ними заключается в том, что оба могут использоваться в любом SQL заявления, даже если они встроены в скомпилированные программы, в скомпилированных программах могут использоваться только PFS/LFs. Учитывая скомпилированные программы, изменения в форматах записей PFs/LFs подразумевают процесс перекомпоновки/перекомпиляции, хотя в этом нет необходимости в случае изменений таблиц/представлений, если они не упоминаются извне инструкции SQL.

наткнулся на эту дискуссию, ища что-то еще, поэтому подумал, что я внесу свой вклад. Ключевой логический файл предоставляет функциональные возможности индекса. Однако индексы работают лучше, чем логические файлы, оптимизатор запросов в DB2 для IBM i с большей вероятностью использует SQE (SQL query engine), а не более старый и менее эффективный cqe ("классический" query engine) для оптимизации запроса, если он может использовать индекс. По умолчанию индексы имеют больший размер страницы, чем логические файлы, что помогает с производительностью. В более поздних версиях операционной системы IBM i можно указать размер страницы логического файла, так что преимущество индексов не так важно, как ранее. Стратегическим направлением IBM является концентрация усилий по повышению производительности баз данных на новых объектах базы данных, определенных SQL DDL(таблицы, индексы и т.д.) и игнорировать старые устаревшие объекты, определенные DDS (физические и логические файлы.)