Siemarglopendsa,

Это слишком глобальный подход ))

JSON структура проще. Линк

Проще пока, у вас не стоит задача группировки множетсва обьектов в разрезе свойств.
Или сортировки .
Или связи обьектов разных типов по критерию одинаковых( или удовлетоворяющих условиям попадания в новое множество) свойств.

Siemargl
Для этого есть зависимые множетства
и индексы, которые по сути являются тоже множествами объектов типа "ссылка на объект"


Если ACID на них распостраняется так же как и на обьекты, то не вопрос.
То есть версия узла( листа) индекса,
должна соотвествовать версии обьектов на которые они ссылаются.

Хотя запуск ссылки в космос ( в С++ ) в отличии от указателя невозможен,
а невалидность ссылки можно получить аж на расс, и самое неприятное,
что бороться с невалидными ссыками практически невозможно.

То есть для предсказуемого поведения это должно быть аналогом сурагатного ключа в RDBMS.

Думаю что в конечном итоге мы перейдем к нормализации отношений, а потом и другим аспектам RDBMS,
и ваша базы станет RDBMS базой.
Все к этому идет :)

Siemargl

Объекты тем и хороши, что от нормализации до определенных, но широких пределов можно совсем отказаться. Это не очень хорошо с точки зрения архитектора, но архиудобно с точки зрения разработчика ;-)


ИМХО тупиковый путь.


Siemargl
Например объект, невозможный при нормализации
{
"queriues":[ 1, 2, ...., 1000000],
"buyerName": [ "Иванов", "Васильев", ....."1000000й покупатель"],
"buyAmount": [ 230, 160, ....., 12]
}
Вполне может спокойно обрабатываться и расти в размерах (утрирую немного) ))))


И какую полезную ( бизнесс) нагрузку несет объект именно в таком виде?

Это вы называете объект , на самом деле это набор множеств.
Если будет стоять задача на этот набор множеств, наложить другой набор,
то оперирование наборами ( разностями и пересечениями) усложнится в соотвествии с

опять о конечных автоматах
количество состояний.......растёт экспоненциально с ростом количества состояний исходного НКА


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

Это возможно не самая лучшая абстракция для постороения схемы хранения и обработки,
но самая надежная , предсказуемая и математически обоснованная.

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

И я, например, не стану жертвовать ею, ради других возможно более интуитивно понятных
с точки зрения хранения и обработки инструментов, но не позволяющих
получить соизмеримую предсказуемость конечной системы.

ps Предсказуемость = производительность=стоимость владения.
"=" = соизмеримо( находится практически в линейной зависимости).

Siemargl

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


Что значит неудачную нормализацию?

Возможно тот кто смотрит на данные по другому,
как раз и нарушает логику заложенную архитектором?
Зачем ставить преграды в направлении в котором должна развиваться система.
Если преграды стоят, значит система не должна в этом направлении развиваться.

Другое дело выяснить причины, почему такое ограничение было установлено
и поменять правила, но ни коем случе не отменять.
Отмена ограничений это путь к бесконтрольной непредсказуемости ситемы,
Тут нужна оценка количества и причин возникновения инцидентов ,
приводящих к попытке нарушения ранее установленной логики.



Siemargl
Кстати пример - OLAP - задача, неудобная для нормализации. И мой пример с объектом-массивом выше, хотя в целом и неудачный, тут может быть выгоднее (и в скорости и в удобстве обращения).



ОЛАП не рождается на ровном месте,
есть некие логически связанные данные( множества),

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

ОЛАП очень даже удобный инструмент в понимании какие степени сободы важны а какие вредны, где нормализация нужна, а где вредна.
Если какието текущие аспекты обрабоки данных, отражающих какие либо реальные процессы
, противоречат логике, то это только повод задуматься.
На каком уровне решать проблему( хранения, обработки, или выгнать нерадивого сотрудника) нужно смотреть
по совокупности.

По сути ОЛАПу абсолютно паралельна нормализация( есть она или нет),
но это не повод от нее отказываться в принипе.

зы Начинается философский офтопик, давай его не продолжать.

Siemargl


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



А как же ОЛАП ?

В общем виде он должен дать возможность оценки от группировки в 1 результирующую запись,
до декартового произведения.

Тем самым ты себя ограничеваешь там, где этого делать не нужно .

ОЛАП - это универсальное средство работы над ошибками в понимании логики реальных процессов,
которые отражены в виде хранимых данных.

В общем виде конечная цель хранения и обработки данных это
управлять и предсказывать поведение(м) реальных процессов.

Siemargl

А ведь лишние измерения (таблицы) нужно тоже обслуживать - джойны, индексы, целостность ключей, кэш, безопасность.


За универсальность нужно платить,
Единственное с чем могу согласиться, это подход к безопасности.

Все прочие универсальность RDBMS окупает с головой.


Siemargl
Даешь нормализацию, но сложных объектов! =)


Любых, но там где она действительно нужна и не противоречит логике попадания данных в систему
для дальнейшего анализа ( загрузки в ОЛАП).
Соблюсти баланс попадания данных в систему( на хранение),
и при этом не противоречить логике ( правилам) обработки, это глобальная(стратегическая)
тема над которой я думаю.

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