Поскольку некоторые серверы / языки программирования b-tree, используемые до сих пор, используют плоские ascii-файлы фиксированной или переменной длины для хранения данных. Когда новая запись / строка данных добавляется в файл (таблицу), запись (1) добавляется в конец файла (или заменяет удаленную запись) и (2) индексы уравновешиваются. Когда данные хранятся таким образом, вам не нужно беспокоиться о производительности системы (в том, что делает сервер b-tree для возврата указателя на первую запись данных). Время ответа зависит только от количества узлов в ваших индексных файлах.
Когда вы начинаете использовать SQL, вы надеетесь, что поймете, что производительность системы должна учитываться всякий раз, когда вы пишете оператор SQL. Использование оператора «ORDER BY» для неиндексированного столбца может поставить систему на колени. Использование кластерного индекса может привести к ненужной нагрузке на процессор. Это 21-й век, и мне бы хотелось, чтобы нам не приходилось думать о производительности системы при программировании на SQL, но мы все еще думаем.
В некоторых старых языках программирования было обязательным использование индекса при получении отсортированных данных. Я только хотел бы, чтобы это требование было все еще в силе сегодня. Я могу только удивляться, сколько компаний обновили свои медленные компьютерные системы из-за плохо написанного оператора SQL для неиндексированных данных.
За 25 лет программирования мне никогда не требовалось хранить физические данные в определенном порядке, поэтому, возможно, именно поэтому некоторые программисты избегают использования кластерных индексов. Трудно понять, что такое компромисс (время хранения, время извлечения стихов), особенно если разрабатываемая вами система может когда-нибудь хранить миллионы записей.