lazy-beaverсамый правильный путь делать таблицы - через команду CRTPF -)))
я понимаю, что смайлик стоит, но всё же хочу уточнить, что CRTPF и CREATE TABLE создают таблицы с разным размером блока (2K vs 64K) - для больших таблиц это сказывается на количестве io

в доке лень искать - мне об этом на курсах рассказали, но это прекрасно видно в свойствах таблиц в контрол центре (да и dspfd покажет).
Та же фишка и с индексами - create index создаёт структуру с 64К блоком. Если потом пересоздать logical views, то они подхватят индекс и не будут под себя ещё дисковое пространство занимать. Соответственно чтение будет происходить более крупными блоками - часто это работает быстрее.

lazy-beaver
а чего за курсы то? от IBM?
Да, в Рочестер, штат Миннесота летал на неделю.
Курсы назывались
DB2 UDB for iSeries SQL and Query Performance Tuning and Monitoring Workshop

После этих курсов я понял, насколько IBM отстала от Оракла в этих вопросах.
Но не буду об этом - offtop.

2lazy-beaver
Меня учили на версии 5R3
Вот тут немного про разницу между таблицами и физ. файлом (стр. 18). Там много маркетинговой чуши в разделе сравнения, но это не важно.
Я забыл упомянуть такую важную деталь, как разница в чтении/записи. Для SQL таблицы валидация вставляемых данных происходит непосредственно в момент инсерта, при выборке выдаётся всё, что есть и быстро. Для Physical Files всё наоборот - вставить можно любой мусор - проверка не делается, но при выборке происходит валидация данных (что приводит иногда к интересным последствиям).
Для SQL таблиц сделали конкурентный insert (для PF все желающие вставить выстраиваются в очередь), там же разрешается автоматически реюзать освободившееся после удалений место.

2тлгдшлщм
DB2/400 позиционируется как полноценная БД, это не SQL нашлёпка для DBF файлов. Да, она слабже смотрится по интеллектуальности, по сравнению с Ораклом (то, что я знаю). У DB2/400 есть два оптимизатора - CQE и SQE. Первый - аналог Rule-based optimizer from Oracle6. Второй - новый, современный, но пока ещё совсем зелёный. Если запрос может быть оптимизирован SQE (т.е. нет union, group by, functions и прочего из длинного пока списка) - повезло - план исполнения будет хорошим, он и статистику посмотрит, и bind peeking сделает и про EVT индексы он знает. А нет - извини, будем ползать по всем индексам, даже если это не выгодно. Мы три дня на курсах изучали их поведение. Как ты понимаешь, в одном посте этого не описать.