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

http://www.cs.cmu.edu/~natassa/aapubs/conference/storage%20model%20to%20bridge.pdf
The traditional data placement scheme used in DBMSs, the N-ary Storage Model (NSM, a.k.a., slotted
pages), stores records contiguously starting from the beginning of each disk page, and uses an offset (slot)
table at the end of the page to locate the beginning of each record.

Мне это напомнило анекдот "шел ежик, забыл как дышится, и умер".
И правда, работаю с СУБД уже 20 с лишним лет, но только узнал, что массовая модель хранения называется NSM. Стало мне хуже или лучше? Не знаю.

Читаю дальше
As an alternative, the decomposition storage model (DSM) [5] partitions an n-attribute relation vertically
into n sub-relations, each of which is accessed only when the corresponding attribute is needed.
опа. Это же как в Sybase IQ. Ладно, про такую модель я тоже знаю с конца 80х, даже участвовал (в начале) разработки одной такой.

ну, в тексте потом
This paper introduces Partition Attributes Across (PAX), a new layout for data records that combines
the best of the two worlds and exhibits superior performance by eliminating unnecessary accesses to
main memory.
и т.д., но можно для интереса почитать.

Кстати, че-то я в PAX засомневался. Когда просто столбец надо вытащить, вроде как должно быть быстрее, но один хрен, количество IO, т.е. считываемых страниц с диска, для NSM и PAX будет одинаковым. И, насколько я знаю прикладные задачи, народ обычно тащит на клиента почти всю запись целиком. Также, мне кажется что PAX будет больше жрать процессор, хотя х.з.

Ну а про Clotho storage model (также со ссылками на NSM и DSM) - тут
http://www.vldb.org/conf/2004/RS18P4.PDF

и тут уже пишется что PAX для DSS задач с базами в памяти - фигня. В общем, развлекайтесь :-)

В каких СУБДВо, ну хоть кто-то знает это :)
я не знал аббревиатур, и мне было по барабану. При этом я абсолютно в курсе как хранятся записи на страницах в NSM и DSM.

В каких СУБДТ.е. DSM это чисто column-oriented?
получается, да.

В каких СУБДPAX это что-то типа кластерных таблиц Oracle?
Или можно в двух словах об этом PAX и хоть где-то оно применяется, а то абстрактное описание
в характеристиках самой СУБД, если она "общего назначения", а не какая-нибудь in-memory и т.п., практически никогда не указывают как именно там данные на страницах хранятся, потому что большинству людей это до лампочки.
Русскоязычным я вижу, это тем более до лампочки, потому что большинство статей об этом на английском.
Например, вот тут написано, что якобы есть и гибриды таких баз, но по названиям я их слышу впервые.

Кстати, еще одна статья про PAX
http://research.cs.wisc.edu/multifacet/papers/vldb01_pax.pdf
тех же авторов, только чуть побольше данных, показывает что по производительности PAX близко к DSM, и PAX быстрее NSM только в конкретных случаях. Есть там и свои подводные камни.
И, насколько я понимаю, редко какая популярная СУБД использует описанный в этих статьях NSM в голом виде. Там обязательно какие-то добавки, при которых PAX в том же "чистом" виде может быть и не нужен. Хотя PAX, как утверждается, улучшает использование CPU относительно NSM.

И, да, в том числе
http://dbmsmusings.blogspot.com/2009/09/tour-through-hybrid-columnrow-oriented.html
Oracle 11g release 2 "использует хранение данных столбцами для сжатия", и т.д.
Там же, кстати, и про недостатки PAX. Вкратце - то, что казалось выгодным на процессорах и задачах 2001 года, уже не так эффективно на нынешних процессорах.
И т.д. Читайте на английском.

kdv,

"по производительности PAX близко к DSM" - к NSM. DSM сильно отстает по времени вставки данных.

короче, все это меняется сейчас настолько быстро, что представляет разве что академический интерес.

в мини-страницах,

чего там понимать-то, столбцы, конечно. С картинками все расписано. Сравните Figure1 и Figure2 в первом pdf, на который я ссылку дал (A Storage Model to Bridge...).

мини-странице,

в реальной жизни все сложнее и не так. Например, для примера страницы PAX с Figure2 совсем не нужна там заголовке информация о размере столбцов, потому что она и так есть в описании метаданных (или обязана быть). Наоборот, в дополнение, может быть другая информация, которая относится к транзакциям и еще чему-то.
Вот например, DSM структура страниц Firebird (см. Data Page)
тут с картинками и в общем -
http://www.ibphoenix.com/resources/documents/design/doc_19
здесь без картинок, но подробно
http://www.firebirdsql.org/manual/fbint-page-5.html

как минимум, другое направление оффсетов на записи и самих записей (не сверху вниз, как на Figure1 в примере DSM, а снизу вверх), и т.д.
Учитывая, что для одной таблицы и на одной странице данных у Firebird могут лежать записи разных форматов, да еще и упакованные, Firebird-у "не светит" структура PAX. Впрочем, это мое предположение. И надо посмотреть, что изменилось в формате Firebird 3 в этом плане (скорее всего ничего).

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

мини-страницеХм, а мне казалось что в Firebird модель хранения NSM.
она и есть NSM. никто же не заставляет следовать на 100% вот той картинке, которая в статье. Это же обобщенная схема, для понимания.

мини-страницеЭто если конечно длины фиксированные, а не varchar2 :)
у Firebird размер записи не фиксированный. Во-первых, в char и varchar хранятся только данные, а во-вторых, запись упаковывается.
И ничего, одних оффсетов на начало каждой записи вполне хватает. В самой записи - да, длина данных каждого столбца хранится, но иначе ее раскрутить нельзя. Не было бы сжатия, то длину нужно было бы хранить только для char/varchar, и опять же, в самой записи. В PAX хранятся оффсеты на варчары, точно так же как на "записи произвольной длины".
В общем, в схеме PAX в статье размеры данных - это тоже иллюстрация. В реальной БД эта информация будет вычитываться один раз при чтении описания метаданных таблицы (формата столбцов и их длин).

мини-страницеНе совсем понял, что вы имели ввиду?
описка была. Разумеется,
NSM - "позаписная" структура
DSM - столбцовая структура.

Столбцовые нынче редкость. Одна известная мне DSM - Sybase IQ.
Firebird - NSM, что явно видно из всех картинок, которые я дал.