|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
tip78разделить данные на постоянную часть (условно, таблица CLIENTS, на которую завязана бизнес-логика) и динамическую (условно, таблица CLIENTS_ADDITIONAL_FIELDS, на которую ничего не завязано) ? и подкладывать из отдельной таблицы какой-нибудь JSON/XML с доп.полями? Ну лично я имею в виду A+ES, все изменения данных через события, в РСУБД генерируются таблицы из событий. Но можно и ещё 50 разных способов и подходов расмотреть. Я бы не делил динамическую и статическую часть. Так как с развитием они начнут перемешиваться. То, что раньше казалось не важным и легко в динамику, легко может стать существенно важным, а переносить в статику, это довольно серьёзное изменение. И следить за двумя кусками одни и тех же данных (бизнес не различает «статику» и «динамику») -- усложнять жизнь в дальнейшем. Но это ИМХО. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 15:05 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
tip78читал эту тему , никуда там так и не пришли... Хз насчёт темы, у нас в текущей систему динамически создаётся и ведётся системой 100% таблиц в РСУБД. И все счастливы. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 15:05 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVostttip78читал эту тему , никуда там так и не пришли... Хз насчёт темы, у нас в текущей систему динамически создаётся и ведётся системой 100% таблиц в РСУБД. И все счастливы. а пример можете показать? или ссылку мы сейчас говорим про саму архитектуру данных, или что за "динамические колонки" ? так то джойнами мы тоже получаем 100% динамические таблицы... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 15:26 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
tip78а пример можете показать? или ссылку мы сейчас говорим про саму архитектуру данных, или что за "динамические колонки" ? так то джойнами мы тоже получаем 100% динамические таблицы... Вы попробуйте на EAV построить более-менее сложный копоративный отчёт, где присутствует не только фильтрация, но и группировки, подзапросы, drilldown, и т.д. К слову, на JSONB ситуация будет ещё печальнее, придётся городить кучу вьюх и поддерживать их, и это будет прибито намертво ржавыми гвоздями к конкретной СУБД и конкретной её версии. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 15:36 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVostttip78а пример можете показать? или ссылку мы сейчас говорим про саму архитектуру данных, или что за "динамические колонки" ? так то джойнами мы тоже получаем 100% динамические таблицы... Вы попробуйте на EAV построить более-менее сложный копоративный отчёт, где присутствует не только фильтрация, но и группировки, подзапросы, drilldown, и т.д. К слову, на JSONB ситуация будет ещё печальнее, придётся городить кучу вьюх и поддерживать их, и это будет прибито намертво ржавыми гвоздями к конкретной СУБД и конкретной её версии. да есть у меня это всё в большинстве случае решается агрегацией в отдельной таблице в JSONB я бы никогда не стал этого делать вы про эту динамику чтоли? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 16:01 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
tip78да есть у меня это всё в большинстве случае решается агрегацией в отдельной таблице в JSONB я бы никогда не стал этого делать вы про эту динамику чтоли? Наверное :) Если вы спрашиваете про архитектуру, мы раньше решали это классическим EAV, пробовали JSON и JSONB. И XML тоже пробовали. А потом пересели на CQRS+ES, и все эти костыли ушли в прошлое :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 16:18 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttПомидорЗачем монго когда эту задачу эффективно решает postgres? Я привел jsonb только для моделей которые требуют динамические аттрибуты (аналог eav), все остальное решается как обычно в рсубд. Нет, не аналог EAV. Динамические атрибуты без схемы, это вообще любое хранилище, без схемы, хоть текстовые файлы. Таким макаром и обычный блокнот можно назвать аналогом чего угодно. Совершенно верно, все это аналоги, но все эти хранилища будут различаться по удобству, скорости, и т.д. Здесь я придерживаюсь варианта хранения динамических данных в жейсон поле. Вы пишете про схемы, давайте решать определенную задачу. В жейсоне я могу создать дополнительное поле 'validation_rules', в таблице справочнике Аттирибуты, и при добавление добавление, обновление этого поля, могу сделать валидацию. Как в EAV вы решаете эту задачу? hVosttПомидорЧто значит бардак? Разве не администратор интернет магазина решает что для конкретной категории товаров нужны определенные аттрибуты с указанием типа аттрибута, ограничением определенных значений которые она может принимать и так далее? Тоже самое можно сделать и для жейсона, но как я уже написал валидация данных в вашем случае будет ну уровне базы данных, а в моем случае на уровне приложения. Речь идёт именно о РСУБД. На уровне приложения я могу данные вообще хранить в key-value store и всё-всё-всё проверять на уровне приложения, или даже в текстовых файлах хранить. Аналог? Что за детский сад? Я РСУБД использую как хранилище. Конечно обязательно пользуюсь возможностями целостности, правильности управления данными которые предоставляет РСУБД, но никто не отменял более сложные бизнес правила, которые притом еще динамические. И это не секрет никому, делаются на уровне сервера приложений. Что тогда меняет еще дополнительно проверять валидность данных на уровне приложения? Для очень загруженных систем как раз и применяют key-value store совместно с рсубд. hVosttПомидорЗдесь почти разницы нету Ну так и все ограничения целостности, транзакции, и всё остальное делайте на уровне приложения. Зачем говорить вообще тогда о БД. Храните хоть всё в памяти, и сбрасывайте дамп на диск. Разницы ведь почти нет. Вы кажется специально вводите, запутываете, собираете все в кучу. Транзакции как раз делаются на уровне БД. А вот читать данные можно и с памяти, чем и занимается редис например. hVosttПомидорА вот когда надо будет запросы с фильтрацией, то жейсон уже вырывается вперед, а eav остается далеко позади, что и сказано в указанной мной статье. В указанной вами статье, SELECT по EAV с индексом быстрее, чем все вариации с JSONb. Обновление с индексом чуть-чуть медленнее. По собственному опыту, у нас есть внедрённая система на EAV, довольно крупная по мерками enterprise, и всё работает шустро. Что касается лучшей реализации, то делать проекции на классических таблицах, добавляя колонки динамически в таблицы, не оставляет вообще никаких шансов по скорости ни EAV, ни JSONb, если уж вас так интересует производительность. И, повторюсь, JSONB не явяется аналогом EAV. В указанной мной статье нигде не указанно что бы утверждаете. Жейсон везде выигрывает. авторHere we can see that JSONB was again faster without indexes for EAV, but when the index is used EAV is the fastest. But then I noticed the times for the JSONB queries were the same, pointing me to the fact that the GIN index is not used. Apparently, when you use a GIN index on the full properties column, it only has effect when using the containment (@>) operator. I added this to the benchmark and it had a huge effect on the timing: only 0.153ms! That’s 15000x faster then EAV, and 25000x faster than the ->> operator. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 16:51 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttПомидорЧем же это не EAV? Что вы понимаете под EAV? Хорошо, давайте сперва определимся какую задачу решает EAV модель, как она контролирует целостность данных, проводит валидацию, как добавляются новый записи (новый аттрибут товара). И я приведу на жейсоне решение которая будет тоже самое делать. Я уже давно жду вот такой пример: 1. Администратор интернет-магазина через UI приложения добавляет атрибут для товаров. 2. Администратор добавляет значения этого атрибута для некоторых товаров. 3. Администратор удаляет атрибут, значения атрибута удаляются. Для JSON(B) Таблица Аттрибутивы: id, name, title, validation_rules jsonb, .... Таблица Товары: id, name, category_id, parameters jsonb, .... Таблица Категория товаров: id, parent_id, name, .... Таблица КатегорияТоваровАттрибуты id, category_id, attribute_id, ... Задача 1 и 2. Хотим добавить новый динамический аттрибут для определенной катеригории товаров. 1. Добавляем новое значение в таблицу Аттрибуты, заносим правила валидации для значений этого аттрибута 2. Добавляем новое значение в таблицу КатегорияТоваровАттрибуты, указываем нужную категорию, и аттрибут из шага 1. 3. Открываем нужный товар данной категории, приложение автоматически показывает что нужно заполнить новое поле (зависит от правила валидации, нужно к обязательному заполнению или нет). Проводит валидацию введенного значения (правила берет из таблицы Аттрибуты выбранного поля). 4. На стороне сервера приложений также проводится валидация данных, если все ок, то поле parameters обновляется. Задача 3. Удаляем запись из КатегорияТоваровАттрибуты, допольнительно удаляем запись из поля parameters в таблице Товары. Все это делается через транзакцию. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 17:09 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVostttip78да есть у меня это всё в большинстве случае решается агрегацией в отдельной таблице в JSONB я бы никогда не стал этого делать вы про эту динамику чтоли? Наверное :) Если вы спрашиваете про архитектуру, мы раньше решали это классическим EAV, пробовали JSON и JSONB. И XML тоже пробовали. А потом пересели на CQRS+ES, и все эти костыли ушли в прошлое :) если я правильно понял, CQRS + ES чем-то напоминает blockchain ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 17:41 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ну точно оно авторВот именно вопрос «производительности» мне и интересен. Потому что на простых примерах (когда за IO можно уследить глазками) всё всегда хорошо. Плохо начинается, когда запросы летят десятками тысяч в секунду. Обычная БД скрипит, но терпит. А если мы ведём журнал + head состояния? Пока всё хорошо, всё хорошо. А потом нам надо rebuild и мы стоим перед задачей перемолотить пол-года того, что в нормальном режиме грузило систему на 50%… ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2018, 18:17 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорСовершенно верно, все это аналоги, но все эти хранилища будут различаться по удобству, скорости, и т.д. Здесь я придерживаюсь варианта хранения динамических данных в жейсон поле. Вы пишете про схемы, давайте решать определенную задачу. В жейсоне я могу создать дополнительное поле 'validation_rules', в таблице справочнике Аттирибуты, и при добавление добавление, обновление этого поля, могу сделать валидацию. Как в EAV вы решаете эту задачу? В атрибут добавится поле validation_rules. Вы лучше расскажите, как вы сделаете поле FK в json. ПомидорЯ РСУБД использую как хранилище. Конечно обязательно пользуюсь возможностями целостности, правильности управления данными которые предоставляет РСУБД, но никто не отменял более сложные бизнес правила, которые притом еще динамические. И это не секрет никому, делаются на уровне сервера приложений. Что тогда меняет еще дополнительно проверять валидность данных на уровне приложения? Для очень загруженных систем как раз и применяют key-value store совместно с рсубд. Да при чём тут более сложные бизнес правила? Мы говорим про сравнение JSON и EAV, а не про весь спект всех задач, решаемых в мире. И я говорю, это не аналоги. А вы начинаете про какую-то сложную бизнес-логигу блаблабла. При чём тут это вообще? При чём тут ваши способы решения валидации? Если они не в БД? ПомидорВы кажется специально вводите, запутываете, собираете все в кучу. Транзакции как раз делаются на уровне БД. А вот читать данные можно и с памяти, чем и занимается редис например. Это вы всё в кучу собираете. Я как раз пытаюсь стряхнуть пыль. То, что вы можете сохранить в поле JSON что угодно, не делает его аналогом EAV, что тут непонятного? ПомидорВ указанной мной статье нигде не указанно что бы утверждаете. Жейсон везде выигрывает. Со всеми приседаниями, которые требуется сделать, чтобы JSON выигрывал у EAV, оно не нужно и задаром. И уж если вернуться к тебе разговора, что JSON это не аналог EAV, я уже озвучил почему, такие сравнения выглядят довольно смешными. Хотите хранить в БД какой-то структурированный мусор с точки зрения БД, и управлять этим со стороны приложения, пожалуйста, используйте JSONB, можно даже в обычное текстовое поле запихивать JSON и это будет работать вообще на всех БД. Но это не EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 03:26 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорТаблица Аттрибутивы: id, name, title, validation_rules jsonb, .... Таблица Товары: id, name, category_id, parameters jsonb, .... Таблица Категория товаров: id, parent_id, name, .... Таблица КатегорияТоваровАттрибуты id, category_id, attribute_id, ... Задача 1 и 2. Хотим добавить новый динамический аттрибут для определенной катеригории товаров. 1. Добавляем новое значение в таблицу Аттрибуты, заносим правила валидации для значений этого аттрибута 2. Добавляем новое значение в таблицу КатегорияТоваровАттрибуты, указываем нужную категорию, и аттрибут из шага 1. 3. Открываем нужный товар данной категории, приложение автоматически показывает что нужно заполнить новое поле (зависит от правила валидации, нужно к обязательному заполнению или нет). Проводит валидацию введенного значения (правила берет из таблицы Аттрибуты выбранного поля). 4. На стороне сервера приложений также проводится валидация данных, если все ок, то поле parameters обновляется. Задача 3. Удаляем запись из КатегорияТоваровАттрибуты, допольнительно удаляем запись из поля parameters в таблице Товары. Все это делается через транзакцию. Я не вижу, где здесь СУБД контролирует целостность. Не даёт создать значение отсутствующего атрибута. Или удаляет все значения удалённого атрибута, или наоборот, запрещает удалить атрибут, если у него имеются значения. EAV это делает. С JSONB никакого контроля со стороны БД нет. А все потому что. JSON/B/XML это не аналог EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 03:30 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttПомидорСовершенно верно, все это аналоги, но все эти хранилища будут различаться по удобству, скорости, и т.д. Здесь я придерживаюсь варианта хранения динамических данных в жейсон поле. Вы пишете про схемы, давайте решать определенную задачу. В жейсоне я могу создать дополнительное поле 'validation_rules', в таблице справочнике Аттирибуты, и при добавление добавление, обновление этого поля, могу сделать валидацию. Как в EAV вы решаете эту задачу? В атрибут добавится поле validation_rules. Вы лучше расскажите, как вы сделаете поле FK в json. И как этот поле validation_rules будет помогать БД контролировать целостность, коректность данных? Не таким же образом который я написал? hVosttПомидорЯ РСУБД использую как хранилище. Конечно обязательно пользуюсь возможностями целостности, правильности управления данными которые предоставляет РСУБД, но никто не отменял более сложные бизнес правила, которые притом еще динамические. И это не секрет никому, делаются на уровне сервера приложений. Что тогда меняет еще дополнительно проверять валидность данных на уровне приложения? Для очень загруженных систем как раз и применяют key-value store совместно с рсубд. Да при чём тут более сложные бизнес правила? Мы говорим про сравнение JSON и EAV, а не про весь спект всех задач, решаемых в мире. И я говорю, это не аналоги. А вы начинаете про какую-то сложную бизнес-логигу блаблабла. При чём тут это вообще? При чём тут ваши способы решения валидации? Если они не в БД? Вообще то я сразу же написал на каком уровне обеспечивается целостность данных в случае EAV и в случае жейсон. А задачу динамического атрибута решают оба и жейсон выигрывает. hVosttПомидорВы кажется специально вводите, запутываете, собираете все в кучу. Транзакции как раз делаются на уровне БД. А вот читать данные можно и с памяти, чем и занимается редис например. Это вы всё в кучу собираете. Я как раз пытаюсь стряхнуть пыль. То, что вы можете сохранить в поле JSON что угодно, не делает его аналогом EAV, что тут непонятного? Непонятно то, что если я используя жейсон поле достигаю того же эфекта как при eav, приэтом выигрываю во многом, и предлагаю использовать этот метод, а вы цепились за какие то мифический контроль целостности данных со стороны БД. Потому что целостность данных это не только обязательное присутствие каких то данных, но еще их коректность. И эту коректность вы полюбому будете делать на стороне приложения (на дворе 2018 год :) ) а не в БД. hVosttПомидорВ указанной мной статье нигде не указанно что бы утверждаете. Жейсон везде выигрывает. Со всеми приседаниями, которые требуется сделать, чтобы JSON выигрывал у EAV, оно не нужно и задаром.Вы признаете что жейсон выиграл спор скорости? Или оно вам до сих пор и задаром не нужно? hVosttИ уж если вернуться к тебе разговора, что JSON это не аналог EAV, я уже озвучил почему, такие сравнения выглядят довольно смешными. Хотите хранить в БД какой-то структурированный мусор с точки зрения БД, и управлять этим со стороны приложения, пожалуйста, используйте JSONB, можно даже в обычное текстовое поле запихивать JSON и это будет работать вообще на всех БД. Но это не EAV.Смешными выглядят ваши попытки уйти от темы, заниматься тафтологией. Это не попытка оскорбить вас, и заранее извиняюсь. Просто я понимаю что вы хотите сказать, но я хочу вам немного другое объяснить. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 04:17 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttЯ не вижу, где здесь СУБД контролирует целостность. Не даёт создать значение отсутствующего атрибута. Или удаляет все значения удалённого атрибута, или наоборот, запрещает удалить атрибут, если у него имеются значения. EAV это делает. С JSONB никакого контроля со стороны БД нет. А все потому что. JSON/B/XML это не аналог EAV. Ну я так сразу же писал что целостность контролируется на стороне приложения. Как можно удалить значения которые запрещены к удалению? На уровне приложения для этого делаются всякие тесты чтобы проконтролировать такие казусы, и это намного гибче. Ведь даже в случае с EAV вам иногда надо удалить запись с каскадным эфектом. Вы можете ошибиться приняв такое решение? Можете. И БД никак не поможет вам в этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 04:25 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорИ как этот поле validation_rules будет помогать БД контролировать целостность, коректность данных? Не таким же образом который я написал? Точно таким же, как и для JSON. Какие-нибудь бизнес-ограничения на уровне приложения. Для ограничений целостности: по типу данных, по наличию атрибута, foreign key, будет проверка на уровне СУБД. И всего этого не будет на уровне СУБД для JSON. ПомидорВообще то я сразу же написал на каком уровне обеспечивается целостность данных в случае EAV и в случае жейсон. А задачу динамического атрибута решают оба и жейсон выигрывает. Вы сравниваете мяч и апельсин только на том основании, что они круглые. Спор зашёл в тупик. ПомидорНепонятно то, что если я используя жейсон поле достигаю того же эфекта как при eav, приэтом выигрываю во многом, и предлагаю использовать этот метод, а вы цепились за какие то мифический контроль целостности данных со стороны БД. Потому что целостность данных это не только обязательное присутствие каких то данных, но еще их коректность. И эту коректность вы полюбому будете делать на стороне приложения (на дворе 2018 год :) ) а не в БД. Какая можеть КОРРЕКТНОСТЬ у непонятного значения в JSON с именем "хер_знает_что"? Вы чего городите? В EAV вы тупо не создадите значение для отсутствующего атрибута. И не сможете просто так грохнуть атрибут, если повесить NO ACTION в ограничениях целостности. Я не против, если вы выбрали управлять корректностью полностью на строке приложения, ок. Спор не об этом. Выбрали, обосновали свой выбор -- ну и прекрасно. Но с точки зрения хранения данных в СУБД это не одно и то же. Это не "аналоги", как часто это может звучать вследствие банальной неграмотности. ПомидорВы признаете что жейсон выиграл спор скорости? Или оно вам до сих пор и задаром не нужно? Нет, не признаю. На конкретном примере, крайне упрощённом и далёком от реальности, цифры не являются окончательным показателем. Что будет в разрезе отчётов с группировкой и подзапросами, на большом объёме данных? Что будет, если некоторые атрибуты меняются часта, а некоторые нет? Что будет, если для каждого значения атрибута нужно добавить ведение истории? Все эти задачи решаются на EAV в одинаковом ключе, для JSON от задачи придётся сильно менять и подходы и модель данных, что-то тащить в реляционку, что-то хранить в "куче". ПомидорСмешными выглядят ваши попытки уйти от темы, заниматься тафтологией. Это не попытка оскорбить вас, и заранее извиняюсь. Просто я понимаю что вы хотите сказать, но я хочу вам немного другое объяснить. Нет, не тафталогия. Когда говорят, что JSON это альтернатива EAV, это банальное распостранение заблуждений. И разные задачи решаются лучше разными способами. Не является ни в какой мере, утверждение, что "лучше будет, если EAV заменить JSON". ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 09:33 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорНу я так сразу же писал что целостность контролируется на стороне приложения. Как можно удалить значения которые запрещены к удалению? На уровне приложения для этого делаются всякие тесты чтобы проконтролировать такие казусы, и это намного гибче. Ведь даже в случае с EAV вам иногда надо удалить запись с каскадным эфектом. Вы можете ошибиться приняв такое решение? Можете. И БД никак не поможет вам в этом. В EAV отлично работает каскад. Странно, что когда мы говорим о БД, вы смещаете фокус внимания на приложение. В таком случае, я повторюсь, совершенно пофигу что и как и где вы будете хранить, если всем будет управлять приложение. На самом деле, я только приветствую и всячески поддерживаю, когда логика размещена в приложении, а не в СУБД. Но осуществлять базовые ограничения целостности именно модели размещения данных, таки задача СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 09:36 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttПомидорИ как этот поле validation_rules будет помогать БД контролировать целостность, коректность данных? Не таким же образом который я написал? Точно таким же, как и для JSON. Какие-нибудь бизнес-ограничения на уровне приложения. Для ограничений целостности: по типу данных, по наличию атрибута, foreign key, будет проверка на уровне СУБД. И всего этого не будет на уровне СУБД для JSON. Вот и выяснили что полюбому вам придеться проверять данные на уровне приложения. А теперь чтобы по типу данных была целостность, вам надо еще немного потрудиться чем простое EAV. А в простом EAV данные же храняться в текстовом формате. Для каждого типа создать свою таблица хранения, тогда давайте посмотрим как вы их потом соберете в одну! Проверка на наличие атрибута большая проблема на жейсоне? Я вам наверху уже нарисовал примерную схему ограничения для произвольных атрибутов. Надеюсь вы не собираетесь руками что то подправлять в БД? Внешний ключ единственная проверка СУБД, а все остальное вам опять таки придеться делать на стороне приложения, тогда какая разница на одну проверку меньше или больше? hVosttПомидорВообще то я сразу же написал на каком уровне обеспечивается целостность данных в случае EAV и в случае жейсон. А задачу динамического атрибута решают оба и жейсон выигрывает. Вы сравниваете мяч и апельсин только на том основании, что они круглые. Спор зашёл в тупик. Я их сравниваю только потому что ту задачу которую мы решаем на основе модели eav можно эффективно решить применив немного другой подход с жейсоном. hVosttПомидорНепонятно то, что если я используя жейсон поле достигаю того же эфекта как при eav, приэтом выигрываю во многом, и предлагаю использовать этот метод, а вы цепились за какие то мифический контроль целостности данных со стороны БД. Потому что целостность данных это не только обязательное присутствие каких то данных, но еще их коректность. И эту коректность вы полюбому будете делать на стороне приложения (на дворе 2018 год :) ) а не в БД. Какая можеть КОРРЕКТНОСТЬ у непонятного значения в JSON с именем "хер_знает_что"? Вы чего городите? В EAV вы тупо не создадите значение для отсутствующего атрибута. И не сможете просто так грохнуть атрибут, если повесить NO ACTION в ограничениях целостности. Я не против, если вы выбрали управлять корректностью полностью на строке приложения, ок. Спор не об этом. Выбрали, обосновали свой выбор -- ну и прекрасно. Но с точки зрения хранения данных в СУБД это не одно и то же. Это не "аналоги", как часто это может звучать вследствие банальной неграмотности. С точки зрения хранения данных конечно это совсем разные подходы, но под словом "аналог" я подразумеваю решения задачи. Ведь задача одна и та же в данном случае. КОРРЕКТНОСТЬ все таки есть, в базу данных даже админов не надо допускать что то подправить. А если все таки лезет, то пусть уже ознакомиться с значением "хер_знает_что". А вот для пользователей которым доступ к бд ограничен пользовательским интерфейсом, так они даже не почувствуют eav это или жейсон, они не смогут создать значение для отсутствующего атрибута. Им подавай ограничения на уровне приложения и скорость. hVosttПомидорВы признаете что жейсон выиграл спор скорости? Или оно вам до сих пор и задаром не нужно? Нет, не признаю. На конкретном примере, крайне упрощённом и далёком от реальности, цифры не являются окончательным показателем. Что будет в разрезе отчётов с группировкой и подзапросами, на большом объёме данных? Что будет, если некоторые атрибуты меняются часта, а некоторые нет? Что будет, если для каждого значения атрибута нужно добавить ведение истории? Все эти задачи решаются на EAV в одинаковом ключе, для JSON от задачи придётся сильно менять и подходы и модель данных, что-то тащить в реляционку, что-то хранить в "куче". Ну так данный спор происходит на конкретной модели данных. В статье указан объем. авторSELECT name , properties ->> 'color' , properties ->> 'country' FROM entity_jsonb WHERE id = 120; Напишите аналог этого запроса на модели EAV. Тем более я могу через приложение гибко контролировать select часть, а в EAV? У вас там запрос полностью измениться. Историю я веду не на колонки, а на строки. Занимает много места, но сейчас это уже не проблема. Зато позволяет сразу вытаскивать нужную информацию не применяя жойны. hVosttПомидорСмешными выглядят ваши попытки уйти от темы, заниматься тафтологией. Это не попытка оскорбить вас, и заранее извиняюсь. Просто я понимаю что вы хотите сказать, но я хочу вам немного другое объяснить. Нет, не тафталогия. Когда говорят, что JSON это альтернатива EAV, это банальное распостранение заблуждений. И разные задачи решаются лучше разными способами. Не является ни в какой мере, утверждение, что "лучше будет, если EAV заменить JSON".Хорошо, не жейсон, ведь это только формат данных, а метод на основе его, если для вас это будет более понятным. Хотя я изначально это и имел ввиду, как и автор статьи. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 11:16 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttПомидорНу я так сразу же писал что целостность контролируется на стороне приложения. Как можно удалить значения которые запрещены к удалению? На уровне приложения для этого делаются всякие тесты чтобы проконтролировать такие казусы, и это намного гибче. Ведь даже в случае с EAV вам иногда надо удалить запись с каскадным эфектом. Вы можете ошибиться приняв такое решение? Можете. И БД никак не поможет вам в этом. В EAV отлично работает каскад. Странно, что когда мы говорим о БД, вы смещаете фокус внимания на приложение. В таком случае, я повторюсь, совершенно пофигу что и как и где вы будете хранить, если всем будет управлять приложение. На самом деле, я только приветствую и всячески поддерживаю, когда логика размещена в приложении, а не в СУБД. Но осуществлять базовые ограничения целостности именно модели размещения данных, таки задача СУБД. Так что мешает на жейсоне сделать каскад? Также отлично будет работать. Где хранить будет непофигу с точки зрения удобства, скорости, модификаций каких то. Поэтому рекомендую постгис где возможно как реляционка так и документо-ориентированность. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 11:23 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорВот и выяснили что полюбому вам придеться проверять данные на уровне приложения. А теперь чтобы по типу данных была целостность, вам надо еще немного потрудиться чем простое EAV. А в простом EAV данные же храняться в текстовом формате. Для каждого типа создать свою таблица хранения, тогда давайте посмотрим как вы их потом соберете в одну! А какие проблемы? Между прочим на EAV можно создать типы с JSON-ом ПомидорПроверка на наличие атрибута большая проблема на жейсоне? Я вам наверху уже нарисовал примерную схему ограничения для произвольных атрибутов. Надеюсь вы не собираетесь руками что то подправлять в БД? Внешний ключ единственная проверка СУБД, а все остальное вам опять таки придеться делать на стороне приложения, тогда какая разница на одну проверку меньше или больше? Разница в том, что статическая или динамическая схемы -- это всё равно схемы. А контролировать данные, которые должны соответствовать схеме должна БД, а не приложение. По крайне мере EAV это решает, JSON не решает. ПомидорЯ их сравниваю только потому что ту задачу которую мы решаем на основе модели eav можно эффективно решить применив немного другой подход с жейсоном. Ну json не решает задачь EAV. JSON + приложение, да. И то, с натягом. С большим. ПомидорС точки зрения хранения данных конечно это совсем разные подходы, но под словом "аналог" я подразумеваю решения задачи. Ну так какая задача? Хранить любой мусор? Конечно, JSON здесь намного лучше. Хранить строгий динамический набор атрибутов? Не, эту задачу JSON не решает. Там всё равно будет мусор, даже если ПО считает, что нет. С точки зрения БД, это какая-то куча данных. И всё. ПомидорА вот для пользователей которым доступ к бд ограничен пользовательским интерфейсом, так они даже не почувствуют eav это или жейсон, они не смогут создать значение для отсутствующего атрибута. Им подавай ограничения на уровне приложения и скорость. Это понятно. Но это за рамками дискуссии, ну очень далеко. ПомидорНу так данный спор происходит на конкретной модели данных. В статье указан объем. Так "объём", это не только количество записей. Если говорить про динамику, то это постоянно набирающая обороты сложность. Т.е. сложность растёт без вмешательства программиста. Проблемы, которые JSON не решает, не показаны в статье. Только скорость на одноклеточном примере, но с большим количеством записей. ПомидоравторSELECT name , properties ->> 'color' , properties ->> 'country' FROM entity_jsonb WHERE id = 120; Напишите аналог этого запроса на модели EAV. Тем более я могу через приложение гибко контролировать select часть, а в EAV? У вас там запрос полностью измениться. Историю я веду не на колонки, а на строки. Занимает много места, но сейчас это уже не проблема. Зато позволяет сразу вытаскивать нужную информацию не применяя жойны. Код: sql 1. 2. 3. 4. 5.
буков больше? Такие запросы также могут генериться приложением, никто руками их не пишет. История на колоноки здесь бесплатно. Возможность конвертить тип, не теряя данных бесплатно. Делать быструю "колоночную" аналитику бесплатно. Хранить к дополнительные данные к каждому значению бесплатно (на JSON вместо значения придётся делать структуру вместо примитива, а это увеличит сложность запросов просто драматически). Быстрое обновление, проставить значения атрибута хоть для +100500 сущностей без проблем. Контроль со стороны БД. Настоящие ФК в значениях атрибутов. Расширение вширь и в глубь, без изменения существующего кода. Ну и конечно, сильная независимость от вендора, для кого-то это фигня, кто сидит пожизненно плотнячком на конкретной субд. Для нас, например, это важно, и это окупилось уже многократно. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 12:03 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорТак что мешает на жейсоне сделать каскад? Также отлично будет работать. Где хранить будет непофигу с точки зрения удобства, скорости, модификаций каких то. Поэтому рекомендую постгис где возможно как реляционка так и документо-ориентированность. :) Какой каскад, со стороны аппликейшен? Ну это даже не смешно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 12:03 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
hVosttПомидорВот и выяснили что полюбому вам придеться проверять данные на уровне приложения. А теперь чтобы по типу данных была целостность, вам надо еще немного потрудиться чем простое EAV. А в простом EAV данные же храняться в текстовом формате. Для каждого типа создать свою таблица хранения, тогда давайте посмотрим как вы их потом соберете в одну! А какие проблемы? Между прочим на EAV можно создать типы с JSON-ом И на жейсон атрибут тоже можно запихнуть жейсон, будет иерархия жейсонов, которая кстати нативная hVosttПомидорПроверка на наличие атрибута большая проблема на жейсоне? Я вам наверху уже нарисовал примерную схему ограничения для произвольных атрибутов. Надеюсь вы не собираетесь руками что то подправлять в БД? Внешний ключ единственная проверка СУБД, а все остальное вам опять таки придеться делать на стороне приложения, тогда какая разница на одну проверку меньше или больше? Разница в том, что статическая или динамическая схемы -- это всё равно схемы. А контролировать данные, которые должны соответствовать схеме должна БД, а не приложение. По крайне мере EAV это решает, JSON не решает.Как БД контролирует данные которые должны соответствовать схеме? Например хотим в динамическом атрибуте хранить период даты, как она это проконтролирует? hVosttПомидорЯ их сравниваю только потому что ту задачу которую мы решаем на основе модели eav можно эффективно решить применив немного другой подход с жейсоном. Ну json не решает задачь EAV. JSON + приложение, да. И то, с натягом. С большим. Почему с натягом? Полностью контролирует. По вашей логике то и бизнес правила тоже с натягом валидируются на уровне приложения? Если так, то где еще проверять данные? hVosttПомидорС точки зрения хранения данных конечно это совсем разные подходы, но под словом "аналог" я подразумеваю решения задачи. Ну так какая задача? Хранить любой мусор? Конечно, JSON здесь намного лучше. Хранить строгий динамический набор атрибутов? Не, эту задачу JSON не решает. Там всё равно будет мусор, даже если ПО считает, что нет. С точки зрения БД, это какая-то куча данных. И всё.Задача простая. Есть набор объектов, которые одного типа, имеют как похожие так и непохожие наборы атрибутов. И в дальнейшем могут добавляться атрибуты. Не могу понять почему вы все время указываете на мусор данных в случае жейсон. hVosttПомидорА вот для пользователей которым доступ к бд ограничен пользовательским интерфейсом, так они даже не почувствуют eav это или жейсон, они не смогут создать значение для отсутствующего атрибута. Им подавай ограничения на уровне приложения и скорость. Это понятно. Но это за рамками дискуссии, ну очень далеко. Все это взаимосвязанно. Ведь вы же не проектируете схему базы данных не учитывая дальнейшую ее эксплуатацию. hVosttПомидорНу так данный спор происходит на конкретной модели данных. В статье указан объем. Так "объём", это не только количество записей. Если говорить про динамику, то это постоянно набирающая обороты сложность. Т.е. сложность растёт без вмешательства программиста. Проблемы, которые JSON не решает, не показаны в статье. Только скорость на одноклеточном примере, но с большим количеством записей. hVosttПомидор Код: sql 1. 2. 3. 4. 5.
Напишите аналог этого запроса на модели EAV. Тем более я могу через приложение гибко контролировать select часть, а в EAV? У вас там запрос полностью измениться. Историю я веду не на колонки, а на строки. Занимает много места, но сейчас это уже не проблема. Зато позволяет сразу вытаскивать нужную информацию не применяя жойны. Код: sql 1. 2. 3. 4. 5.
буков больше? Такие запросы также могут генериться приложением, никто руками их не пишет. История на колоноки здесь бесплатно. Возможность конвертить тип, не теряя данных бесплатно. Делать быструю "колоночную" аналитику бесплатно. Хранить к дополнительные данные к каждому значению бесплатно (на JSON вместо значения придётся делать структуру вместо примитива, а это увеличит сложность запросов просто драматически). Быстрое обновление, проставить значения атрибута хоть для +100500 сущностей без проблем. Контроль со стороны БД. Настоящие ФК в значениях атрибутов. Расширение вширь и в глубь, без изменения существующего кода. Ну и конечно, сильная независимость от вендора, для кого-то это фигня, кто сидит пожизненно плотнячком на конкретной субд. Для нас, например, это важно, и это окупилось уже многократно. Хорошо, для вас много букв не проблема. А как насчет скорости этого запроса? Ведь автор как раз это и проверил, и пришел к выводу что жейсон метод в 15 тыч. быстрее. :) История на колонки как бесплатны? Можете подробнее в этом месте объяснить. Меняем для какого то объета значения динамического атрибута 'color' с RED на BLACK. Конвертить тип данных не бесплатно, а нагрузга для системы. Для жейсонб это уже нативно. :) Делать быструю "колоночную" аналитику делают немного другим методом, например можно в редис скинуть. :) Она уж точно будет быстрее вашей аналитики. Какие дополнительные данные к каждому значению можете хранить? Я не представляю. Жейсон изначально поддерживает вложенность, или дополнительные атрибуты к жейсон объекту. И сложность не растет драматически. авторFor updating the data, this resulted in these execution times (in ms). Note that the scale is logarithmic: Here, we see that the JSONB is much (>50000x) faster than EAV when not using any indexes, for the reason mentioned above. When we index the foreing key columns the difference is almost eliminated, but JSONB is still 1.3x faster than EAV. Notice that the index on the JSONB column does not have any effect here, as we don’t use the properties column in the criteria. Как видите то что в вашем методе без проблем, в случае с жейсоном минимум 1.3 быстрее. :) Расширение вширь и в глубь жейсон метод не ограничивает ни как. Сильная зависимость от вендора для меня действительно не проблема на данный момент. Выбираю инструменты сам. Но вашу точку зрению я изначально понимал. Просто думаю скоро все вендоры реализуют такие фичи в любом случае. Если не секрет то с какой субд на какую субд вы прыгнули? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 13:24 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
ПомидорКак БД контролирует данные которые должны соответствовать схеме? Например хотим в динамическом атрибуте хранить период даты, как она это проконтролирует? ну для начала можно на колонку повесить тип date, и тогда кроме даты туда уже ничего не вставить "динамический атрибут периода даты" это started + closed потом есть CONSTRAINTS , можно проверять, чтобы дата была в диапазоне, чтобы была уникальной, чтобы не пересекалась с другими таблицами (FK) ничего из этого JSONB не умеет. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 16:08 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
tip78ПомидорКак БД контролирует данные которые должны соответствовать схеме? Например хотим в динамическом атрибуте хранить период даты, как она это проконтролирует? ну для начала можно на колонку повесить тип date, и тогда кроме даты туда уже ничего не вставить "динамический атрибут периода даты" это started + closed потом есть CONSTRAINTS , можно проверять, чтобы дата была в диапазоне, чтобы была уникальной, чтобы не пересекалась с другими таблицами (FK) ничего из этого JSONB не умеет. Сделайте все это в EAV модели. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 16:40 |
|
Пронетирование бд электроэнергетических устройств
|
|||
---|---|---|---|
#18+
сделано уже многократно этот функционал доступен из коробки ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 18:09 |
|
|
start [/forum/topic.php?fid=32&msg=39674410&tid=1540020]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 249ms |
total: | 385ms |
0 / 0 |