Timur Solodovnikov будет жить. Поприветствуем!

я это понял что выполняется полностью, но тело не очищается ?

Да, при CONCURRENTLY — не очищается, а обновляется. Просто в Вашем случае все записи — новые (а все старые удалены). :)

да. это просто обновление строками, а не таблицей. Я размечтался о другом :)))

Nina Shevchenko будет жить. Поприветствуем!

Подскажите, постгрес умеет пропускать джоины с шардированными таблицами если конкретный джоины там точно не может сработать? Раньше оно могло только если при планировании знало какие значения будут.

Подскажите, постгрес умеет пропускать джоины с шардированными таблицами если конкретный джоины там точно не может сработать? Раньше оно могло только если при планировании знало какие значения будут.

А Вы про какую версию спрашиваете? И, кстати, что такое "шардированнымые таблицы"? Если partitioning, то runtime partition pruning начнётся с v11. ;)

@knizhnik , подскажите, а вот эта штука - IMCS - живая или уже не сильно?

Да, я её поддерживаю. и ещё у меня появилась более новая штука по тем же мотивам - VOPS.

почему?

Потому что EAV не анти паттерн. Просто другой подход. Есть плюсы и минусы. Кто это считает это анти паттерном, просто неосиливший му#$@б.

Потому что EAV не анти паттерн. Просто другой подход. Есть плюсы и минусы. Кто это считает это анти паттерном, просто неосиливший му#$@б.

EAV — это именно что anitpattern. Да, это другой подход, нереляционный. И в нём есть минусы.. и ещё минусы, в основном. ;)

Не антипаттерн это

Он просто мало кому нужен

Не антипаттерн это

Ну-ну. И почему?

Потому что часто он решает свою задачу

Динамические атрибуты

Потому что часто он решает свою задачу

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

У тя таких задач видимо не было

У тя таких задач видимо не было

Как вышеописанная? Ну почему же, было. EAV отлично достигает этой цели, вообще без проблем. :)

Достигает и мусора нет

Достигает и мусора нет

И каким же образом?

Мусор это лишние записи. Их нет

Мусор это лишние записи. Их нет

Причём тут лишние записи? Мусор — это чушь вместо данных. И такое с EAV достигается очень легко.

Вместо eav хранить в json? Есть предложения лучше?

Вместо eav хранить в json? Есть предложения лучше?

flat table или 6NF, например.

Flat table не решает задачи eav...

А причес тут шестая нормальная форма? Как она поможет?

Flat table не решает задачи eav...

Почему же? Да, это DDL (как и 6NF).

На момент запуска приложения я еще не знаю структуру данных. Я ее другими таблицами описываю и в рантайме пишу в eav

А причес тут шестая нормальная форма? Как она поможет?

entity_propertyX(entity_id REFERENCES entities, property REFERENCES property_values).

entity_propertyX(entity_id REFERENCES entities, property REFERENCES property_values).

Я не понял что это, дай ссылку на доку

На момент запуска приложения я еще не знаю структуру данных. Я ее другими таблицами описываю и в рантайме пишу в eav

Да, я знаю. А с flat table меняется структура таблицы (и какие-то, возможно, добавляются), в runtime.

Я не понял что это, дай ссылку на доку

Ну, например (первое попавшееся): https://stackoverflow.com/questions/4824714/would-like-to-understand-6nf-with-an-example

Вроде понял. То есть для каждого атрибута таблица?

Вроде понял. То есть для каждого атрибута таблица?

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

А что делать, если заранее не знаю аттрибутов?

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

А что делать, если заранее не знаю аттрибутов?

А как Вы обычно эту задачу решаете? Вот откуда Вы знаете, что у поставщика есть номер... что они вообще в таблице Vendor хранятся? ;) И что значат другие поля в этой таблице, что с ними делать? Т.е. здесь нужна какая-то поддержка этих динамических атрибутов в приложении. Нередко делают для этого какой-нибудь "каталог метаданных", в виде таблиц в той же базе данных.

В общем то я на той стадии думания и пока незнаю какой вариант выбрать

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

У меня есть типы товаров и к ним надо динамически привязывать и создавать атрибуты. Мало того у товара могут быть различные варианты с разными свойствами

Что можете сказать про json? Стоит ли вместо eav?

Конечно же помимо лёгкости решения хочется ещё и поддерживать это легко

Что можете сказать про json? Стоит ли вместо eav?

Понимаете, зависит от важности этого для Вас (Ваших пользователей). Я вот видел ситуации, когда пользователей, на самом деле, устраивало, что там (в атрибутах) куча мусора, что запросы возвращают чёрт знает что, что нетривиальные тормозят. Если это сойдёт, то EAV — Ваш выбор. ;) IMHO, JSON(b) может быть лучше EAV... но примерно так же, как тиф лучше чумы. :(

Понимаете, зависит от важности этого для Вас (Ваших пользователей). Я вот видел ситуации, когда пользователей, на самом деле, устраивало, что там (в атрибутах) куча мусора, что запросы возвращают чёрт знает что, что нетривиальные тормозят. Если это сойдёт, то EAV — Ваш выбор. ;) IMHO, JSON(b) может быть лучше EAV... но примерно так же, как тиф лучше чумы. :(

Идеального решения все равно не найти. Я это понимаю.

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

Решили пока просто построить с использованием jsonb несколько таблиц и поделать выборки

Код даже не писали

Идеального решения все равно не найти. Я это понимаю.

Я только что тут рассказывал про другие решения, не заметили?! ;)

Я только что тут рассказывал про другие решения, не заметили?! ;)

Они ещё по-моему сложнее

Про какое решение именно вы имеете ввиду?

Они ещё по-моему сложнее

IMHO, они выгодно отличаются от EAV/JSONb тем, что это хотя бы решения. ;)

Про какое решение именно вы имеете ввиду?

Любое из flat table / 6NF.

Я незнаю что такое flat table увы (

Видимо это все атрибуты в таблице одной?

Тогда мы модифицируем саму таблицу при добавлении нового свойства?

Видимо это все атрибуты в таблице одной?

Да, всего лишь. :) NULL-able. И да, модифицируем таблицу.

Блин сурово звучит

Блин сурово звучит

Ну а мне кажется, что добавить ссылочную целостность и правильные типы в EAV — гораздо суровее (и быстро начинает напоминать разработку недо-СУБД "внутри" существующей... и неспроста). ;)

Так я то вообще пока в сторону jsonb )))

+ метаданные в отдельной таблице

Есть таблица свойств и их описание. А в товаре значения свойств в jsonb

Все остальные sql

Так я то вообще пока в сторону jsonb )))

А у него примерно те же проблемы (но, к счастью, хоть примитивные типы есть).

Есть таблица свойств и их описание. А в товаре значения свойств в jsonb

Ну а где всё прочее, что даёт "обычная" модель? Например, ссылочная целостность? (Кстати, то, что в JSONb есть типы, не избавляет их хранения в метаданных.) И ещё появляется такая штука, как проверка схемы JSON (которой в обычной схеме нет по очевидной причине). ;)

EAV — это именно что anitpattern. Да, это другой подход, нереляционный. И в нём есть минусы.. и ещё минусы, в основном. ;)

Чёйта нереляционный? В котором месте?

Чёйта нереляционный? В котором месте?

Тавой-то. Поле V в EAV таблице какого типа?

А как Вы обычно эту задачу решаете? Вот откуда Вы знаете, что у поставщика есть номер... что они вообще в таблице Vendor хранятся? ;) И что значат другие поля в этой таблице, что с ними делать? Т.е. здесь нужна какая-то поддержка этих динамических атрибутов в приложении. Нередко делают для этого какой-нибудь "каталог метаданных", в виде таблиц в той же базе данных.

Есть таблицы с описанием сущностей и атрибутов, правил их обработки, типы и тд. Через админку накидываются атрибуты и сразу рабочее api е ним есть

Есть таблицы с описанием сущностей и атрибутов, правил их обработки, типы и тд. Через админку накидываются атрибуты и сразу рабочее api е ним есть

То же самое, в этом случае.

Ну я подумал что буду валидировать с помощью таблицы метаданных. Мне в eav не нравится то что значение это строка

Или придется делать под инт одну таблицу, под строки другую

И так далеп

Ну я подумал что буду валидировать с помощью таблицы метаданных. Мне в eav не нравится то что значение это строка

Вот поэтому это и нереляционная модель (т.е. с точки зрения теории). Т.е. домен этого поля — это... "ну, эээ, какие-то неведомые данные". Поэтому и FK с него не сделаешь, и т.п... а потом начинают возникать идеи про "придется делать под инт одну таблицу, под строки другую"... и вот кто-то уже пишет свою недо-СУБД. ;)

Ну так раз данные неструктурированные так json же лучше?

Если не рассматривать 6ю форму и плоскую таблицу

Если у товара могут быть характеристики не известно какие то это что то типа документа

Понимаю что подходы разные. Сижу пытаюсь оправдать свой выбор в сторону jsonb если честно

Лукавить не буду

Ну так раз данные неструктурированные так json же лучше?

Если у вас действительно неструктурированные данные — да, лучше. Только вот я что-то сомневаюсь. ;) К примеру, Вас устроит такое: {"время высыхания":"5 метров"} ? Если нет, то всё-таки какая-то структура у Вас есть. А если устроит, то почему бы и нет. :)

Я подумал сделать так. Что свойства будут иметь варианты значений

Как метаданные

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

У свойства будет уникальный символьный код, которое будет ключом

Т.е. мы сами введем некоторые ограничения чтобы пытаться сохранить целостность данных

Т.е. мы сами введем некоторые ограничения чтобы пытаться сохранить целостность данных

Я не спорю, что при достаточных усилиях можно написать свою СУБД внутри другой.. только вот стоит ли? > Но те свойства что в фильтрах они могут быть только из существующих значений и будут администрироваться Про сортировку подумайте / не забудьте, если уж будете делать, кстати. Но я это всё к тому, что Вы просто потратите какое-то (немалое?) время на реализацию того, что СУБД дала бы Вам и так... да и реализация, скорее всего, выйдет кривая. :(

Я не спорю, что при достаточных усилиях можно написать свою СУБД внутри другой.. только вот стоит ли? > Но те свойства что в фильтрах они могут быть только из существующих значений и будут администрироваться Про сортировку подумайте / не забудьте, если уж будете делать, кстати. Но я это всё к тому, что Вы просто потратите какое-то (немалое?) время на реализацию того, что СУБД дала бы Вам и так... да и реализация, скорее всего, выйдет кривая. :(

Сортировку подумали

Да я понимаю что ты про каноничность

Но кажется что это ещё сложнее. Придется какой то генератор писать который будет добавлять поля в таблицу

И выглядит как то ещё опаснее. Особенно в нашем случае с отсутствием такого опыта

Сортировку подумали

Ну, как хотите. :( Запросы ещё попробуйте. А, и ещё: . В отличие от 6NF (и даже от EAV) JSONb-поля обновляются только целиком — если нужно обновить один из сотни атрибутов, переписываются все. . Подумайте про индексацию, если будут нетривиальные запросы (можно посмотреть на expressional индексы). (И да, если Вы таких индексов не будете использовать, производительность у Вас может быть не очень... по разным причинам).

Я читал про gis индексы. Это они?

Но кажется что это ещё сложнее. Придется какой то генератор писать который будет добавлять поля в таблицу

Да, но то, что придётся делать при EAV/JSONb (контроль целостности и схемы вручную), делать не придётся. :)

Ой наверное gin index

Yaroslav читал что с версии 9.5 можно какой то ключ только обновить