Вопрос больше теоретический, от любопытства. Реального ограничения скорости тут не будет.

В таблице будут храниться некие сущности.

PK_ID -> Integer, PK, Gen_ID(..., +1)
Entity_ID -> varchar до пары десятков символов, разные
Дополнительные поля.

Дополнительные поля могут меняться, при этом в таблицу дописывается новая запись и тем же Entity_ID
Но запись новых строк будет редко. И скорее всего чаще это будут новые Entity, чем изменения старых.

При этом в 90% случаев читаться будут только текущие записи, т.е. с MAX(PK_ID) для каждой Entitity_ID.
Соответсвие Entity -> Max_PK_ID можно брать из отдельной таблицы.

Есть ли разница, будет ли индекс на PK возрастающим или убывающим? IBExpert его создает возрастающим и менять потом не дает.
( Знаю, можно сначала создать индекс и потом его задействовать в ПК. Но - любопытно )

И тут возникает вопрос... Для поиска строк с большими ID вроде бы эффективнее descending-индексы (для того и нужны). По большому счёту будут читаться все записи "конца" таблицы с немногочисленными пропусками.

// "конец" в кавычках, потому что это с т. зр. величины PK и времени занесения, физически конечно может упасть в любую страницу файла.

Да и в принципе при работе в таблицах либо запрос данных равновероятно падает в любые строки от "начала" до "концу" (напр. справочники), либо более вероятно обращение к недавно занесённым строкам (ну например, при прочих равных, покупатель заходивший в магазин на прошлой неделе скорее придёт еще раз, чем покупатель последний раз бывший год назад, LRU).

То есть казалось бы для PK разумнее по умолчанию создавать desc-индексы, они как правило будут либо не хуже asc-индексов, либо лучше.

Или затраты на перестройку desc-индеков при добавлении значений "в конец" намного меньше?

Где-то вообще было сравнение, в чем по затратам на разные операции лучше asc и desc индексы? Почему именно asc выбранны по умолчанию ?

Ведь если то же соответсвие Entity -> Max_PK_ID хранить не в отдельной таблице, а в композитном индексе, то индекс (asc Entity, desc PK) будет работать лучше, чем (asc Entity, asc PK), при чтении/поиске данных среди последних записей для каждой из многих Entity ?

kdvAriochИли затраты на перестройку desc-индеков при добавлении значений "в конец" намного меньше?
как раз они выше. Добавлять-то ты будешь увеличивающиеся значения, значит в desc-индекс они будут попадать "в начало", а не в конец.

А, блин, вечер... Это и имел в виду, но описался "наоборот".

Ну мало ли, может быть там дерево индекса как-то "от середины" хранится, что новые страницы можно в оба конца добавлять.

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

В конце концов это ведь тоже общее место что как правило доступ выполняется к последним данным, а не к старым. Это и кэши всякие разные(LRU), и heap-менеджеры(infants mortality), etc.

То есть как-то кажется, что движок мог бы иметь оптимизацию именно под чтение последних данных в таблице... Или SSD редки а на разнице HDD/RAM никакая оптимизация не будет заметна ?

kdvAriochтолько текущие записи, т.е. с MAX(PK_ID) для каждой Entitity_ID.
хреновая идея, как-то странно от тебя слышать. Куда логичнее в "таблице сущностей" хранить актуальное, а в дополнительной - историю изменений. И в дополнительную лезть только тогда, когда это действительно надо.

Вообще, при разработке структуры физику лучше держать на втором плане. Модель, ориентированная на "как лучше для desc-индексов" порочна изначально.

Тут будет около десятка чтений в минуту и столько же записей в сутки.
А двумя таблицы - это дублирование как минимум структуры (если актуальные ущности в историю не входят, и всю историю соединять через вьюху с union - не люблю я почему-то union'ы подсознательно может быть зря), а то и данные тоже ( если таблица сущностей будет дублироваться как часть таблицы истории). Денормализацией немного отдает, нарушением DRY.
Оно понятно, когда ради производительности это делается.

А малонагруженные таблицы иногда можно подумать над разными изысками и заодно над внутренними механизмами.

Вот в частности, как мне кажется, может я не прав, за и против при выборе типа индексе в FAQах/доках не раскрыто. Предположить можно (я примерно так и преполагал), но именно предположить.

А уж тем более оценку при каком соотношении read/write выравниваются затраты/выигрыш от asc/desc индекса

Я же сразу написал - "Вопрос больше теоретический, от любопытства"

Ну да, в одной кривизне "ничего стращного нет" а другая кривизна - ужас-ужас

DBConstructor,

там раные entity и у каждой свой максимум

ты предлагаешь select max(pk_id)

а речь про select max(pk_id), entity_id group by entity_id

Симонов Денис,

Вот, вот ! давно надо исправить этот баг, что генераторы не видят транзакций !!!!11адынадынадын

kdv,

в общем, сам видишь, это не я такой, это погода такая