Но для большинства случаев это норм

Вообще я бы на постгре бы сейчас перешёл, если бы было время на это

В общем если в монге нужна консистентность между документами, то не избежать исхищрений

если кто-то пытается поддержиавать 100% консистентность в монге, с ним что-то не так

Вообще я бы на постгре бы сейчас перешёл, если бы было время на это

бесят миграции в RDBMS, к тому же в ноде нет ничего для этого нормального

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

вот джанга + rdb это приятно

Это да, я бы начал копать в сторону json полей

Вообще я бы на постгре бы сейчас перешёл, если бы было время на это

json поля?

Ага

Если там есть индексы, то можно жить

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

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

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

это уже другой вопрос)))

Большинству не нужен шардинг

Если бы мне нужен был шардинг, то я бы не стал его на монге делать

Ага

Почему?

Хз, есть какое то чувство что это тупиковый путь

А шардинг затащить в приложение?

Не, взять ориентированную на шардинг субд для этих данных

но вообще постгря норм

Riak, Cassandra, etc

активно юзаем jsonb

активно юзаем jsonb

удобно?

Riak должен быть относительно прост во всех аспектах

да, вполне, но пока туда value-objects складываем

и списки

если они особо не нужны вне сущности, что обычно так

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

Да, целостность данных - это как раз отсутствие битых ссылок, пустых значений в NOT NULL колонках и так далее

Вообще это конечно удобно, но это олдскульный подход с переносом части бизнес логики в БД

Если там есть индексы, то можно жить

Есть индексы, ещё и jsonb поля

Вообще это конечно удобно, но это олдскульный подход с переносом части бизнес логики в БД

А кто говорит про логику? Допустим я пытаюсь удалить юзера, а на него ссылки с других таблиц. Я в приложении за этим следить должен?

хранимки!

Ребята, а в чем может быть проблема. Поставил постгрю. Спокойно могу делать коннект через psql -U postgres. Сетаплю себе sequelize. Делаю коннект к БД с нужными кредами. Но выпадает ошибка SequelizeBaseError: password authentication failed for user "ubuntu.username". Почему он пытается юзать убунту юзера, а не того, что я отдал в конфиге ?

Да просто foreign key

А кто говорит про логику? Допустим я пытаюсь удалить юзера, а на него ссылки с других таблиц. Я в приложении за этим следить должен?

Да

Да

Нет

БД не должна допускать несогласованности того что в ней лежит

Ребята, а в чем может быть проблема. Поставил постгрю. Спокойно могу делать коннект через psql -U postgres. Сетаплю себе sequelize. Делаю коннект к БД с нужными кредами. Но выпадает ошибка SequelizeBaseError: password authentication failed for user "ubuntu.username". Почему он пытается юзать убунту юзера, а не того, что я отдал в конфиге ?

http://stackoverflow.com/questions/2942485/psql-fatal-ident-authentication-failed-for-user-postgres

хранимки!

вот тебе смешно https://habrahabr.ru/post/321050/#comment_10056294

БД не должна допускать несогласованности того что в ней лежит

Это зависит от разделения ответственности

для меня было неожиданностью, что люди не просто так делают, а еще топят за то, что это ок и так надо

А кто говорит про логику? Допустим я пытаюсь удалить юзера, а на него ссылки с других таблиц. Я в приложении за этим следить должен?

Удалять связанные данные?

что psql крутой язык для бизнес-логики

БД не должна допускать несогласованности того что в ней лежит

гыгы. ON DELETE CASCADE ))))

гыгы. ON DELETE CASCADE ))))

И что смешного?

что psql крутой язык для бизнес-логики

ооп, модули, типажи, полиморфизм для лохов короч

Несогласованности не будет. Если данные важны то ставишь ON DELETE RESTRICT

То, что если у тебя к этом пользователю много связей, то ты еще и полбазы себе вынесешь)

То, что если у тебя к этом пользователю много связей, то ты еще и полбазы себе вынесешь)

ON DELETE RESTRICT

Ну тогда ты и не удалишь ничего толком)

что psql крутой язык для бизнес-логики

У меня в проекте часть логики там. Это адок конечно, я даже дебаггер для pgAdmin поднимал :)

Вообще удаление в реляционках это такая вещь...

У меня в проекте часть логики там. Это адок конечно, я даже дебаггер для pgAdmin поднимал :)

Гусарам сразу скажу, что досталось в наследство

по нашим наблюдениям у монги начинаются проблемы когда размер индексов выходит за размер доступной RAM. загружали базу размером 700 гб (по сути логи). когда индексы стали болше RAM (64гб) - вставка стала очень медленной

Ну тогда ты и не удалишь ничего толком)

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

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

Если ты сам конечно не джун

по нашим наблюдениям у монги начинаются проблемы когда размер индексов выходит за размер доступной RAM. загружали базу размером 700 гб (по сути логи). когда индексы стали болше RAM (64гб) - вставка стала очень медленной

так они сами об этом на сайте и пишут

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

и тут мы внезапно приходим вот к этому: > @vkurchatkin Это зависит от разделения ответственности

Запрещать джунам коммитить в репозиторий слово DELETE?

Код ревью делать на 10 человек, в надежде что кто-то заметит?

И всё только ради того чтобы внешний ключ не вешать?

Как мы от баз данных перешли к управлению персоналом?)

Как будто субд мешает удалять

ERROR: S client not available

Она мешает удаляет неконсистентно

Она мешает удаляет неконсистентно

О чём и речь

Ну удалит твой джун консистентно- сильно лучше станет?

А как же ручной комит? У него то неплохие гарантии. Ну как напишешь конечно но получше.

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

Да причем тут джуны? ))) Речь о том, что если ты в реляционке начнёшь что-то удалять, то быстро упрёшься в свои же связи. И либо cascade, что обычно не то, что ты хочешь, либо restrict, который скорее всего ничего не удалит. Ты там выше зачем-то предлагал убирать констрейнты. Не знаю зачем. Все нормальные парни в случае связанных данных ничего не удаляют. Обычно в таких случаях данные помечаются удаленными. И либо когда-то там бэкграундная джоба что-то сделает, чтобы распутать эту связь, либо оно так и остаётся висеть. Плюс к этом надо добавить еще то, что при интенсивном удалении возрастает нагрузка и на индекс, и на, скажем так, чтение данных. Не знаю как там у вас это делают, а у нас обычно слово DELETE вообще не фигурирует нигде, никак и никогда.

> @wertlex Все нормальные парни в случае связанных данных ничего не удаляют. Обычно в таких случаях данные помечаются удаленными. Вот тоже верно

DELETED_AT

Да госпидя, это всё понятно. ON DELETE RESTRICT как раз таки поможет от случайного удаления

а с чего тут все началось, ревью в команде впадлу делать?

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

Всем peace

Целостность === консистентность

странный вывод)

Да причем тут джуны? ))) Речь о том, что если ты в реляционке начнёшь что-то удалять, то быстро упрёшься в свои же связи. И либо cascade, что обычно не то, что ты хочешь, либо restrict, который скорее всего ничего не удалит. Ты там выше зачем-то предлагал убирать констрейнты. Не знаю зачем. Все нормальные парни в случае связанных данных ничего не удаляют. Обычно в таких случаях данные помечаются удаленными. И либо когда-то там бэкграундная джоба что-то сделает, чтобы распутать эту связь, либо оно так и остаётся висеть. Плюс к этом надо добавить еще то, что при интенсивном удалении возрастает нагрузка и на индекс, и на, скажем так, чтение данных. Не знаю как там у вас это делают, а у нас обычно слово DELETE вообще не фигурирует нигде, никак и никогда.

Ну вот тебе нужно обновить 2 документа. Задача стала проще?

Есть ощущение что ничего не поменялось

блин, ну норм так про бд тему поднял

короче mysql я понял

)

А я просто задал вопрос идиотский...

Ну вот тебе нужно обновить 2 документа. Задача стала проще?

нуу... намного. в реляционке я открою транзакцию, обновлю оба документа, и закрою транзакцию))

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

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

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

для бложиков с коментариями мне кажется как раз rdb идеально

просто, надежно + джоины

next.js вдохновлялся простотой php

Next.js про конвенции, и высокоуровневые абстракции

Next.js про конвенции, и высокоуровневые абстракции

Верно

Я. Пытался. Но оно поломали зависимости на проде и сервер завис грузя трехгиговый файл

апдейт. попытался загрузить файлик из сетки с норм пропускной способностью - успех

парни кто юзает node-telegram-bot-api, как передать тест с форматированием, например жирный

парни кто юзает node-telegram-bot-api, как передать тест с форматированием, например жирный

напиши в его чатик, зачем всё заспамливать?

я напилс, просто там послединй ответ 2 часа назад

не дождался ответа и напился