Здравствуйте, vdimas, Вы писали:
V>В классике ISAM страничный, со страницами данных, индекса, служебными и страницами переполнений.
V>Например, Berkeley DB, MS Jet DB, Informix C-ISAM, Superbase, SQLite, MySQL-MyISAM и т.д. до бесконечности — практически все сколь-нибудь популярные.
MyIsam — нет, там space management никакой. Нет ни служебных страниц, ни страниц переполнений. Словом, нихрена там нету.

V>Уверен, что в твое представление не вкладывается даже банальные записи переменной длины (классика ISAM, под записи переменной длины эта технология и была изначально разработана), бо dBase из махрового 80-го года так не умел.
Почему же, вкладывается.
V>Кароч, ISAM означает доступ к записям через индексы. Противопоставляется SQL-доступу (текстовый запрос), доступу к просто "типизированным файлам" или доступу по физическим ссылкам (непосредственным смещениям данных), как в навигационных базах.

V>Поэтому, когда я говорил об ISAM, я имел ввиду исключительно библиотечное АПИ для управления записями ISAM-хранилища, т.е. имелся ввиду бэкенд под SQL, бо сам-то SQL не нужен. Но тебе при этом "слышалась" какая-то хрень, сорри.
Ок, понятно, терминологическая путаница. В нашей деревне под ISAM всегда понимались достаточно конкретные вещи.
Если речь просто об API, который позволяет сделать SEEK или MOVE, то мои возражения — мимо тазика.

На всякий случай напомню, что обсуждение/критика началось не с ISAM вообще, а с MyISAM.
Который как раз не страничный, не блочный, с индексами в отдельном файле, и полным отсутствием поддержки транзакций.
И дело вовсе не в том, что там блокировки — на уровне таблиц, а в том, что там принципиально невозможно сделать update... update... update... update... ROLLBACK!
Некуда откатываться — ведь логгирования нету. "Зато он быстрый", ага.