Обсуждение вертикального хранения в фидо 4 года назад
Даже скопирую сосбтвенный мессадж для ленивых
1. Общие мысли, не в плане критики Вас лично или статьи, просто наболело.
Думаю, что не открою ни для кого секрета в эхе, что в структуру типа:
Сущности(ID_сущности, Название_в_предметной_области)
Атрибуты(ID_сущности, ID_атрибута, Название_в_предметной_области)
Экземпляры(ID_сущности, ID_Экземпляра)
Значения(ID_сущности, ID_Экземпляра, ID_атрибута,
Дата_установки/изменения_значения, Значение_с_указанной_даты)
можно впихнуть все (или почти все) объекты реального мира с историей их
изменений.
Для получения информации из такой структуры будет достаточно даже начального
уровня стандарта SQL.
Вопрос. Какая модель данных и ее физическая реализация это потянет?
Вопрос не праздный. Стремление к подобным решениям наблюдаю уже лет 5, в том
числе и сам принимаю участие в той или иной степени. Упираемся в
неоптимальность реляционки для таких решений, оно и понятно. Но непонятно,
почему в других моделях должно быть лучше. Упираемся в необходимость
абстрагироваться от источников данных и в приводящую в этом случае нужду
изобретать аналог SQL для данных в "среднем слое" и сопутствующие проблемы.
По крайней мере, пока слышны (и в этой эхе) лишь маркетинговые доводы, вроде
возьмите Cache и все у вас заработает.
Очень хочу видеть ссылки на реально сделанные по такой схеме проекты ("1С" -
это антитезис, не приводите)!!! Не важно на чем, хоть на фокспро, хоть на
доморощеннной СУБД, хоть на жабе, главное, чтобы работало в промышленном
режиме.
Вопрос не менее интересный: почему при таком очевидно простом решении (4
педали и пара рычагов) никто за 30 лет не добился промышленных результатов?
Иными словами, почему мы до сих пор сидим на реляционке, если все задачи
решаются четырьмя сущностями?
2. По статье, очень бегло.
2.1. Модели и так отделены от средств реализации. Но это не значит, что
данная модель будет одинаково хорошо реализована разными средствами.
2.2. "Блочный" подход в стиле hardware-компонентов тоже не стал панацеей,
хотя и занял свое место. Тому есть несколько причин:
(1) в hardware имеем прохождение сигнала со скоростью тактовой частоты
(цифра) или света (аналог), в то время как в software время отклика на
выходе практически всегда зависит от поданной на вход информации.
(2) число возможных состояний конечного автомата в не самом сложном
бизнес-software-компоненте на порядки выше, чем в hardware-микросхеме.
Протестировать все состояния не представляется возможным за разумное время.
А если возможно, то это относительно простые компоненты вроде вычисления
математических функций или STL, для которых, опять таки, верен п(1).
Таким образом, собрав из кучи микросхем устройство мы уверены, что оно будет
работать с единой тактовой частотой. Собрав из кучи компонентов программу мы
не можем даже приблизительно оценивать время отклика на выходе.
2.3. "Прошло время программ - "черных ящиков с большой красной кнопкой" -
это противоречит принципу инкапсуляции. Она - как беременность, либо есть,
либо ее нет.
--
Открытая SmallERP / Архитекторы программных систем 
