Ale
При том даж в смолтоке класс это такой же объект, просто создающий другие объекты (фабрика)
Ale
Просто если говорить "именно класса", то будет проблема с тем, что такое класс
Ale
В разных языках это разные штуки
Vladimir
Да в общем то не особо разные
Artur
Сколько можно один и тот же бред повторять
то есть вы, Владимир, выбрали бы монго для построения системы учёта финансов, или, например, учёта товарных остатков?
Vladimir
Нет, не выбрал бы. Но по другой причине
Vladimir
Хотя если под целостностью данных подразумевается логическая конститентность между документами, то под этой
Ale
Вот и транзакция)
Vladimir
Увы не всегда это возможно
Ale
Другие аггрегаты должны обновляться в рамках жругих транзакций
Ale
Ну короче, выделив границы транзакций все равно куда их пихать
Ale
Лишь бы опыт был
Vladimir
Увы, это приводит к дикому геморрою
Vladimir
Например, нужно создать два документа за раз
Vladimir
Создаём первый, затем второй
Anton
еще камень в сторону монгу, оно не могет апдейтнуть элемент во вложенном масиве, по-моему это зашквар лютый
https://jira.mongodb.org/browse/SERVER-831
Vladimir
Но при последующей обработке при наличии первого нельзя рассчитывать на наличие второго
Vladimir
Приходится делать фоновые процессы, которые чинят такие связи
Vladimir
Или read repair
Ale
У тебя было две транзакции
Vladimir
Нет, была одна, логическая
Ale
Ну в монге транзакция это работа с одним документом
Vladimir
Недавно изучил протокол монги и бсон, там уже куча смешного
Roman
да говно монга это всем понятно, вопрос что вместо для нее для schema-less хранилищ
A
Ну в монге транзакция это работа с одним документом
Ну, все же не транзакция, а атомарная операция. Откатить-то нельзя))
Vladimir
В общем если в монге нужна консистентность между документами, то не избежать исхищрений
A
да говно монга это всем понятно, вопрос что вместо для нее для schema-less хранилищ
не, монга норм. Просто на нее не положить столько разных моделей данных (понятное дело, связи в первую очередь) как на реляционку
Vladimir
И при этом в итоге будет максимум eventual consistency
Vladimir
Но для большинства случаев это норм
Vladimir
Вообще я бы на постгре бы сейчас перешёл, если бы было время на это
Roman
В общем если в монге нужна консистентность между документами, то не избежать исхищрений
если кто-то пытается поддержиавать 100% консистентность в монге, с ним что-то не так
Roman
Вообще я бы на постгре бы сейчас перешёл, если бы было время на это
бесят миграции в RDBMS, к тому же в ноде нет ничего для этого нормального
A
Ну и опять же, надо понимать, что выбирая монгу ты выбираешь шардинг, репликацию, вот это вот всё. И вот этого всего нету в реляционке, и, вообще говоря, и не может быть без трейд-офф либо по перфомансу, либо по ACID
Roman
вот джанга + rdb это приятно
Vladimir
Это да, я бы начал копать в сторону json полей
A
Ага
Vladimir
Если там есть индексы, то можно жить
Roman
Ну и опять же, надо понимать, что выбирая монгу ты выбираешь шардинг, репликацию, вот это вот всё. И вот этого всего нету в реляционке, и, вообще говоря, и не может быть без трейд-офф либо по перфомансу, либо по ACID
за репликацию многие топят, но это же дичь сколько данных надо, чтобы понадобился дистрибутед шардинг
A
Vladimir
Большинству не нужен шардинг
Vladimir
Если бы мне нужен был шардинг, то я бы не стал его на монге делать
A
Ага
A
Почему?
Vladimir
Хз, есть какое то чувство что это тупиковый путь
A
А шардинг затащить в приложение?
Vladimir
Не, взять ориентированную на шардинг субд для этих данных
Ale
но вообще постгря норм
Vladimir
Riak, Cassandra, etc
Ale
активно юзаем jsonb
Vladimir
Riak должен быть относительно прост во всех аспектах
Ale
да, вполне, но пока туда value-objects складываем
Ale
и списки
Ale
если они особо не нужны вне сущности, что обычно так
Artur
Хотя если под целостностью данных подразумевается логическая конститентность между документами, то под этой
Да, целостность данных - это как раз отсутствие битых ссылок, пустых значений в NOT NULL колонках и так далее
Vladimir
Вообще это конечно удобно, но это олдскульный подход с переносом части бизнес логики в БД
Artur
Вообще это конечно удобно, но это олдскульный подход с переносом части бизнес логики в БД
А кто говорит про логику? Допустим я пытаюсь удалить юзера, а на него ссылки с других таблиц. Я в приложении за этим следить должен?
Roman
хранимки!
Roman
Michael
Ребята, а в чем может быть проблема. Поставил постгрю. Спокойно могу делать коннект через psql -U postgres. Сетаплю себе sequelize. Делаю коннект к БД с нужными кредами. Но выпадает ошибка
SequelizeBaseError: password authentication failed for user "ubuntu.username". Почему он пытается юзать убунту юзера, а не того, что я отдал в конфиге ?
Artur
Да просто foreign key
Artur
БД не должна допускать несогласованности того что в ней лежит
Roman
Ребята, а в чем может быть проблема. Поставил постгрю. Спокойно могу делать коннект через 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
Vladimir
БД не должна допускать несогласованности того что в ней лежит
Это зависит от разделения ответственности
Ale
для меня было неожиданностью, что люди не просто так делают, а еще топят за то, что это ок и так надо
Ale
что psql крутой язык для бизнес-логики
Artur
Несогласованности не будет. Если данные важны то ставишь ON DELETE RESTRICT