Универсальное представление данных

Я вот проектирую для себя структуру данных для учета на предприятии и возникла интересная идея по универсальному представлению данных в некой базе данных. Фишка заключается в том, что мы разделяем представление данных в гридах, списках, лист контролах и т.п. и способ хранения данных. Визуальные таблицы данных у нас могут содержать неограниченное количество столбцов произвольного типа, а хранилище данных для любой таблицы всегда имеет фиксированную структуру в виде двух стандартных таблиц – таблицы метаданных и таблицы данных.

Первая таблица (метаданных) описывает поля таблицы данных, скажем, сотрудников (пусть это будет таблица № 10), например, в виде:

№ кол-ки Имя кол-ки Полное наим. Тип значения Длина в байтах Точность1 ПорНо Порядковый номер / индекс N 5 02 ТабНом Табельный номер N 5 03 ФамИО Фамилия И.О. C 21 04 Фамилия Фамилия сотрудника C 16 05 Имя Имя сотрудника C 12 06 Отчество Отчество сотрудника C 16 07 УкрФам Украинская фамилия C 16 08 УкрИмя Украинское имя C 12 09 УкрОтч Украинское отчество C 16 010 ИдКод Идентификационный код C 16 011 ДатаРожд Дата рождения D 8 012 ОснДатаПриема Основная дата приема D 8 013 ОснДатаУволн Основная дата увольнения D 8 014 ОснФирма Основное предприятие работы R 0 014 ОснПодр Основное подразделение работы R 0 015 ОснУчасток Основной участок работы R 0 016 ОснЧасТариф Основной часовой тариф N 9 517 ОснДнТариф Основной дневной тариф N 10 418 ОснМесОклад Основной месячный оклад N 12 2. . . . . . . . . . . . . . . . . .

(здесь N - число; C - строка; D - дата; R – ссылка, в виде номер (индекс) таблицы / номер (индекс) строки или ряда).

Вторая таблица (данных) содержит собственно данные, причем в их временном измерении. Т.е. любое поле таблицы, кроме первого, которое является ключевым индексом, может менять свое значение во времени. Если дата модификации данных не пуста, то данное поле конкретного ряда имеет новое значение с указанной даты. Поменялась дата модификации, поменялось значение. Поле вида: (Ряд, Колонка), может иметь или не иметь ссылку на строку другой таблицы, причем, в любом случае, оно представлено своим универсальным значением . Если ссылки нет, то универсальное значение это просто строковое представление числа, даты или самой строки. А если ссылка существует, то универсальное значение означает просто строковое представление (порядка 20 байтов) данного ссылочного объекта для целей сортировки .

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

Пример таблицы данных для справочника сотрудников (скажем, таблицы № 10) представлен ниже. Полагаем также, что таблица № 5 это таблица подразделений всех учитываемых в базе данных предприятий. Номера подразделений мы не описываем.

№ Ряда № Кол-ки Год модиф. Мес. модиф. День модиф. № ТаблСсылки № РядаСсылки Универс. значение. . . . . . . . . . . . . . . . . . . . . . . .1 14 5 1 ПродажОтдел1 14 2009 1 1 5 2 СнабженияОтдел1 14 2010 1 1 5 3 ВалютныхОперацийОтд1 14 2011 1 1 5 4 ТаможенныйОтдел. . . . . . . . . . . . . . . . . . . . . . . .1 18 10001 18 2009 1 1 20001 18 2010 1 1 30001 18 2011 1 1 4000. . . . . . . . . . . . . . . . . . . . . . . .

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

Таким образом, может быть описана любая таблица и даже вся база данных одним контейнером. Однако для Win32 не целесообразно объединять таблицы, так как есть ограничение на длину одного файла (2 – 4 гигабайта).

Поскольку мы имеем фиксированную структуру базы данных, полностью проиндексированную, то можно пользоваться дешевыми движками база данных, например Visual FoxPro или даже самописный движок, как у 1С77. При оптимальной организации данных, вполне можно получать приемлемые результаты для предприятий среднего уровня. Впрочем, ничего не мешает использовать промышленные сервера баз данных, например, MS SQL Server.

iscrafmEmery, а что делает таблица №6, как она выглядит?
Прикалываетесь? Ее здесь нет, хотя она будет иметь похожую структуру.

iscrafmstiавтору знакомо слово EAV?
не мешайте, он его изобретает. Только в еще более продвинутом виде.
Понимаю, что новое это хорошо забытое старое. Но многие из нас выросли из 1С-овских штанишек и ее организация данных уже всех достала.

Посмотрел только что WIKI, довольно мудреное определение, у меня вроде проще. Вот еще накручено:
http://www.askdev.ru/question/3120/Использовать-ли-EAV-модель-данных/ .

iscrafmEmeryПонимаю, что новое это хорошо забытое старое. Но многие из нас выросли из 1С-овских штанишек и ее организация данных уже всех достала.

т.е. это идея для 1С-ников? От изменения названия суть не меняется. Потому что остальные просто используют нормальную организацию данных изначально.
Идея независима от 1С, хотя может быть применена и там, если писать конфигурации самому с нуля. Я не знаю, возможно ли отвязать представление данных в 1С-овском CListCtrl от соответствующих dbf-таблиц? Если бы я мог сам наполнять содержимое этих визуальных списков (да еще в виртуальном режиме), то в 1С77 можно было бы вдохнуть «вторую жизнь» :) . Тем не менее, организацию периодических реквизитов справочников 1С лучше делать по этой схеме. Тогда для каждого 1С-овского справочника должна будет создана таблица модификации всех реквизитов, кроме ключевого кода, которая может быть пустой, если поля основных таблиц не меняются во времени.

Что касается «нормальной организации данных», то если писать независимого клиента под некоторую базу данных, то уже ничем не ограничен. Однако данная структура, которая очень похожа на EAV, хотя EAV не предлагает отслеживание полей данных во времени, лично мне кажется вполне привлекательной, чтобы поэкспериментировать с ней.

Last1Cmenвчера это поле было "видом овоща" сегодня уже "номером ТТН" а позавчера вообще "окладом"... а послезавтра наверное прийдется "курс валюты" там вести

просто замечательно и удобно потом будет генерить отчеты по такой структуре
Любое поле произвольной таблицы характеризуется своими координатами и временем модификации (если пусто, то без ограничений во времени), а также ссылкой на произвольную строку некоторой таблицы (если необходимо) и (всегда) своим 20-ти байтным универсальным (строковым) значением, используемым для сортировки. Скажем в 1С77 нельзя сортировать ссылочные объекты, так как фактически они сортируются по своему внутреннему идентификатору (36-тиричному значению), что бесполезно для практики. А у нас можно, ибо ссылка имеет еще свое 20-ти битное строковое представление.

Что касается отчетов, то не вижу никаких проблем. В своей собственной конфигурации 1С я написал собственный генератор отчетов уровня пользователя. Для этого широко использую предварительную обработку данных. Кстати, это весьма мощная идея, наряду с предварительной подготовкой (проводкой, расчетом) данных.

iscrafmдля начала ТС нужно попытаться ответить на простой вопрос: а зачем это все и что мешает сделать нормальную структуру данных?
Есть шанс упростить и стандартизировать учет на предприятии, причем на «легких» движках БД. Всех делов то, написать собственного клиента.

vadiminfoВидимо Вы не удачно сформулировали достоинства своей идеи. Поскуку все СУБД типа разделяют храннеие (физический уровень) от логической структуры, и сама РМД предполагает представления данных отличные от базовых таблиц.
Сейчас только предварительное обсуждение, позже возможна публикация статей по результатам работы.

СУБД-то разделяют, более того многие сервера БД и клиентов могут не иметь. Задача состоит в написании собственного клиента подключаемого к некой внешней БД, организованной по предлагаемому варианту.

vadiminfoВы, скорее, замахнулись на преодоление структурных ограничений РМД.
Действительно, она относится к структурированным, а Вы типа делаете некий каракас, куда моно запихнуть типа произвольные струтуры реального мира. Т.е. у Вас типа полуструктурированная МД.
На базе реляционных форматов это обычно EAV, а в более или менее по взрослому это XML, т.е. не реляционное представление, система запросров.
Какие замашки? :) Идея очень простая и легко реализуется. Возможно только некоторые нюансы возникнут при организации реальных запросов. Но ничто не помешает искать нужные решения по мере поступления проблем :) .

EAV разжевывается очень нудно. Кто не в теме не поймет. Хотя эта идея очень простая, вместо хранения редких таблиц (даже многомерных) использовать хранение только их непустых элементов в таблицах фиксированной структуры. XML хорош как переносимый формат (экспорт / импорт / пересылка по сети), но в постоянной работе его использовать невыгодно.

Начинать экспериментировать я собираюсь на самопальном «движке» типа «1C Database Engine for .DBF, .CDX» (файл dbeng32.dll, размером всего 143 Кб), затем VFP Runtime, а потом уже можно будет пробовать платные и бесплатные sql сервера.

vadiminfoСмотртите, как проектировщик, Вы должны следовать неким типа критериям: простота, структурное соотвествие предметной области структурнам БД. Это Вы утрачиваете: у Вас структура это всего две таблы, не соотвествущеие реальному миру: одна описание данных, вторая типа аудита что-то. А выковырять структуры сущностей реального мира из них есче нуно. Причем с промощью реляционной системе запросов, поскоку сруктура рел формата. А ить простота извлечение инфы важнейшая цель сроздания БД. А бывают сложные запросы и для нормальной БД, а Вашей это все тока много усложнится. Навязывать ОЦ тоже стремней. Ить Вы остались в рамках реляционных средств.
Потому, раз Вы чувствуете в себе призвание, то, возможно, стоит сосредолточиться на решениях в корне отличных от РМД.
Опыт внедрения реальных конфигураций (100% собственных) на предприятиях у меня есть. Поэтому я не вижу никаких принципиальных трудностей (хотя это и не означает, что они не появятся в дальнейшем :) ) в реализации данной модели (адаптированной EAV). Ведь все поля предлагаемых таблиц будут проиндексированы. А любой SQL держится, по сути, на индексах. Только у нас, в силу фиксированности структуры БД все должно быть существенно проще.

iscrafmEmeryЕсть шанс упростить и стандартизировать учет на предприятии, причем на «легких» движках БД. Всех делов то, написать собственного клиента.
к некоторой схеме данных вы добавляете, дополнительно, еще одну. И для нее предлагаете специализированного клиента, который будет это интерпретировать. В чем упрощение?
Как раз клиент должен быть универсальным. Существует множество универсальных серверов БД, но я не знаю, подходящих для меня, универсального клиента БД. Как вариант, я вижу подобного клиента написанного на MFC или Qt, так чтобы я мог легко конфигурировать пользовательский интерфейс (лучше, чем в 1С77) и самостоятельно обрабатывать сообщения вроде LVN_GETDISPINFO, LVN_ODCACHEHINT, LVN_ODFINDITEM и т.п., как для контрола SysListView32 . А уж функцию доставки данных можно уже реализовать вне клиента, на стороне сервера БД. Как идея, можно попробовать перехватывать данные уведомления в самой 1С77 и реализовывать отображение данных в списках только динамически . Тогда и «семерка» будет достойным кандидатом для экспериментов :) .

Last1CmenEmeryЧто касается отчетов, то не вижу никаких проблем. В своей собственной конфигурации 1С я написал собственный генератор отчетов уровня пользователя. Для этого широко использую предварительную обработку данных. Кстати, это весьма мощная идея, наряду с предварительной подготовкой (проводкой, расчетом) данных.

очень легко и просто вместо select sp358 from ra123 будет писать

select case when сm.sp36 between @NPeriod_1 and @KPeriod_1 then sp358 else sp89 end from ra123 (это если две модификации)

я просто предвкушаю себе удобство разработки и главное "сопровождения" в такой среде :)

в принципе как шаблон-конструктор для разработки некой начальной базы под конкретное решение идея имеет смысл быть но "только толкнули" сразу надо от неё уходить в область более-менее фиксированных структур с таблицами "по назначению"
Не понимаю, о чем Вы? Например, мой движок расчета заработной платы (из первичных табелей 1С77 во вторичные) реализован на VFP, который «общается» с «семеркой» как с DDE сервером. Чтобы избежать использования «неудобных имен» я автоматически сгенерировал VFP модуль типа:


и пользуюсь себе удобными именами без проблем :) .

alneoИерархические БД?
Пример для учета на предприятии можете привести?

LSVЕдинственная проблема, ИМХО - производительность будет посредственной.
Производительность это, прежде всего, вопрос организации самих данных и доступа к ним. А идеи тут могут быть разные. Например, очень помогает предварительная обработка данных, «правильная» индексация и ее использование, собственно структура БД и т.д. Эта тема «вечная» :) .

guest_20040621Просто потрясающе, насколько одинце сносит башню. :( На мой взгляд, Emery, изначально кривые идеи нет смысла тиражировать.
Троллинг?

vadiminfoEmery,
Я лишь хотел, чтобы Вы более критично относились к простеньким идеям.
Лучший критерий истины - практика :) .

guest_20040621> Троллинг?

Нет. Четкая последовательная позиция. Полистайте форум.
А почему шифруемся?

Программист-ЛюбительEmeryЛучший критерий истины - практика :) .
"Нет ничего практичней хорошей теории"
Как говорил декан одного физфака: «Дайте мне любую теорию, а эксперимент мы подгоним» :-) .

SERG1257EmeryЛучший критерий истины - практика :) . Ссылочной целостности нет, уникальности на уровне БД нет, запросы сложные донельзя см пост Last1Cmen
Да, все значения проиндексированы, но простая выборка одной строки размазана по всей таблице V (значения)
Ну, вообще-то, главная проблема в отсутствии универсального клиента, а не в организации доступа к данным. И кто нам мешает использовать для универсального клиента промышленные базы данных? Например, Вам не нужна история модификаций данных, а мне «ссылочная целостность» и «уникальность на уровне БД». За сложность запросов я также не переживаю, если я все контролирую, то и запросы оптимизирую под себя. Я ведь не средство разработки предлагаю, а конечное решение, конфигурацию, в терминах 1С. Причем, в этом случае нет необходимости в пользовательском творчестве по построению изощренных запросов. А все прогнозируемые, фиксированные запросы всегда можно свести к простому доступу по нужному индексу или группе индексов.

SERG1257Emeryпричем в их временном измеренииБесплатных ланчей не бывает, а если не нужно хранить историю?
Нет проблем, три поля по одному байту всегда будут пустыми и общих записей будет меньше. Так что не большая цена :-) .

БредятинаEmeryЯ вот проектирую для себя структуру данных для учета на предприятии и возникла интересная идея по универсальному представлению данных в некой базе данных.
И Вам нужно посмотреть модель TransRelational Стива Тарена, чтобы быть, все-таки, в курсе того, что делается в этой области - в области хранения, а не представления, как Вы выразились, данных в БД [U.S. Patent and Trademark Office: Value-Instance-Connectivity Computer-Implemented Database. U.S. Patent № 6009432, 28.12.1999; для простого понимания см. Приложение 1 у Дейта]. Может тоже патент получите:)
Спасибо за информацию! Только на патент данная идея не тянет, т.к. подпадает под довольно широкое определение EAV. Только у меня более конкретно, а у них более абстрактно, хотя для посторонних их идея малопонятная. Тем более, какие патенты в Эпоху Перемен? :-) .

Однако куда более актуальным является вопрос «идеального» клиента. Армия программистов со всего мира, пишет все, что угодно, кроме очень востребованного универсального клиента для различных серверов БД, так чтобы можно было контролировать процесс обмена данным между сервером и клиентом.

БредятинаEmeryВедь все поля предлагаемых таблиц будут проиндексированы.
А в TR индексы вообще не нужны:)
Выходит, что не нужны, по крайней мере, для тех задач, которые я решаю.

БредятинаEmeryА любой SQL держится, по сути, на индексах.
Индексы не имеют никакого отношения ни к SQL, ни к РМД.
Очень даже имеют, только движок БД скрывает это от пользователя, а если очень нужно, то сам индексирует, никого не спрашивая.

БредятинаEmeryТолько у нас, в силу фиксированности структуры БД все должно быть существенно проще.
Скорее, наоборот. "Не фиксированная" структура вообще никак не усложняет работу с данными. А вот фиксированная, скорее всего, усложнит:)
Типичное разночтение в терминологии :) . Мои собственные конфигурации в 1С77 и проще и эффективней стандартных, хотя сделаны по принципу «1С – Несовместимо!» :) . Там у меня «фиксированная» структура, пользователь работает только с настройками. А если вместо клиентской части 1С77 написать собственную, то будет еще более эффективное решение, даже на «легких» движках БД.

БредятинаEmeryНет проблем, три поля по одному байту всегда будут пустыми и общих записей будет меньше. Так что не большая цена :-) .
Еще какая проблема:) Во-первых, цена приличная, а, во-вторых, какие еще байты у пустых полей? Это вообще прошлый век в хранении данных:)
Имеется в виду ширина полей в байтах. Значения могут быть либо пустыми (символ «пробел»), либо символом нуля («0»), так как поля даты модификации строковые. Впрочем, символ с кодом NULL тоже допускается.

Три байта на миллион записей, дадут 3 мегабайта пустых данных. Это что проблема в эпоху терабайтных винтов?

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

БредятинаEmeryОднако куда более актуальным является вопрос «идеального» клиента. Армия программистов со всего мира, пишет все, что угодно, кроме очень востребованного универсального клиента для различных серверов БД, так чтобы можно было контролировать процесс обмена данным между сервером и клиентом.
Под "идеальным клиентом" можно понимать только полностью управляемый пользователем интерфейс. А для этого нужна семантическая модель. Способ хранения не имеет к этому никакого отношения:)
Так я и пишу: «чтобы можно было контролировать процесс обмена данными между сервером и клиентом». И речь мы сейчас ведем о клиенте, а не о сервере. С серверами БД проблем нет, они уже давно решены. А вот проблемы с «полностью управляемым пользователем интерфейсом» остались, хоть с «семантической моделью», хоть без нее :) .

БредятинаEmeryОчень даже имеют, только движок БД скрывает это от пользователя, а если очень нужно, то сам индексирует, никого не спрашивая.
Индексы не имеют никакого отношения ни к SQL, ни к РМД. Это же факт:) А вы говорите о неудачных реализациях, которые что-то скрывают:) Вот когда тоступ к индексу обеспечивается в терминах модели данных, тогда, конечно, имеют отношение.
Тогда объясните мне, как делается запрос на выборку одного уникального элемента из базы, содержащей сто миллионов записей? При условии, что критерий поиска не индексирован. Обычный scan?

БредятинаEmeryТипичное разночтение в терминологии :) . Мои собственные конфигурации в 1С77 и проще и эффективней стандартных, хотя сделаны по принципу «1С – Несовместимо!» :) . Там у меня «фиксированная» структура, пользователь работает только с настройками. А если вместо клиентской части 1С77 написать собственную, то будет еще более эффективное решение, даже на «легких» движках БД.
Никакого разночтения нет. Расширяемая, в том числе пользователем, структура никак ничего не может усложнить, даже теоретически:) А "фиксированная" структура, скорее всего, усложнит. Как и "фиксированная" структура холодильника или шкафа:)
Лично я сыт по уши расширяемыми средствами разработки. Что хорошо программисту, то юзверю «смерть» :) . Особенно, если предлагаемые решения представляют собой полуфабрикат, сделанный по принципу, «нам с этой программой не работать». Чем грешит, пресловутая «1С». Мои пользователи работают на моих конфигурациях и горя не знают, а десяток различных перепробованных стандартных решений для 1С вызвали категорическую реакцию бухгалтеров: «То, что могут делать эти конфигурации, нам не нужно, а то, что нужно, они не могут». Про неудобство работы с ними и избыточную трудоемкость я вообще молчу. Так что мы ведем достаточно беспредметный спор, так как исходим из разного контекста и собственного опыта.

guest_20040621> А почему шифруемся?

Ни разу. Вы, наверное, просто недавно здесь.
Вы прячетесь за анонимным логином. Ни профиля посмотреть, ни количество Ваших сообщений. У меня эта информация доступна.

guest_20040621> Мои собственные конфигурации в 1С77 и проще и эффективней стандартных

В данном случае опыт играет отрицательную роль. Попробуйте забыть про одинце - вы поразитесь, настолько много интересных решений вокруг.
Меня интересует универсальный клиент с конфигурируемым интерфейсом, виртуальным режимом для контрола списка / грида, типа как для SysListView32, поддержка групп, возможность привязки к дереву, типа SysTreeView32, перехват сообщений виртуального режима. Что можно взять из Вашего множества «интересных решений вокруг» для этих целей?

БредятинаEmeryИ речь мы сейчас ведем о клиенте, а не о сервере. С серверами БД проблем нет, они уже давно решены.
В этом и заключается самая большая проблема:) Ваша и Вашего подхода. Непонимание огромных проблем серверов БД, ориентированных на не эффективные модели данных:)
Вы знаете мои проблемы лучше меня :) ?
Мои модели реально работают и фактически кормят меня. Я знаю, как еще улучшить их работу. Но мне нужен универсальный (идеальный) клиент. Я могу и пытаюсь писать его сам. Но это отнимает много времени. Начнем с того, что нет 100%-но подходящего грида / списка. Затем нет хорошего конфигуратора интерфейса, «отвязанного» от источника данных. Меня не устроит любой грид. Лучший, из бесплатных с исходниками, что я знаю, это грид Криса Маудера (Chris Maunder). Затем идет грид Алькса (ALX или Алексей Долгачев), затем различные расширения CListCtrl (SysListView32), вроде GfxList. Грид Алькса не поддерживает виртуального режима и групп. Грид Криса Маудера поддерживает виртуальный режим, но не поддерживает групп. SysListView32 очень хорош, но имеет скрытые параметры (т.е. намеренные ограничения для пользователя), Кроме того, для SysListView32 нужно самому писать инлайн редактирование. И так далее, подходящий грид найти очень сложно. А то, что нравится одним, может не понравится другим. Пока я юзаю SysListView32, особенно мне нравится этот контрол из Win7, но он не работает под ХРюшу. Несмотря на то, что примеров реализации инлайн редактирования существует много, реализованы они неудовлетворительно для меня. Как говорят, если хочешь, чтобы работа была сделана хорошо, нужно делать ее самому. Вот и занимаюсь списком SysListView32, вместо того, чтобы писать бизнес приложения :) .

Tolkaзачем для определения "историчности" записи заводить 3 отдельных поля? Кто-то когда-то будет задаваться вопросом, покажи записи, которые менялись по вторникам? Достаточно одного простого date поля
Чтобы ответить на Ваш вопрос, достаточно вести логгирование (журналироваие) изменений базы данных. История нужна, чтобы отслеживать, скажем, факт того, что Иванова, после замужества, стала Петровой, а кто-то может быть вообще пол сменил :) .
У сотрудника одновременно может быть несколько назначений, табельных номеров, графиков работы и т.д. Один, из которых, считается основным (для вывода информации в отчетах по сотрудникам). Те, кто на подмене, в разные периоды времени должны отображаться в разных подразделениях, и т.д. и т.п. Очень полезно такие реквизиты делать периодическими, что удобно для отслеживания, скажем, нескольких приемов увольнений в данную контору. Я не знаю случая из своей практики, чтобы нужна была история модификаций полей данных с точностью меньшей, чем сутки. Может быть Вы, к примеру, на почасовой оплате, когда Ваша ставка с 8:00 до 10:00 утра была одна, с 10:00 до 12:00 другая, а ближе к вечеру третья. И нужно составить отчет по сотрудникам, упорядоченный по размерам их ставок на время 12:30. Если нужна такая точность, то придется, конечно, вводить кроме даты еще и время модификации поля данных. Только сомневаюсь, что такая точность будет реально востребована. Даже когда человек работает посменно, и его смена переходит с одного дня на другой и в этот день ему повысили зарплату, то вряд ли потребуется точность фиксации повышения оклада с точностью до полусмены. Так что любая база данных всегда не абсолютна и очень часто компромиссна между желанием учесть больше информации и возможностью ее обработать и хранить. Я обычно ориентируюсь на реальную обстановку с небольшим запасом.

Что касается трех однобайтовых полей для даты модификации. Это сделано для удобства составления запросов. С атомарной информацией легче работать и меньше делать различных преобразований.

TolkaА что если нужна и история и быстродействие?

В EAV мы получаем развёртку сущностей по полям Nсущ*Nполей. А у вас, насколько я понял, получается Nсущ*Nполей*Nист...

берём среднюю таблицу с данными на несколько миллионов. Сущность имеет 20 атрибутов и 10 исторических записей. Получаем 10^6*20*10 = 2*10^8 = 200 млн записей...

как будет работать?

теперь принимаем, что у одной сущности один из строковых атрибутов, скажем 10 символов, а у другой - 100, а у третьей - 500. И все они славно так проиндексированы одним индексом. Какой индекс будет работать быстрее? По 200 млн записей и средней длине 250 символов или по 3 миллионам и средней длине 10 символов?
Неправильно так перемножать. Возьмем для примера «плоскую» таблицу сотрудников. Ввод времени модификации делает ее формально «трехмерной». Только «третье» измерение будет очень редким. Скажем, та же Иванова стала после замужества Петровой, а затем, после второго замужества, Сидоровой. Это дает только две дополнительные записи к «плоской» таблице сотрудников. Далее, пусть Вася Пупкин три раза принимался на нашу работу и два раза увольнялся. Это дает дополнительно еще 3 записи. И так далее. Т.е. для редкой истории (не зря фирма «1С» называет справочники «условно-постоянной» информацией) «третье измерение» не перемножается, а суммируется. Там же, где фиксируются операции и на их основе документы, может потребоваться учет до минуты. Но это будет учет не в «третьем измерении», а во «втором». Документы не должны содержать периодических реквизитов. После их проведения, все ссылки замещаются их значениями на время проведения и данные документов фактически замораживаются. Другое дело, если Вы делаете перепроведение. Тогда данные могут «разморозится». Т.е. «трехмерными» могут быть только первичные таблицы (справочники или таблицы определений), а документы (вторичные таблицы – таблицы операций или таблицы отношений) всегда должны быть только «плоскими».

Tolkaа про универсальный клиент вообще не въехал...о чём разговоры

это драйвер или гуи? Если гуи, то какое отношение он имеет к структуре базы?
«Универсальный клиент» это конфигурируемый интерфейс представления данных без привязки этих данных к источнику данных. Обмен данными между Сервером БД и Универсальным Клиентом должен программироваться «вручную» и в принципе не должен зависеть от Сервера БД. Т.е. программист сам делает запросы к Серверу БД на основе уведомлений (желательно) виртуального режима представления данных Универсального Клиента. Где-то так :) .