Немного отстал от жизни, что за notify?

Почитать бы тебе или видос глянуть. Что люди не сделают, лишь бы SQL на помойку…

https://www.postgresql.org/docs/current/sql-notify.html

https://www.youtube.com/watch?v=kZy7F9w6CH8

SQL перестало быть состоятельным примерно 30 лет назад. То есть, когда индустрия перестала опираться только на скалярные значения фиксированной длины и комбинации оных, когда получилось, что на такой банальный чих, как поле-массив, приходится создавать две дополнительные таблицы, не говоря уже о том, насколько сложно их потом реструктурировать после изменения схемы данных. А отсутствие механизма listen-notify — это, казалось бы, вечный бич SQL, который изначально подразумевал только формат «запрос-ответ». К сожалению, в постгресе notify-listen — это даже близко не тот pub-sub, который есть в кролике или редиске.

Кролика и сбоку можно приделать на триггеры/что-нибудь еще.

SQL перестало быть состоятельным примерно 30 лет назад

Чоэта? Свою работу он делает хорошо. Ну, двузвенщики вот, если бы были столярами, делали бы всё одним зубилом, но то разве вина рсубд?

как поле-массив, приходится создавать две дополнительные таблицы

Не должно быть в нормальной бд никаких полей-массивов и прочих полей-структур. Какой у такого поля будет домен? Это противоречит основным принципам построения рбд.

не говоря уже о том, насколько сложно их потом реструктурировать после изменения схемы данных

Если таблицы бд нормальной форме - всё хорошо реструктурируются. Все проблемы обычно начинаются с членоположения на НФ.

Вангую, что вопрос не к БД и от тебя хотят какой-то pub/sub ESB/вебсокет.

Не должно быть в нормальной бд никаких полей-массивов и прочих полей-структур.

Да хоть поля-деревья, поля-орграфы и поля-блобы, ты нам не указ.

инкрементирую этого костылятора! ))

Да хоть поля-деревья, поля-орграфы и поля-блобы, ты нам не указ.

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

Не осилил нормализацию?

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

Зачем нормализовывать непрозрачное, чтоб тормозило?

встречный вопрос из параллельной области: а зачем хранить файлы в субд? потому что есть блоб?

ну дичь же.

Если под неизвестно откуда взявшимся «файл» ты подразумеваешь что-то до отвратительного большое, то сам воюй с соломой. А если искренне интересуешься, зачем в БД может валяться небольшой ненормальзованный блоб с каким-нибудь криптографическим ключом или кусочком ДНК, то это как-то слишком очевидно, чтобы я мог вразумительно ответить. Чтобы не сношать БД с БД в виде ФС без повода.

*хранит и доволен*

Не осилил нормализацию?

Нормализация — trade-off, в нормализованную базу может быть намного дешевле и консистентнее писать, но если типичный паттерн чтения это «заджойнить 20+ таблиц» и писать нужно реже, чем читать — денормализованная база может быть лучше. И да, тот же постгресс — так себе key-value база (поскольку нет настоящего primary-индекса, все индексы по сути равноценны), но когда лень включать в стек что-то серьёзнее — сойдёт.

Array объективно нужен, чтобы не заниматься хернёй.

В каких кейсах, например? Сколько я видел попыток запихать в поле массив, всё заканчивалось в дерьме.

JSON тоже, на тот случай, если нужно сдампить часть данных без чёткого понимания, что из них в дальнейшем может пригодиться

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

Нормализация — trade-off, в нормализованную базу может быть намного дешевле и консистентнее писать,

Если тебе не нужна консистентрость, то о чём вообще речь? Так можно хоть в файлах хранить твои данные.

но если типичный паттерн чтения это «заджойнить 20+ таблиц» и писать нужно реже, чем читать — денормализованная база может быть лучше.

Для паттернов, когда надо «заджойнить 20+ таблиц» есть всякие матвьюхи. А когда в одно прекрасное утро на большой и толстой деномализированной таблице придётся делать апдейт какой-нибудь одной сущности, всё закончится в дерьме, если вообще закончится.

Зачем нормализовывать непрозрачное, чтоб тормозило?

Чтобы смочь потом с данными делать хоть что-то, кроме того единственного кейса. Скорость - это не про рсубд, хочешь скорость, складывай всё в редис или еще nosql какой-нибудь.

Есть у меня объект со статичным набором внешних идентификаторов. То есть, изменяться они не будут, никаких связей в бд нет. Твои предложения?

данных по гб в месяц

Это же ничто вообще.

Я тебе вполне реальный случай привёл. Это полезно, это себя оправдывает, пострес прекрасно в таком сценарии использования себя чувствует.

Ты, вроде, MySQL-щик? К твоему сведению, в свежих постгресах в jsonb даже индексы поддерживаются без костылей с вычисляемыми колонками.

это не про рсубд

Глупости. Очень даже про скорость.

Если тебе не нужна консистентрость, то о чём вообще речь? Так можно хоть в файлах хранить твои данные.

Сильно зависит от схемы и юзкейса, иногда в предельно денормализованную key-value базу можно достаточно консистентно писать. Да, файлы — это тоже key-value база.

А когда в одно прекрасное утро на большой и толстой деномализированной таблице придётся делать апдейт какой-нибудь одной сущности

Ну так обычно это применяют когда либо не нужно делать этот апдейт, либо когда знают, что этот апдейт можно сделать в реляционной базе, а потом перегенерировать хоть всю key-value как внешнюю проекцию этой реляционной базы (если читать слегка протухшие данные допустимо). Materialized views — замечательная вещь, но они всё ещё внутри того же постгреса будут и будут ограничены фичами постгреса.

Ну так обычно это применяют когда либо не нужно делать этот апдейт

Ну вот если бы еще знать наверняка, нужно будет делать аптейт или нет.

Для паттернов, когда надо «заджойнить 20+ таблиц» есть всякие матвьюхи. А когда в одно прекрасное утро на большой и толстой деномализированной таблице придётся делать апдейт какой-нибудь одной сущности, всё закончится в дерьме, если вообще закончится.

Сильно зависит. Иногда данные в БД не меняются вообще by-design, тогда денормализация — наше все. Иногда меняются крайне редко, тогда можно обновить ненормализованные поля одной транзакцией — медленно, зато 99.99% остального времени они будут выбираться со свистом. В общем, на тему нормализации и денормализации целые книги пишут, это большой и интересный топик.

Просто нормализовать данные много ума не надо.

Есть у меня объект со статичным набором внешних идентификаторов. То есть, изменяться они не будут, никаких связей в бд нет.

Нууу, совсем всё уныло, даже срач не развести.

Глупости. Очень даже про скорость.

На приемлемое время выйти, конечно, можно, но если мериться письками, то всосёт по сравнению с всякими inmemory без шансов.

Ты, вроде, MySQL-щик?

Уже ораклист на полшишки. Завтра еще и постгресс начну колупать с данными, которые хранятся xml блобом. Вот у меня очко порвёт, когда буду это апдейтить.

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

Кто-нибудь бы нам еще бд обновил до актуальной версии, чтобы можно было потыкать и оценить этот jsonb. Думаю всё равно будет медленнее, чем eav, а если и не медленнее, то о ужас, рбд скатились в монгу, надо срочно закрывать говноделам доступ на create/alter table, а то они всю базу засрут своим jsonb.

Сильно зависит. Иногда данные в БД не меняются вообще by-design, тогда денормализация — наше все

Но тогда это - не бд, а лог или какой-нибудь key-value кэш. Зачем это тащить в рбд? Если вещи, которые работают с такими данными намного эффективнее.

Просто нормализовать данные много ума не надо.

Когда понял, как это делается, то да. С другой стороны стонами неосиляторов форумы полны.

в свежих постгресах в jsonb даже индексы поддерживаются без костылей с вычисляемыми колонками

Как бы индексы по вычисляемым значениям (не колонкам, а любому выражению) поддерживаются давно. И в мускуле тоже (но не так давно).

Но тогда это - не бд, а лог или какой-нибудь key-value кэш. Зачем это тащить в рбд?

Ну так любой индекс кроме, возможно, primary key по сути есть key-value кэш с той разницей, что он может обновляться консистентно с собственно данными без возни с распределёнными транзакциями. Зачем тащить индексы в рбд?

В MySQL же есть движок Memory.

Но и без этого, если у нас много рамы под кеш, а мы не идиоты, стараемся избегать лишних джоинов и констрейнтов, не чураемся избыточности, где необходимо, да в целом структура бд адекватная и индексами грамотно обмазанная, то в среднем на запрос разница будет лишь в разы, а не на порядки. Не придумал сходу достаточно убедительного сценария, где это проявлялось бы максимально наглядно, но РСУБД позволяет избежать бессмысленных телодвижений в приложении, а это тоже время, особенно, если речь о приложении на Python, например.

Того количества запросов, что в секунду может прохавывать единственный инстанс PostgreSQL на приличном железе, многим и во сне не суждено увидеть. Так что, пока речи не идёт о настоящем хайлоаде с сотнями тысяч rps и миллисекундными задержками, РСУБД вполне тащат.

Но тогда это - не бд, а лог или какой-нибудь key-value кэш. Зачем это тащить в рбд? Если вещи, которые работают с такими данными намного эффективнее.

Ну так этот «лог» может быть частью твоих данных, может иметь слабую связь с какими-то другими полями в БД или другие таблицы будут на него ссылаться. Вариантов море. В конце концов, даже если это «лог в себе», ты не обязательно захочешь тащить еще одну субд в свою инфраструктуру, по множеству причин.

Кролика и сбоку можно приделать на триггеры/что-нибудь еще

Весь смысл готовых СУБД заключается в том, что ты просто берешь пользуешься ею и она точно работает, а не дописываешь ad-hoc костыли с непонятными гарантиями надежности и стабильности.

SQL перестало быть состоятельным примерно 30 лет назад

Чоэта? Свою работу он делает хорошо. Ну, двузвенщики вот, если бы были столярами, делали бы всё одним зубилом, но то разве вина рсубд?

Ты в курсе ранней истории MySQL? На мой взгляд, это один из тех примеров, когда софт упал в пустую нишу, а не поднялся на чьих-то деньгах. Старые пердуны рассказывали «что за молодежь пошла, ни стыда, ни совести ни транзакций, ни изоляции», но в том-то и дело, что веб-макакам нужно было быстро и грязно, им, по сути, нужна была локальная БД аля SQLite, которая была релизнута только в 2000 году. Реальной альтернативой на то время была только Berkley DB, которая не имела толком никакой семантики (да и не имеет до сих пор) и тем более языка запросов. То есть, эффективно, гибко, но сложно и страшно, слишком много рычагов, слишком много возможностей.

Достаточно было сделать удобную прокладку в пыхе для BDB — и MySQL оказался бы в жопе. То есть, мартыхе даже не нужно было бы знать SQL — он работает с объектами БД как с обычными объектами PHP. То же самое ведь по итогу делается в ORM через SQL, но с кучей прокладок и огромными накладными расходами. Отдельный слой БД в 99% проектов — это лишняя сущность, она только мешается под ногами. То есть, в ней не крутится никакой логики, там нет хранимых процедур — она просто сохраняет и отдает данные.

Причем, на этом фоне иронично выглядят споры по поводу хранимых процедур: одни говорят, что это признак говнокода и неподдерживаемо, только полный вынос логики из БД позволяет создать хорошую систему, другие говорят, что хранимки позволяют эффективно обрабатывать данные независимо от ЯП слоя логики и с хорошей производительностью благодаря близости к серверу БД. На самом деле додики и те, и другие, потому что создают ложную диллему — на самом деле сервер БД здесь лишнее звено, роль «хранимых процедур» должен был исполнять слой логики, напрямую общающийся с БД.

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

Не должно быть в нормальной бд никаких полей-массивов и прочих полей-структур. Какой у такого поля будет домен? Это противоречит основным принципам построения рбд

Вот я и пишу — РБД не нужно.

Если таблицы бд нормальной форме - всё хорошо реструктурируются. Все проблемы обычно начинаются с членоположения на НФ

Хорошо, гуру, расскажите нам, как легко в нормальных формах превратить связь 1-к-N в связь N-к-M.

*использует одно такое поделие с хранением файлов в бд и проклинает разработчиков каждый раз*

встречный вопрос из параллельной области: а зачем хранить файлы в субд? потому что есть блоб?

Внезапно, файловая система — это почти такая же БД.

Внезапно, файловая система

внезапно, началась какая-то игра в слова

Это нормально, я себя тоже проклинаю.

Но тасок вида «в зажопинске у админа-аутиста под кали 2016 года нет прав на запись аватарок» стало намного меньше.

Хорошо, гуру, расскажите нам, как легко в нормальных формах превратить связь 1-к-N в связь N-к-M.

create table role (
    id serial primary key,
    code varchar(255) not null
);

create table account (
    id serial primary key,
    name varchar(255) not null,
    role_id int not null references role
);

create table account_role (
    account_id int not null references account,
    role_id int not null references role
);

insert into account_role (account_id, role_id)
select id, role_id from account;

alter table account drop column role_id;

Когда проэтосамишь консистентное состояние нескольких сотен тысяч файлов в директориях и их состояния в БД - начнёшь понимать зачем.

У хранения в largeobject свои минусы - например скотски пухнущие файлы БД.

Короче, куди ни ткни, хурма какая-то.

insert into account_role (account_id, role_id)
select id, role_id from account;
alter table account drop column role_id;

С таким же успехом можно пересоздавать таблицы заново и копировать в них данные — будет чуть медленнее, но по сути то же самое. Это я тебе пишу как человек, который восемь лет разрабатывал систему, которая примерно так, как ты описываешь, по десять раз на дню жонглировала таблицами вместо того, чтобы один раз сделать гибкую схему, которая прожует любой бред, который сегодня пользователь себе придумал, причем, сделает это без остановки работы системы и потери данных.

Когда проэтосамишь консистентное состояние нескольких сотен тысяч файлов в директориях и их состояния в БД - начнёшь понимать зачем

У меня позиция, что любое распределенное хранилище неизбежно превращается в этом самое — бесконечную синхронизацию несогласованных хранилищ. Странно, что под это дело так мало готовых решений в виде каких-нибудь библиотек для синхронизации распределенных хранилищ.

Весь смысл готовых СУБД заключается в том, что ты просто берешь пользуешься ею и она точно работает, а не дописываешь ad-hoc костыли с непонятными гарантиями надежности и стабильности.

pub/sub - задачу рсубд? Ну не знаю. Делать из рбд комбайн, который будет делать всё - ну такое себе.

Отдельный слой БД в 99% проектов — это лишняя сущность, она только мешается под ногами.

Всё эти, т.н. проекты, где типа ничего не нужно, начинает дико лагать, когда количество пользователей переваливает за 1.5 и появляются какие-то объёмы данных. Да, быстра, херак-херак и в продакшон, но это не значит, что рбд там вообще не нужны. Когда всё оказывается в дерьме, макак с орм выкидывают и бедные люди потом пытаются костылями что-то сделать, чтобы хоть как-то работало.

Хорошо, гуру, расскажите нам, как легко в нормальных формах превратить связь 1-к-N в связь N-к-M.

Если таблицы a (id) и b (id, fk_a) в связи 1 к много. Делаешь таблицу c, вставляешь туда из b ( b.id, b.fk_a ). Из b удаляешь колонку fk_a. Всё. В чём подвох?

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

Ну, конечно, можно было приделать какую-нибудь nosql/монгу, но есть один нюанс.

причем, сделает это без остановки работы системы и потери данных.

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

Так что, пока речи не идёт о настоящем хайлоаде с сотнями тысяч rps и миллисекундными задержками, РСУБД вполне тащат.

Ну как, мне, например, надо выбрать данные из половины значимых таблиц и да, оно тащит, но если выбирать это же сразу из кеша, то всё становится намного бодрее. В целом, ну да, можно и по 600-1000мс делать запрос, но можно и по 200-400мс.

Ну так этот «лог» может быть частью твоих данных

Не может. У нас тут срач про то, что вся эта реляционка с нормализацией не нужна.

Ну так любой индекс кроме, возможно, primary key по сути есть key-value кэш с той разницей, что он может обновляться консистентно с собственно данными без возни с распределёнными транзакциями.

Логически да. Логически и eav должен летать. Но на уровне реализации там всё сложнее и красивые схемы будут отрабатывать неприлично долго.

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

Хочешь раздуплить теорему CAP?

Не может. У нас тут срач про то, что вся эта реляционка с нормализацией не нужна.

(Де)нормализация — это не бинарное свойство.

В контексте обсуждения - бинарное.

Всё эти, т.н. проекты, где типа ничего не нужно, начинает дико лагать, когда количество пользователей переваливает за 1.5 и появляются какие-то объёмы данных. Да, быстра, херак-херак и в продакшон, но это не значит, что рбд там вообще не нужны. Когда всё оказывается в дерьме, макак с орм выкидывают и бедные люди потом пытаются костылями что-то сделать, чтобы хоть как-то работало

Очень, очень советую почитать про Berkley DB. Она позволяет параллельно писать в базу, при этом ей не нужен сервер и вся СУБД умещается в либу на 2 МБ. Кстати, по организации данных похоже на PSO.

Если таблицы a (id) и b (id, fk_a) в связи 1 к много. Делаешь таблицу c, вставляешь туда из b ( b.id, b.fk_a ). Из b удаляешь колонку fk_a. Всё. В чём подвох?

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

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

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