Знаю, знаю, «тынц-тынц-тынц», этот вопрос уже обсуждался. Только обсуждение всегда сводилось к флейму с оффтопом, а статьи однозначного ответа не дают.

Вопрос встал вот почему. Спорим мы с коллегой о структуре БД. Я – «молодой», говорю – давайте возьмём EAV, сначала делать чуть сложнее, потом дорабатывать куда проще. Он – «старый и опытный», а ничего подобного, говорит, и сначала намного сложнее, и потом намного сложнее, и затрат больше на порядок, и триггеры с ХП программисты писать заморочатся. Я говорю – да делал уже, и всё удобно и без проблем, он – так то для 15 пользователей, почти прототип, а у нас будет промышленный масштаб.

Система – не бухгалтерская и не документооборот. Понятно, что взаимосвязанных структур EAV должно быть несколько.

В самой большой структуре EAV может храниться до 100 млн. «объектов», до 10 Тб. Время отклика для создания одного «объекта» – до 1 сек, подключений – до 1000, запись может вестись одновременно с 50, объёмы записи – в 90% до 10 Кб, 10% до 10 Мб. Чтение может вестись одновременно с 5 рабочих мест, кусками по 30 «объектов», время «сбора и выдачи» куска – 3 сек.

В самой «общей» структуре EAV могут храниться объекты до 50 хитро связанных между собой классов. Общий объём там до 1 Гб, но время «сбора и выдачи» 1 объекта – 0,5 сек., чтение «объектов» может вестись одновременно с 300 подключений.

Вкратце подходы EAV и ROT, как я их понимаю, описаны в прикреплённом файле.

Поделитесь, пожалуйста, следующим:

1) Правильно ли я понимаю, что такое ROT, а что такое EAV?

2) Кто-нибудь применял что-то наподобие EAV, Тенцера и иже с ним) для таких объёмов с такой нагрузкой под СУБД MS SQL 2005 или Oracle 10g?

3) Чем лучше в моём случае «собирать» объекты – сервером БД или сервером бизнес-логики? Или лучше вообще не «собирать», а хранить себе каждый класс в отдельной таблице?

4) Кто прав по оценке трудозатрат, я или он? Что легче делать и потом поддерживать - сотни таблиц или хитрые алгоритмы работы с EAV? Что более ресурсоёмко? И есть ли вообще ощутимая разница, стоит ли EAV усилий по его продвижению?

Евгений ФадеевC тем, что Вы называете EAV (я не в курсе насколько это устоявшийся термин) наедитесь так, что небо в овчинку покажется.
Впрочем первый вариант тоже несколько странноват, на мой взгляд.
Согласен, что наемся. И со вторым тоже наемся. И наедался уже, и ничего. Вопрос в том, с чем программисты больше наедятся: с первым, реализуя, расширяя и докручивая, или со вторым, добавляя по нескольку таблиц, перестраивая и тестируя при изменении и добавлении каждого класса?

А какой не странный подход? db4o и Cache? Пока считаю экзотикой.
locky
а и не может быть однозначного ответа... зависит от ситуации, когда чего
применять... у меня вон ваще получилось, что в одной базе собраны 1,2,3
НФ+ EAV - потому как так было удобнее всего с точки зрения разработки и
с точки зрения быстродействия...

Возможно, через одну-две версии, если доживёт, такое и разовьётся. Но хотелось бы начинать с чего-то одного, чтобы не делать сразу несколько вариантов логики работы. Насчёт однозначного ответа - просто в какой-то статье уже сравнивали производительность, но там совсем другие объёмы и нагрузки.

funikovyuri<...> RMD->EAV RMD->EAV EAV RMD->EAV EAV EAV RMD->сама БД. Это кстати можно делать до посинения, т.к. РМД (как и любую формальную модель) можно описать в терминах РМД и делать это рекурсивно пока душа просит!<...>
Согласен, пока архитекторы, программисты, тестировщики и DBA доступны - изменять структуру классов БД в соответствии с желаниями пользователя лучше средствами СУБД, и не надо изобретать велосипедов и наславивать лишние уровни.

А если разработчики недоступны, а пользователю надо немедленно добавить новое свойство класса и тут же начать его заполнять для экземпляров, да ещё и чтобы интерфейс соответствующим образом изменился?

Впрочем, наверное, для того, чем мы сейчас занимаемся, такое требование неактуально. А для системы паспортизации СКО, помнится, было ещё и как актуально...

Единственное, что осталось понять - как реализовать хранение исторической информации при помощи ROT? Есть ли для этого штатные механизмы хотя бы у Oracle 10g и MS SQL Server 2005, и если они есть, то насколько удобны и похожи? Буду читать...