Вы только что подтвердили то, что написала во втором абзаце: «Существуют различные способы упрощения жизни при работе с иерархией...». Nested sets — один из таких способов.
Работа с иерархической структурой такая же необходимая вещь, как и с линейным списком. Практические все системы имеют такие справочники. И если вы создадите таблицу организаций, в которой укажите поле родителя, то вам тоже придётся для построения всех зависимостей обратиться к таблице деревянным запросом. И если для организаций глубина вложенности не будет особо большой (от силы порядка четырёх), то для построение структуры больших агрегатов, в которые включены более мелкие комплектующие, там глубина может исчисляться десятками.
Существуют различные способы упрощения жизни при работе с иерархией, например создать поле PATH, где будет храниться путь от корня и тогда выстроить запрос в линейный, использую оператор LIKE «1.23.%». Но это уже отдельная задача оптимизации работы с деревьями.
Думаю, вы сами себе ответили на вопрос. Если бы я хотела дать в статье сравнительную оценку быстродействия для различных серверов БД, то наверное бы так и поступила. Да и заголовок статья был бы тоже другой. Поэтому похоже, что вы заблудились в поисках недостающих знаний.
Ну если вы сами себе заказчик, тогда действительно легко))))
Начать копить на Оракле, чтобы доказать автору статьи, что его модель для вашего случая не подходит — сомнительная цель. Может быть начать с того, что определится чего вы хотите получить, а потом уже пытаться это решать. Я в статье обозначила это, а ваших комментариях я этого не вижу.
Хорошая статья, где описана работа по созданию хранилища данных.
Хочу заметить, что моя статья к хранилищу данных не имеет отношение, решается другая задача.
1. Не обобщайте. EAV был предложен исключительно для атрибутов и не более.
2. А чем так сильно увеличилась нагрузка для выборки на чтение из таблицы организации (select * from nsi_organization)?
А в чём проблема относится к таблице nsi_organization, как к nsi_item? Я показала для примера, и совершенно не утверждаю, что такоё подход нужен исключительно только для систем, где необходимо работа с организациями, подставьте на это место другой справочник, структура от этого не поменяется.
И, кстати, у вас заказчик сильно идёт на внедрение новых технологий (я имею ввиду хранилище данных)? Если да, то вам повезло))))
Вы ошибаетесь, предложенная система вообще не зависит от бизнес-логике, а содержит голую структуру. И чем она будет наполнена зависит уже от разрабатываемой системы.
Что касается EAV, то я тоже не сторонник пихать его везде, где только можно, поэтому использую его для поддержания очень незначительной функциональности. При этом я не утверждаю, что такое решение самое-самое, это одно из возможных, кто-то может предложить другое исходя из потребности системы, которую он ведёт.
Хранилище, это замечательная идея, а если к ней добавить еще Event Sourcing и CQRS, то простынки кода на поддержание этой инфраструктуры будут никак не меньше, того, что здесь описано. И выгоды по критерию «многоденег» вряд ли удастся получить.
Любая система применима к определённым условиям, и то, что вы говорите, не есть альтернатива, а просто другая потребность. Когда есть необходимость создать хранилище, тогда стоит говорить каким образом это делать.
Существуют различные способы упрощения жизни при работе с иерархией, например создать поле PATH, где будет храниться путь от корня и тогда выстроить запрос в линейный, использую оператор LIKE «1.23.%». Но это уже отдельная задача оптимизации работы с деревьями.
Начать копить на Оракле, чтобы доказать автору статьи, что его модель для вашего случая не подходит — сомнительная цель. Может быть начать с того, что определится чего вы хотите получить, а потом уже пытаться это решать. Я в статье обозначила это, а ваших комментариях я этого не вижу.
Хочу заметить, что моя статья к хранилищу данных не имеет отношение, решается другая задача.
2. А чем так сильно увеличилась нагрузка для выборки на чтение из таблицы организации (select * from nsi_organization)?
И, кстати, у вас заказчик сильно идёт на внедрение новых технологий (я имею ввиду хранилище данных)? Если да, то вам повезло))))
Что касается EAV, то я тоже не сторонник пихать его везде, где только можно, поэтому использую его для поддержания очень незначительной функциональности. При этом я не утверждаю, что такое решение самое-самое, это одно из возможных, кто-то может предложить другое исходя из потребности системы, которую он ведёт.
Хранилище, это замечательная идея, а если к ней добавить еще Event Sourcing и CQRS, то простынки кода на поддержание этой инфраструктуры будут никак не меньше, того, что здесь описано. И выгоды по критерию «многоденег» вряд ли удастся получить.
Любая система применима к определённым условиям, и то, что вы говорите, не есть альтернатива, а просто другая потребность. Когда есть необходимость создать хранилище, тогда стоит говорить каким образом это делать.