Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?

А вот можно поподробнее про acid не нужен?? По моему это радикально упрощает работу с данными в многопользовательском режиме. И нужны ну просто ОЧЕНЬ весомые аргументы, чтоб отказываться от того, что дает тебе база на халяву.

Здравствуйте, IncremenTop, Вы писали:

IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной б

А если к разным? А если к одной, но разные схемы с тем чтобы в перспективе можно было разнести на разные физические базы?

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

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

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

Здравствуйте, IncremenTop, Вы писали:

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

IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд,

Где куча микросервисов лазит к одной БД?

IT>И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.

Бывает. Некоторые архитекты и не такое учудяют.

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?

Почему нет? РСУБД это удобно. И с чего ты взял что ACID нужен только в финтехе. ACID на самом деле нужен практически везде, просто не везде за него готовы платить.

IT> За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени.

Почему неудобно? Очень удобно. Специализированные time series db ничуть не более удобны, их плюс не в удобстве, а в том что они жрут в хайлоаде меньше ресурсов. Но небольшие проекты это, как правило, и небольшая нагрузка, на которой особой разницы между RDBMS и TSDB по ресурсам нет, а зрелость, развитые средства и богатый функционал первых остается.

Здравствуйте, IncremenTop, Вы писали:

IT>2. И я не против РБД. Мне непонятно, зачем их применять там, где они избыточны/не подходят.

на старте проекта могут быть не понятны требования, чтобы грамотно оценить и выбрать специфическую NoSQL.
да и как то не приходит на ум сразу "вариант выбора".
Вот недавно исследовал на предмет выбора Timeseries DB. пробовал Influx, OpenTSDB, Graphite. Ну медленные же они, комьюнити жидкое. да и надежность показалась так себе, Influx часто на пустом месте просто отваливался. В результате остановился на TimescaleDB — которая по сути надстройка над Postgres( РБД )


При этом про РБД все известно и понятно, все шишки давно набиты.

Ну и при грамотной организации кода, сползти с РБД на NoSQL как правило проще чем в обратном направлении

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
Альтернативы какие предлагаешь? Key value store? Да, на первом этапе это выглядит как нормальное решение. Однако потом бизнеслогика даже небольшого проекта разрастается. Начинаются потребности в миграциях данных и рефакторинге схемы данных. Появляется необходимость в поиске по другим критериям, отличным от дай мне объект по идентификатору. И в результате начинаем на ровном месте писать считай свою реляционную надстройку над key value store, и там, где целостность данных у нас проверяет реляционка посредством внешних ключей, уникальных ключей, тут ты этот функционал хреначишь ручками сам. И это я не говорю о таких приколах, как возможные повреждения самого персистентного файла. Плавал, знаю. Одно время тоже повелся на то, что щас без реляционки обойдусь, мне нужна только простейшая персистентность. И блин прямо перед релизом потребовался функционал, который в реляционки из коробки. В срочном порядке практически за сутки поменял хранилище на реляционку и реализовал недостающую логику на ней, вот только кое что поменять не успел, в результате чего кое что осталось по старому и потом огребал проблемы с целостностью данных. С тех пор реляционки я ОЧЕНЬ люблю и считаю это решением по умолчанию практически для всего. Хотя вот конкретно сейчас у меня снова все хранится непосредственно в файловой системе как memory mapped files, а из реляционки я только изначально все вычитываю, реляционка у меня только на чтение, но тут уже идет специфика проекта. Круто без реляционки только в самом начале проекта. А далее требования и хотелки меняются, и уже очень сильно либо жалеешь что не стал делать на реляционке сразу.

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

Здравствуйте, IncremenTop, Вы писали:

IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
На кой чёрт нужны микросервисы в небольшом проекте?!?

Здравствуйте, IncremenTop, Вы писали:

IT>Как ты будешь писать юнит-тесты?
Молча.

IT>Как ты будешь поддерживать и сопровождать этот код на sql?
Э-э-э... А в чём принципиальная сложность?
В том, что конкретно ты не знаешь sql?

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

IT>Аргументы, что суть микросервисной архитектуры именно в распределенность — в возможности масштабировать разные части системы.
Название твоего же топика "зачем N в небольших проектах".
Так зачем там микросервисы? Что там вообще надо масштабировать в небольших проектах, да еще частями?

IT>Я не спорю, что на SQL можно даже космолеты программировать. Но зачем?
Просто, надёжно, удобно. Не космолёты программировать, а с данными работать.
В том числе в эксплуатации.

Здравствуйте, torvic, Вы писали:

T>Здравствуйте, IncremenTop, Вы писали:
>> но когда куча микросервисов лазит к одной бд...
T>а в чём проблема?
T>и какая альтернатива для медицинских данных, как в этом случае?

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

Здравствуйте, IncremenTop, Вы писали:

IT>Возьмем документоориентированные БД — у тебя уже в БД хранится та самая дтошка и на уровне документа как раз поддержка есть.
IT>Никаких джойнов как раз не надо. Даже порой схему не надо разрабатывать, если совсем уж надо быстро.

Потом проект растет, нужно делать всякие репорты и хитрые запросы, на которых документоориентированные БД чаще всего сливают

Здравствуйте, IncremenTop, Вы писали:

IT>Хотя я не писал хранимки в монге, так что может быть с точки зрения ХП ты и прав.

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

Здравствуйте, IncremenTop, Вы писали:


IT>Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
Не получается. Просто это уже не микросервисы в классическом понимании. Но вполне рабочая и удобная архитектура для многих случаев.

IT>И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.
Не все архитекторы стремятся сделать "модно молодёжно".
Некоторые делают так, как разумно в их конкретной ситуации с учётом всех требований и ограничений.

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?
Чаще всего в финтехе ACID как раз нужен. Собственно, он всегда нужен, просто в больших проектах или в распределённых транзакциях им иногда жертвуют в угоду масштабируемости.

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

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Шоб вам многоэтажные запросы в монгодб отлаживать.

Здравствуйте, IncremenTop, Вы писали:

C>>На кой чёрт нужны микросервисы в небольшом проекте?!?
IT>Это была затравка к обсуждению

В результате которой ты исказил смысл и выдал какой то сумбур.

IT>и скорее надо спросить так — зачем нужны микросервисы в системе с одной реляционной бд?

О, а на этот вопрос ответить легко. Потому что модно и молодежно, так в статьях написано. Года полтора назад очередной бой выдержал на эту тему. Аргументы любителей микросервисов как под копирку — микросервисы позволяют каждой команде писать как хочешь на чем хочешь. В своей части проекта (в ядре) удалось от микросервисов отпихаться. А вот соседний департамент таки решил поступить модно и молодежно. В результате через год модной и молодежной разработки начальника департамента убрали за тотальный просер всех сроков и занятие не тем чем надо, а на его место забрали одного из наших тимлидов. И он сейчас срочно микросервисы и 100500 репов на каждый мелкий пиписькосервис оттуда вычищает.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, Слава, Вы писали:

С>>Напишите пожалуйста конкретнее, на примерах если можно.

IT>Не понял.
IT>У нас есть, допустим, две таблицы — кастомеры и книги. К ним ходят разные классы дата слоя. Если нужно в рамках одного бизнес-процесса изменить обе, то это выполняется на уровне бизнес-логики. Собственно, избитый корень агрегации о том же.
Этот пример иллюстрирует лишь возможность обходиться без хранимок. Но в чем же тут проигрывает sql не понятно. Да, и не ясно, в чем выигрывает документоориентированная база?

Здравствуйте, IncremenTop, Вы писали:

IT>Как ты будешь писать юнит-тесты?
По части тестов реляционная база нием не отличается от не реляционной.
Точно так же моками.

IT>Как ты будешь поддерживать и сопровождать этот код на sql?
Обыкновенно, как любой другой код, что смущает-то?

IT>Это удобно лишь при разработке определенным категориям людей, которые все вопросы решают одной хранимкой, которая лазит по базе.
V>>Аргументы?
IT>Аргументы, что суть микросервисной архитектуры именно в распределенности — в возможности масштабировать разные части системы. Но вместо этого у нас появляется единая точка отказа, причем в которой еще находится логика. Зачем тогда микросервисы?
Это не микросервисы и об этом я писал. Но это не значит, что система плохая.
А микросервисами эту систему назвали Вы. А теперь, получается, Вы критикуете свой же термин.
Единая точка — отказа — это не так, база вполне может быть кластером.

Здравствуйте, IncremenTop, Вы писали:

IT>1. Я не против хранимок в принципе, но это должно быть под строгим контролем.
Как и код в принципе.

IT>Неоднократно наблюдал, как разработчики пытались решить все проблемы одной хранимкой.
А монструозных методов и функций, пытающихся решить все проблемы одним вызовом, ты не наблюдал разве?
Дяденька, а Вы настоящий сварщик?

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

IT>2. И я не против РБД. Мне непонятно, зачем их применять там, где они избыточны/не подходят.
Мне тоже.

Там, где достаточно файла/файлов для хранения, разумеется не место РСУБД, это явно избыточно.
Но "избыточны" и в качестве альтернативы "неизбыточного" для небольших проектов предлагать noSQL? Это серьёзно сейчас было?
Я понимаю, есть сценарии, где noSQL того или иного рода будет лучше альтернатив. Но это не про избыточность или неизбыточность, ИМХО, и не про размер проектов.

Здравствуйте, mogadanez, Вы писали:

M>он имеет ввиду если именно бизнес-логика в хранимках

А что, это обязательно так делать?

Здравствуйте, Jack128, Вы писали:

J>А вот можно поподробнее про acid не нужен?? По моему это радикально упрощает работу с данными в многопользовательском режиме. И нужны ну просто ОЧЕНЬ весомые аргументы, чтоб отказываться от того, что дает тебе база на халяву.

Возьмем документоориентированные БД — у тебя уже в БД хранится та самая дтошка и на уровне документа как раз поддержка есть.
Никаких джойнов как раз не надо. Даже порой схему не надо разрабатывать, если совсем уж надо быстро.

Здравствуйте, IncremenTop, Вы писали:

J>>А вот можно поподробнее про acid не нужен?? По моему это радикально упрощает работу с данными в многопользовательском режиме. И нужны ну просто ОЧЕНЬ весомые аргументы, чтоб отказываться от того, что дает тебе база на халяву.

IT>Возьмем документоориентированные БД — у тебя уже в БД хранится та самая дтошка и на уровне документа как раз поддержка есть.
IT>Никаких джойнов как раз не надо. Даже порой схему не надо разрабатывать, если совсем уж надо быстро.
Ну так можно и просто в файл сложить, зачем тогда вообще база?
Смысл документ-ориентированных баз в возможности операции частями документа и в возможности ограничений его структуры.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, mogadanez, Вы писали:

M>>Потом проект растет, нужно делать всякие репорты и хитрые запросы, на которых документоориентированные БД чаще всего сливают

IT>Т.е. проект растет и не надо его масштабировать? Отлично.
Чаще всего так и бывает — функциональность растёт быстро, а нагрузка значительно медленнее.

--
WBR,
Serge.

Здравствуйте, Слава, Вы писали:

С>Шоб вам многоэтажные запросы в монгодб отлаживать.
При том уровне выразительности на котором пребывает язык запросов к монгодб, любой запрос сложнее find превращается гипертрофированную многоэтажную конструкцию.

ACID желателен везде. Сейчас даже в мобильных ToDoList-ах используется СУБД (Sqlite). Нужно придумать вескую причину, чтобы не использовать нормальную РСУБД для хранения данных в любом приложении.

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, _ABC_, Вы писали:

IT>>>Молча подключишь ci/cd к автотестам на свои хранимки?
_AB>>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.
V>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"

строго говоря в setup/teardown можно убивать все и создавать новое.

Здравствуйте, IncremenTop, Вы писали:

IT>Это отсекается на код-ревью, да и в принципе сейчас даже студия экспресс поддерживает парное кодирование.
И что мешает делать код-ревью для SQL?

IT>Чтобы аналогичное сделать для кода на sql — уже надо извращаться.
Почему? Работа идет в той же самой студии, в том же самом гите, можно создавать точно так же пул реквесты, запросы на код ревью и т.д. В чём разница-то?

Здравствуйте, IncremenTop, Вы писали:

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

первый хреново гуглится https://i.imgur.com/utvSlI6.png

сайт второго не впечатлил
https://elisdn.ru/blog/140/php-frameworks-for-enterprise
"Фреймворки и инструменты PHP для Enterprise" — серьезный уровень, да...

Здравствуйте, _ABC_, Вы писали:

IT>>Чтобы аналогичное сделать для кода на sql — уже надо извращаться.
_AB>Почему? Работа идет в той же самой студии, в том же самом гите, можно создавать точно так же пул реквесты, запросы на код ревью и т.д. В чём разница-то?

Человек просто плохо знаком с RDBMS и с SSDT в частности, поэтому у вас разговор напоминает разговор слепого с глухим.

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?
ACID это здравый смысл, он нужен всегда.
Не всегда он нужен в базе данных, так как механизмы обепечения acid тяжеловесные, для ускорения иногда можно взть не-acid базу и сделат acid силами приложения.
Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.

IT>За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени.
А чего неудобного в хранении таких данных в БД?

IT>Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная. А учитывая навороченные инструменты работы с РСУБД в совремеенных язках, еще и довольно удобная для программиста.

Здравствуйте, IncremenTop, Вы писали:

IT>Нет, в многих нагруженных систем от него ушли в сторону саги.
Вынужденно ушли.

IT>Потому что почти всегда нужна асинхронность на уровне процессов.
Э-э-э... Я понял в чём твоя проблема. Ты решение принимаешь за цель.
Нужна не асинхронность на уровне процессов, а время отклика.

G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.
IT>Аcid — это такое же перепроектирование
Какое "такое же перепроектирование", если речь идёт о преждевременной оптимизации?

IT>Опустим то, что это надо проектировать, а не из коробки использовать.
А что есть решение, которое можно в любом проекте из коробки использовать, а не проектировать что-то с использованием этого решения?

IT>Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.
Подробнее можно?

IT>При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее.
За счёт чего? Быстрее чего? На каких сценариях быстрее?

IT>Прошло почти полсотни лет.
А дважды два, по-прежнему, четыре. Доколе?!

Здравствуйте, Miroff, Вы писали:

M>Большинство разработчиков просто не умеют работать с другими хранилищами данных кроме СУБД. Для них даже картинки в файлах хранить это уже rocket science. А когда они все же это делают, они настолько боятся ошибиться что принимают очень странные решения в духе "мы вообще никогда ничего не будем удалять, только добавлять новое"

M>Для них даже картинки в файлах хранить это уже rocket science.

И они совершенно правы. Именно поэтому так популярен S3, CloudFront и прочие CDN

Files are hard

https://danluu.com/file-consistency/

Gt_>>достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.

S>А с чего это она выиграет у промышленной рсубд?

потому что монга сильно примитивней, не будет разбора SQL и поиска его в library cache, не будет оптимизатора, строящего план запроса.

Gt_

Здравствуйте, Слава, Вы писали:

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



Т.е. ты на серьезных щщах утверждаешь, что легче менять что-то в сильно-связанной системе, чем в слабосвязанной?

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

Вакансия:
"-Разработка высоконагруженного бэкенда для медицинского приложения;

базовые принципы современной разработки ПО: IoC/DI, слабая связанность, разделение по слоям и компонентам, логирование, пригодность кода для юнит-тестирования;
отличное знание любой промышленной реляционной базы данных: нормализация/денормализация таблиц, представления, индексы, хранимые процедуры, оптимизация запросов;
опыт разработки с помощью фреймворков для MS .Net ASP.Net MVC / WebAPI;
организация доступа к БД SQL из кода MS.Net: Entity Framework, преимущества и ограничения использования ORM;
опыт участия в разработке высоконагруженных и масштабируемых сервисов;
распараллеливание вычислений, доступ к данным, кэширование, опыт использования RabbitMQ для транспорта сообщений;"

Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:


И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.

Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Здравствуйте, IncremenTop, Вы писали:
> но когда куча микросервисов лазит к одной бд...
а в чём проблема?
и какая альтернатива для медицинских данных, как в этом случае?

Здравствуйте, vmpire, Вы писали:

V>Не получается. Просто это уже не микросервисы в классическом понимании. Но вполне рабочая и удобная архитектура для многих случаев.

Это неудобно в принципе. Удобно это лишь людям, которые пишут логику на хп.

V>Не все архитекторы стремятся сделать "модно молодёжно".

Этот дурень как раз взял худшие стороны со всех подходов.

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

IT>>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?
V>Чаще всего в финтехе ACID как раз нужен. Собственно, он всегда нужен, просто в больших проектах или в распределённых транзакциях им иногда жертвуют в угоду масштабируемости.

Прочитай внимательнее, что я написал — не из мира финтеха.

И да — распределенные транзакции применяются очень редко.

V>Небольшое количество данных, привязанных ко времени, достаточно просто хранить в реляционных базах.

Просто в реляционных не получится.

Здравствуйте, IncremenTop, Вы писали:

V>>Чаще всего в финтехе ACID как раз нужен. Собственно, он всегда нужен, просто в больших проектах или в распределённых транзакциях им иногда жертвуют в угоду масштабируемости.

IT>Прочитай внимательнее, что я написал — не из мира финтеха.

И вне мира финтеха ACID — это очень хорошо/

IT>И да — распределенные транзакции применяются очень редко.

И как это отменяет необходимость acid?

Здравствуйте, IncremenTop, Вы писали:

V>>Не получается. Просто это уже не микросервисы в классическом понимании. Но вполне рабочая и удобная архитектура для многих случаев.
IT>Это неудобно в принципе. Удобно это лишь людям, которые пишут логику на хп.
Не очень понял, что именно неудобно.

V>>Не все архитекторы стремятся сделать "модно молодёжно".
IT>Этот дурень как раз взял худшие стороны со всех подходов.
Аргументы?

IT>И модно-молодежно это было лет 10 назад, сейчас уже архитектор, которые знает только реляционные профнепригоден.
Никто не говорил, что он больше ничего не знает. Речь шла об оптимальности решания в конкретных условиях.

V>>Небольшое количество данных, привязанных ко времени, достаточно просто хранить в реляционных базах.
IT>Просто в реляционных не получится.
Вот сейчас удивились бы производители реляционных баз, которые туда возможность создания темпоральных таблиц давно ввели.
Да и просто колонку с датой валидности добавить несложно.
Запросы будут подтормаживать, но для небольших объёмов данных это несущественно.

Здравствуйте, IncremenTop, Вы писали:

С>>Шоб вам многоэтажные запросы в монгодб отлаживать.

IT>Я же не извращенец, чтобы на документо-ориентированной реализовывать реляционную.

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

Здравствуйте, mogadanez, Вы писали:

M>Потом проект растет, нужно делать всякие репорты и хитрые запросы, на которых документоориентированные БД чаще всего сливают

Т.е. проект растет и не надо его масштабировать? Отлично.
Хитрые запросы — это логика в БД? Отлично.
Хорошие решения проблем роста.

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах ...

Из личного.

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

Её замутили после того как "устали" от относительно большой и сложной реляционной базы (FB), на которую натянули "объектную" модель, в другом (серьезном) проекте.

Ну так вот.

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

Но хорошо хоть такая база есть, потому что без неё просто утонешь.

Здравствуйте, IncremenTop, Вы писали:

IT>Молча подключишь ci/cd к автотестам на свои хранимки?
Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.

IT>Ага, я понимаю, что для комсомольцев нет невыполнимых задач.
Инструменты есть.

IT>Сложность в том, что диалекты SQL уступают любому современному языку на бэке, даже б-мерзкому джаваскрипту.
В чём конкретно? В работе с данными не уступают.
Кроме того, есть же возможность работать из кода. Linq2DB какой-там или ещё что-то.

IT>В том, что все трудно тестируемо, еще тяжелее это сопровождать — любой pgAdmin уступает даже старому jdeveloper-у.
Я пользуюсь Visual Studio для работы с SQL.

IT>В коде хранимок не он, а его диалект. Причем логика в процедурном стиле.
Не используй плохой диалект. Используй нормальные СУБД.

IT>Я утверждал, что они там нужны?
Ты тему своего топика видел вообще?

IT>Это точно о хранимках?
Это о работе с данными при помощи РСУБД.
Хранимки можно не использовать при желании.

Здравствуйте, IncremenTop, Вы писали:

IT>1. Как бы можно было придумать хотя бы библиотеку. Что за чудо-юдо сборник книг — непонятно, как и непонятно, зачем менять схему.
Отож. Сборник — это несколько книг под одной обложкой.
Вот, например:https://www.livelib.ru/book/1000558706-luchshie-fantasticheskie-romany-tri-velikih-puteshestviya-audiokniga-mp3-sbornik-zhyul-vern
Зачем менять схему?
Ну, например, для того, чтобы отразить этот факт: книга, вроде бы, одна (кусок отдельно не купишь), но авторов и названий в ней — три.
И это не произведение от трёх соавторов, а три самостоятельных произведения.
Можно бы на это забить, и хранить эти ненужные подробности внутри аннотации к книге; но тогда не будут работать запросы типа "дай мне список изданий 'Затерянный мир'".
IT> Ну и как вы должны понимать, то анала с миграцией данных в РБД еще больше. По сравнению с монгой — просто небо и земля.
Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода.
В Монге у меня возникает иллюзия, что всё это делать не надо. Просто нужно написать у себя в коде проверку, типа "если у книги есть .author — то хорошо, а если есть includedBooks — то это сборник".
В итоге через пять релизов у меня каждый "запрос" — это спагетти из вот таких if-ов, которые вообще непонятны новому разработчику в команде. Типа "нафига тут эта формула, зачем предполагать, что название — это book.Name || book.includedBooks[0].name?
IT>2. Что за большинство? Выборка по той же монге будет быстрее, также как и вставка. Главное, чтобы индекс в память умещался.

Здравствуйте, _ABC_, Вы писали:

IT>>Молча подключишь ci/cd к автотестам на свои хранимки?
_AB>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.
Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"

Здравствуйте, vmpire, Вы писали:

IT>>>Молча подключишь ci/cd к автотестам на свои хранимки?
_AB>>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.
V>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"

Ну и что? Про юнит-тесты речи же и не было. Там было "автотесты".

Здравствуйте, _ABC_, Вы писали:

_AB>А монструозных методов и функций, пытающихся решить все проблемы одним вызовом, ты не наблюдал разве?

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

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

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

серьезные спецы
https://elisdn.ru/portfolio
https://career.habr.com/kroniak

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

Здравствуйте, Gt_, Вы писали:

Gt_>серьезные спецы
Gt_>https://elisdn.ru/portfolio
Gt_>https://career.habr.com/kroniak

Серьезный у тебя анализ на основе профиля на хабре и однофамильца.

Да, один из альфы, другой из джетбрейнс. А ты у нас кто будешь?

Gt_>но дело не в опыте, а в сравнении на табличке блога с комментами ...

У тебя есть другой пример? Или только однофамильцы?

Здравствуйте, IncremenTop, Вы писали:


IT>За распределенный монолит надо увольнять из профессии, а тут еще хуже — распределенный монолит с хранимками. Франкенштейн собственной персоной.

а что не так с распределенным монолитом?

Здравствуйте, IncremenTop, Вы писали:

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

IT>Транзакционность на уровне одной "таблицы" поддерживают многие неРБД.

А ссылочную целостность они дают, если я передумаю и захочу через какое-то время разработки добавить и вторую таблицу? (у меня так и произошло на самом деле сейчас)

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>ACID это здравый смысл, он нужен всегда.
IT>Нет, в многих нагруженных систем от него ушли в сторону саги.
Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу.
Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".

IT>Потому что почти всегда нужна асинхронность на уровне процессов.
Асинхронность и ACID не связаны.

G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.
IT>Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.
Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД?

G>>А чего неудобного в хранении таких данных в БД?
IT>Опустим то, что это надо проектировать, а не из коробки использовать.
IT>Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.
Тут нужна конкретика.
Вот есть данные с вот такой схемой, и вот такие запросы.
Нереляционная БД Х делает вот такие запросы, а РСУБД — не может так делать, потому что У.
А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую релеляционную БД.

IT>При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее.
G>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.
IT>Прошло почти полсотни лет.
Теореме пифагора уже тысячи лет, это не делает её менее верной.
В мире математики рулит доказательство, а не частное мнение. Неуниверсальность РСУБД надо доказать. Для этого надо описать класс данных (схемы) и операции над ними, которые запросами в РСУБД сделать невозможно или крайне сложно и неэффективно.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, gyraboo, Вы писали:

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

IT>Транзакционность на уровне одной "таблицы" поддерживают многие неРБД.

Ты путаешь. Транзакционность (то есть атомарность, зачастую даже без долговечности) на уровне одной ЗАПИСИ поддерживают все базы, в рамках одного инстанса конечно же. Иначе было бы сильно сложнее сделать.
Транзакционность (ACID) на уровне одной таблицы поддерживют РСУБД и технически она реализуется также, как и транзакционность на уровне нескольких таблиц.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу.
G>>Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".

IT>Нет. Когда я покупаю товар, то я делаю несколько действий. Т.е. это сага.
IT>Мало того, товар может зарезервироваться на складе, но оплата не прошла и логично не откатить все, а предложить пользователю попробовать еще раз. И это тоже возможно в рамках саги.
И все это обладает признаками ACID. Оплата не прошла — товар не поставлен, прошла — поставлен.
Еще раз: асинхронность и ACID не связаны.
Если у тебя в рамках "саги" (очередной модный термин) какой-то из шагов не поддерживает транзакции и ACID, то придется самостоятельно приседать чтобы обеспечить транзакционность всего процесса.




G>>Асинхронность и ACID не связаны.
IT>Связана.
Нет

IT>Если у вас в рамках транзакции 2 и более сервисов, то это распределенная транзакция, которые суть зло по сравнению даже со сложностью саги. И если взаимодействией асинхронное между сервисами, то либо вы еще транзакционность добавляете в шину(а это очень медленно), либо это уже транзакция-сага. Непонятный франкенштейн.
Ты очень сильно привязываешься в техническим деталям вместо понимания сути транзакций.

IT>В итоге либо вы шлете к чертям ДДД вместе с кроликами и кафкой, либо вы шлете к чертям 2pc.
Послать подальше ДДД это хорошо, остальное я даже не понял о чем речь.


G>>Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД?
IT>Я говорю о табличках, потому что мы не определились, какую NoSQL бд описываем. Терминология даже у еластика плавает от версии к версии.
"Таблички" == реляционная модель == удобно использовать ЛЮБУЮ РСУБД. Все РСУБД построены на основе одно и того же набора операций.

IT>Я ничего не сказал о взаимосвязях.
И не надо. Это ни на что не влияет.

G>>А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую нерелеляционную БД.
IT>Так я перечислил эти фичи.
Сосредоточься. Я говорю что сравнивать по фичам БЕСПОЛЕЗНО. Нужны схемы данных и запросы.


G>>>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.
IT>Они это не доказывали, цель была в том чтобы построить максимально полную, непротиворечивую и неизбыточную модель.
Они это доказывали.



IT>Выше я давал примеры, когда монга по скорости была гораздо эффективнее постгре.
Логично что кэш быстрее не самой шустрой РСУБД.

IT>В принципе логично, что специализированный инструмент всегда будет эффективнее в рамках специализации универсального всемогутора.
Ты сейчас занимаешься предварительной оптимизацией.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>Транзакционность (ACID) на уровне одной таблицы поддерживют РСУБД и технически она реализуется также, как и транзакционность на уровне нескольких таблиц.

IT>Не путаю как раз. Транзакционность на уровне одной таблицы монгодб(собственно мультидокументную тоже уже поддерживается между разными репликами) поддерживает достаточно давно, не говоря о других БД.

Монга не поддерживает ACID на уровне таблицы.
Если ты уверен в обратном, то покажи как реализовать:
— Есть таблица счетов (балансов)
— Нужно реализовать операции перевода между счетам — уменьшить баланс на одном и увеличить на другом
— Баланс не должен опускаться меньше 0
— сумма балансов не должна меняться
— транзакции параллельные

Тут еще бывает так:
1) Приложение хранит финансовые данные
2) Используется oracle/mssql
3) В коде все запросы к базе в режиме без выставленных транзакций [Тут должен быть блюющий смайлик].

Здравствуйте, torvic, Вы писали:

T>а в чём проблема?

Тестируемость, масштабируемость, сопровождаемость.

За распределенный монолит надо увольнять из профессии, а тут еще хуже — распределенный монолит с хранимками. Франкенштейн собственной персоной.

Это как из всех подходов выбрать худшее.

Здравствуйте, vmpire, Вы писали:

V>Не очень понял, что именно неудобно.

Как ты будешь писать юнит-тесты?
Как ты будешь поддерживать и сопровождать этот код на sql?

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

V>Аргументы?

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

V>Никто не говорил, что он больше ничего не знает. Речь шла об оптимальности решания в конкретных условиях.

Оптимальностью не пахнет. Напоминает одного архитектора, который дропнул бэк и написал все на хранимках постгре.


V>Вот сейчас удивились бы производители реляционных баз, которые туда возможность создания темпоральных таблиц давно ввели.

Ну да, ты еще приведи слова Тома Кайта.
Я не спорю, что на SQL можно даже космолеты программировать. Но зачем?

Здравствуйте, Слава, Вы писали:

С>Шоб вам многоэтажные запросы в монгодб отлаживать.

Я же не извращенец, чтобы на документо-ориентированной реализовывать реляционную.

Здравствуйте, IncremenTop, Вы писали:

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

Да, именно. С условием "сохранить целостность данных". Без этого условия конечно можно менять что хошь.

IT>Сейчас особенно актуально последнее, когда все стали внезапно денормализовывать БД.

Тут в канале гоферов недавно люди обнаружили, что порядок колонок в индексе важен. Примерно поэтому и возник спрос на денормализацию.

Здравствуйте, Cyberax, Вы писали:

C>На кой чёрт нужны микросервисы в небольшом проекте?!?

Это была затравка к обсуждению и скорее надо спросить так — зачем нужны микросервисы в системе с одной реляционной бд?

Здравствуйте, Слава, Вы писали:

С>Да, именно. С условием "сохранить целостность данных". Без этого условия конечно можно менять что хошь.

Так в принципе не надо на документоориентрованных бд применять концепции из рбд.

С>Тут в канале гоферов недавно люди обнаружили, что порядок колонок в индексе важен. Примерно поэтому и возник спрос на денормализацию.

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

Здравствуйте, IncremenTop, Вы писали:

С>>Да, именно. С условием "сохранить целостность данных". Без этого условия конечно можно менять что хошь.
IT>Так в принципе не надо на документоориентрованных бд применять концепции из рбд.

Напишите пожалуйста конкретнее, на примерах если можно.

IT>Спрос был гораздо раньше, потому что вставка vs выборка. Это еще в лохматых учебниках 90-х было написано.

Это тема для отдельной ветки, я подожду ответа на мой вопрос про примеры.

Здравствуйте, _ABC_, Вы писали:

_AB>Молча.

Молча подключишь ci/cd к автотестам на свои хранимки?

Ага, я понимаю, что для комсомольцев нет невыполнимых задач.

_AB>Э-э-э... А в чём принципиальная сложность?

Сложность в том, что диалекты SQL уступают любому современному языку на бэке, даже б-мерзкому джаваскрипту.
В том, что все трудно тестируемо, еще тяжелее это сопровождать — любой pgAdmin уступает даже старому jdeveloper-у.

_AB>В том, что конкретно ты не знаешь sql?

В коде хранимок не он, а его диалект. Причем логика в процедурном стиле.

_AB>Так зачем там микросервисы? Что там вообще надо масштабировать в небольших проектах, да еще частями?

Я утверждал, что они там нужны?
У ренессанса далеко не мелкая система.

_AB>Просто, надёжно, удобно.

Это точно о хранимках?

Здравствуйте, Слава, Вы писали:

С>Напишите пожалуйста конкретнее, на примерах если можно.

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

Здравствуйте, IncremenTop, Вы писали:

зачем ты все сваливаешь в кучу

IT>Т.е. проект растет и не надо его масштабировать? Отлично.

проблема масштабирования будет независимо от того какая у тебя БД.
Фейсбук до сих пор в качестве основной базы Mysql использует

IT>Хитрые запросы — это логика в БД? Отлично.

те ты против хранимок — и поэтому реляционные БД тоже плохо?

Здравствуйте, mogadanez, Вы писали:

M>Фейсбук до сих пор в качестве основной базы Mysql использует

И php.

В одном случае есть решение из коробки, в другом — все гораздо сложнее.

M>те ты против хранимок — и поэтому реляционные БД тоже плохо?

1. Я не против хранимок в принципе, но это должно быть под строгим контролем.
Неоднократно наблюдал, как разработчики пытались решить все проблемы одной хранимкой.

2. И я не против РБД. Мне непонятно, зачем их применять там, где они избыточны/не подходят.

IT>Не понял.
IT>У нас есть, допустим, две таблицы — кастомеры и книги. К ним ходят разные классы дата слоя. Если нужно в рамках одного бизнес-процесса изменить обе, то это выполняется на уровне бизнес-логики. Собственно, избитый корень агрегации о том же.

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

Gt_

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, IncremenTop, Вы писали:

IT>>Как ты будешь писать юнит-тесты?
V>По части тестов реляционная база нием не отличается от не реляционной.
V>Точно так же моками.

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

Здравствуйте, Gt_, Вы писали:

Gt_>а теперь понадобилось добавить новую сущность — сборник книг, в noSQL это изменение в схеме "книга" + анал с миграцией данных в новую схему. при этом у большинства noSQL вторичных индексов нет, т.е. поиск по сборнику — полный перебор всех документов.

1. Как бы можно было придумать хотя бы библиотеку. Что за чудо-юдо сборник книг — непонятно, как и непонятно, зачем менять схему. Ну и как вы должны понимать, то анала с миграцией данных в РБД еще больше. По сравнению с монгой — просто небо и земля.

2. Что за большинство? Выборка по той же монге будет быстрее, также как и вставка. Главное, чтобы индекс в память умещался.

Здравствуйте, IncremenTop, Вы писали:

IT>2. Что за большинство? Выборка по той же монге будет быстрее, также как и вставка. Главное, чтобы индекс в память умещался.

Итак. По монге-то не столь много написано, а вот очень хороший материал про DynamoDB

Полюбуйтесь на совершенно неочевидные фокусы с запихиванием данных в key-value. Да, это очень хорошо работает, когда у вас уже есть стабильная схема и она не будет меняться.
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-relational-modeling.html

Здравствуйте, IncremenTop, Вы писали:

_AB>>Молча.
IT>Молча подключишь ci/cd к автотестам на свои хранимки?

В чем проблема и откуда вдруг взялись хранимки?

IT>Ага, я понимаю, что для комсомольцев нет невыполнимых задач.

Переход на личности демонстрирует слабость твоей аргументации.

_AB>>Э-э-э... А в чём принципиальная сложность?
IT>Сложность в том, что диалекты SQL уступают любому современному языку на бэке, даже б-мерзкому джаваскрипту.

Уступают в чем? В выборке и манипуляции с реляционными данными? Ты уверен?

_AB>>Так зачем там микросервисы? Что там вообще надо масштабировать в небольших проектах, да еще частями?
IT>Я утверждал, что они там нужны?
IT>У ренессанса далеко не мелкая система.

У тебя в сабже что написано?

M>>он имеет ввиду если именно бизнес-логика в хранимках

НС>А что, это обязательно так делать?

видимо задела фраза в исходном объявлении

Здравствуйте, IncremenTop, Вы писали:

IT>За распределенный монолит

а это что такое?

Здравствуйте, _ABC_, Вы писали:

_AB>Но "избыточны" и в качестве альтернативы "неизбыточного" для небольших проектов предлагать noSQL?

Не, ну NoSQL понятие растяжимое. Тот же LiteDB — тоже формально NoSQL.

Здравствуйте, mogadanez, Вы писали:

IT>>>Как ты будешь писать юнит-тесты?
V>>По части тестов реляционная база нием не отличается от не реляционной.
V>>Точно так же моками.

M>он имеет ввиду если именно бизнес-логика в хранимках
M>если ее замокать — часть логики будет непротестирована
Смотря что тестируем. Если ту логику, что в прцедурах, то мокать её, конечно, не нужно.

Здравствуйте, mogadanez, Вы писали:

IT>>>>Молча подключишь ci/cd к автотестам на свои хранимки?
_AB>>>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.
V>>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"

M>строго говоря в setup/teardown можно убивать все и создавать новое.
Да тут есть разные варианты. Например, можно всё в транзакции делать а в конце откатывать...
Но фанаты — такие фанаты... Не один раз уже с такими дискутировал.

Здравствуйте, vmpire, Вы писали:

V>Но фанаты — такие фанаты... Не один раз уже с такими дискутировал.

как то политкорректно, больше похоже на д@#$%в

S>Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода.

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

Gt_

Здравствуйте, fmiracle, Вы писали:

F>Ну и что? Про юнит-тесты речи же и не было. Там было "автотесты".
Цитирую

Автор: IncremenTop
Дата: 05.02.21

:
"IT>Как ты будешь писать юнит-тесты?"

Здравствуйте, Sinclair, Вы писали:

S>Ну, например, для того, чтобы отразить этот факт: книга, вроде бы, одна (кусок отдельно не купишь), но авторов и названий в ней — три.

Ок, предыдущая сущность по сути авторское произведение, а это будет другая — книга.
Связь между документами через ID, никаких вложенных. Изменение схемы минимально.

S>В Монге у меня возникает иллюзия, что всё это делать не надо. Просто нужно написать у себя в коде проверку, типа "если у книги есть .author — то хорошо, а если есть includedBooks — то это сборник".
S>В итоге через пять релизов у меня каждый "запрос" — это спагетти из вот таких if-ов,

Если ты не используешь миграции монги и валидаторы схемы, которые есть, а вместо этого предпочитаешь писать кучу if-в, так это ССЗБ.

S>

https://speakerdeck.com/dotnetru/nikolai-molchanov-i-dmitrii-ielisieiev-bitva-sql-vs-documentdb?slide=79

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

Здравствуйте, vmpire, Вы писали:

V>Цитирую

Автор: IncremenTop
Дата: 05.02.21

:
V>"IT>Как ты будешь писать юнит-тесты?"

"Молча подключишь ci/cd к автотестам на свои хранимки?"

Здравствуйте, _ABC_, Вы писали:

_AB>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.
_AB>Инструменты есть.

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

_AB>В чём конкретно? В работе с данными не уступают.

Бизнес-логика — это тоже по сути работа с данными.

_AB>Ты тему своего топика видел вообще?

Видел. Это была затравка к архитекторам из ада.

IT>Если ты не используешь миграции монги и валидаторы схемы, которые есть, а вместо этого предпочитаешь писать кучу if-в, так это ССЗБ.

и ради чего этот анонизм с миграциями ? транзакции тормозят, чуть сложнее запросы — сливает даже mysql, мягко говоря не чемпиону в плане разумности оптимизатора.


IT>https://speakerdeck.com/dotnetru/nikolai-molchanov-i-dmitrii-ielisieiev-bitva-sql-vs-documentdb?slide=79

IT>Но странно, что приходится доказывать даже такое, хотя даже исходя из структурных связей — монга должна быть быстрее.

достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.

Gt_

Здравствуйте, vmpire, Вы писали:

V>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"
Ну да, ты прав.
Изменяют базу, которая создается с нуля специально под раунд тестирования.
С логической точки зрения мало чем отличается от оперативной памяти, но религиозное нарушение есть, конечно.

Здравствуйте, IncremenTop, Вы писали:

IT>Я в курсе аналогичного стека для постгре, думаю, что вполне есть аналогичные мучения и для других, но это все монструозно и уныло.
Э-э-э... Да вообще нет особой разницы с тестами другого кода, вроде как?

IT>Все это трудноподдерживаемо в принципе
В чём разница с автотестированием, допустим, проекта на .Net Core?

IT>(если, кстати, нет подписки azure, то, видимо, собственный костыль)
Я работаю со своим стеком, поэтому не особо смотрю, что там по сторонам.
Но, насколько помню, SSDT бесплатны, сам фреймворк юнит тестов идёт вместе с ним. Насколько помню, реализация идёт через стандартный mstest.
А уж как к конкретной реализации пайплайна привязать вызов mstest.exe — это пусть девопсы по месту решают.

IT>Бизнес-логика — это тоже по сути работа с данными.
А еще всё вместе по сути работа с ноликами и единичками.

IT>Видел. Это была затравка к архитекторам из ада.
Т.е., заголовок твоей темы не соответствует содержанию твоей головы?
Ты бы так сразу и сказал, что хочешь обсудить кашу в своей голове, я бы время не тратил.

Здравствуйте, Gt_, Вы писали:

Gt_>и ради чего этот анонизм с миграциями ? транзакции тормозят, чуть сложнее запросы — сливает даже mysql, мягко говоря не чемпиону в плане разумности оптимизатора.

Ты точно смотрел ссылку, говоря про тормоза?

Gt_>достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.

Миллионы мух не могут ошибаться, да.

Хотя я не писал хранимки в монге, так что может быть с точки зрения ХП ты и прав.

Здравствуйте, Gt_, Вы писали:

S>>Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода.
Gt_>у рдбмс как раз не меняется схема таблиц, добавляется новая табличка сборник со ссылками на книги. ничего никуда мигрировать не надо.

А как тогда узнать в какой сборник попадает конкретная книга? Фулскан таблички со сборниками?

Здравствуйте, IncremenTop, Вы писали:

IT>За распределенный монолит надо увольнять из профессии, а тут еще хуже — распределенный монолит с хранимками. Франкенштейн собственной персоной.

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

Здравствуйте, IncremenTop, Вы писали:

IT>Молча подключишь ci/cd к автотестам на свои хранимки?

Можно. Ну или гонять это с in-memory вариантами баз. Смотря что именно тестируем.

IT>Сложность в том, что диалекты SQL уступают любому современному языку на бэке, даже б-мерзкому джаваскрипту.

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

IT>В том, что все трудно тестируемо,

Да нормально там всё тестируется.

IT>еще тяжелее это сопровождать — любой pgAdmin уступает даже старому jdeveloper-у.

У SQL всё нормально с инструментарием.

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

_AB>>В том, что конкретно ты не знаешь sql?
IT>В коде хранимок не он, а его диалект. Причем логика в процедурном стиле.

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

S>>>Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода.
Gt_>>у рдбмс как раз не меняется схема таблиц, добавляется новая табличка сборник со ссылками на книги. ничего никуда мигрировать не надо.

TG>А как тогда узнать в какой сборник попадает конкретная книга? Фулскан таблички со сборниками?

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

Gt_

Gt_>>и ради чего этот анонизм с миграциями ? транзакции тормозят, чуть сложнее запросы — сливает даже mysql, мягко говоря не чемпиону в плане разумности оптимизатора.

IT>Ты точно смотрел ссылку, говоря про тормоза?

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

Здравствуйте, Gt_, Вы писали:

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

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

Здравствуйте, mogadanez, Вы писали:

M>первый хреново гуглится https://i.imgur.com/utvSlI6.png

Один из JetBrains занимается rnd по БД.
Второй работал в питерском альфабанке техлидом или техдиром.


M>"Фреймворки и инструменты PHP для Enterprise" — серьезный уровень, да...

Это не он. Серьезный у тебя уровень анализа — даже на лицо взглянуть не в состоянии.

Здравствуйте, fmiracle, Вы писали:

F>У тебя какая-то зацикленность на хранимках. Масса проектов пишется где все общение с РСУБД главным образом идет через запросы из кода. А хранимок нет вообще или отдельные узкие места, где они дают серьезный эффект по производительности.

Почему-то вангую, что лютая доля проектов с хранимками, причем хранимками всемогуторами.

Здравствуйте, _ABC_, Вы писали:

_AB>С логической точки зрения мало чем отличается от оперативной памяти, но религиозное нарушение есть, конечно.

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

Здравствуйте, _ABC_, Вы писали:

_AB>Э-э-э... Да вообще нет особой разницы с тестами другого кода, вроде как?

Т.е. ты вызываешь хранимки из своего кода?

_AB>В чём разница с автотестированием, допустим, проекта на .Net Core?

В скорости, удобстве, что никакие девопсы не нужны.

_AB>Т.е., заголовок твоей темы не соответствует содержанию твоей головы?

Т.е. в теме не только это обсуждается.

Здравствуйте, mogadanez, Вы писали:


M>он имеет ввиду если именно бизнес-логика в хранимках
M>если ее замокать — часть логики будет непротестирована

Даже необязательно в хранимках, логка может быть инкорпорирована прямо в структуру данных. Скажем, обычный composite unique key это или cascade delete это уже логика. Основные ошибки именно в таких местах и прячутся. Поэтому чтобы сделать тестируемый код, приходится либо не пользоваться никакаими возможностями СУБД кроме самых базовых, либо городить в тестовой системе моков еще одну имплементацию СУБД, либо забить на юнит тесты и сосредоточиться на функциональных тестах.

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Большинство разработчиков просто не умеют работать с другими хранилищами данных кроме СУБД. Для них даже картинки в файлах хранить это уже rocket science. А когда они все же это делают, они настолько боятся ошибиться что принимают очень странные решения в духе "мы вообще никогда ничего не будем удалять, только добавлять новое"

Здравствуйте, Sinclair, Вы писали:

S>В Монге у меня возникает иллюзия, что всё это делать не надо. Просто нужно написать у себя в коде проверку, типа "если у книги есть .author — то хорошо, а если есть includedBooks — то это сборник".
S>В итоге через пять релизов у меня каждый "запрос" — это спагетти из вот таких if-ов, которые вообще непонятны новому разработчику в команде. Типа "нафига тут эта формула, зачем предполагать, что название — это book.Name || book.includedBooks[0].name?

Это, скорее, незнание приемов эффективной организации работы с документными базами данных. Для РСУБД у тебя есть хотя бы нормальные формы и реляционная алгебра, а для документных баз нужно свою голову включать. Причем, со стороны кода у тебя же не возникает проблем со спагетти из if-ов. Скорее всего ты думаешь как-то так: "Ага, у нас есть атомарные объект продаж "книга" и контент. Причем у книги может быть несколько блоков контента, у каждого свое название и автор. И у книги может быть свое, отдельное название и автор-составитель. Вроде ясно, давай рефакторить". Но почему-то ровно та же цепочка рассуждений в случае монги не срабатывает.

Конкретно здесь бы помогло следованием принципам разумной интеграции:
1. Все API за пределы зоны контроля разработчика версионируются, без исключений. Сохранение данных в хранилище это API.
2. Для каждой версии API есть отражение в коде.
3. На вход система обязана принимать любые данные, на выход отдавать только правильные

Таким образом я бы объявил версию v2 API хранилища данных, отрефакторил модель и прописал в коде правила конверсии v1 в v2. Код можно покрывать тестами, включая тесты на инвариант v1->v2->v1. К тому же у меня всегда останется гибкость, оставить в хранилище данные v1 и v2 или запустить миграцию v1 в v2.

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Почему неудобно? Очень удобно. Специализированные time series db ничуть не более удобны, их плюс не в удобстве, а в том что они жрут в хайлоаде меньше ресурсов. Но небольшие проекты это, как правило, и небольшая нагрузка, на которой особой разницы между RDBMS и TSDB по ресурсам нет, а зрелость, развитые средства и богатый функционал первых остается.

у TSDB часто есть функционал, которого нет у RDBMS, например интеграция со всякими коллекторами данных, поддержка графаны и тд, плюс, жрут меньше они не в хайлоаде а в принципе, для нормальной TSDB несколько десятков тысяч вставок в секунду это ничто (0% утилизация цпу), а для реляционной субд это уже хайлоад

Здравствуйте, Miroff, Вы писали:

M>Это, скорее, незнание приемов эффективной организации работы с документными базами данных. Для РСУБД у тебя есть хотя бы нормальные формы и реляционная алгебра, а для документных баз нужно свою голову включать.
В этом-то и риск.
M>Причем, со стороны кода у тебя же не возникает проблем со спагетти из if-ов. Скорее всего ты думаешь как-то так: "Ага, у нас есть атомарные объект продаж "книга" и контент. Причем у книги может быть несколько блоков контента, у каждого свое название и автор. И у книги может быть свое, отдельное название и автор-составитель. Вроде ясно, давай рефакторить". Но почему-то ровно та же цепочка рассуждений в случае монги не срабатывает.
Почему же? Вполне себе срабатывает — мы "прикладной" код так и так рефакторим. А дальше остаётся вопрос: а с данными что делать?

M>Конкретно здесь бы помогло следованием принципам разумной интеграции:
M>1. Все API за пределы зоны контроля разработчика версионируются, без исключений. Сохранение данных в хранилище это API.
M>2. Для каждой версии API есть отражение в коде.
M>3. На вход система обязана принимать любые данные, на выход отдавать только правильные

M>Таким образом я бы объявил версию v2 API хранилища данных, отрефакторил модель и прописал в коде правила конверсии v1 в v2.
Совершенно верно. Я привёл вам пример "правила конверсии" v1 в v2, только очень убогого. Да, кстати, вы всегда добавляете в объекты, хранимые в монге поле "версия схемы документа"?
Если нет — то как вы отличаете v1 от v2?
M>Код можно покрывать тестами, включая тесты на инвариант v1->v2->v1. К тому же у меня всегда останется гибкость, оставить в хранилище данные v1 и v2 или запустить миграцию v1 в v2.
Если вы сели делать миграцию, то вы делаете миграцию. Единственная разница в РСУБД и NoSQL — это в том, что первая бьёт вас по рукам за попытки сделать миграцию неверно. Неопытные разработчики на это обижаются.
Кстати, монга уже умеет многодокументные транзакции? Т.е. могу ли я сделать конверсию v1->v2 "на горячую", с гарантированной целостностью изменений?
Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
Особенно здорово, когда схема меняется не просто как "заменить author на author[]", а как "заменить book[i] на ObjectRef()".

Здравствуйте, Gt_, Вы писали:

Gt_>достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.

А с чего это она выиграет у промышленной рсубд?

Здравствуйте, Sinclair, Вы писали:

S>Почему же? Вполне себе срабатывает — мы "прикладной" код так и так рефакторим. А дальше остаётся вопрос: а с данными что делать?

Так в том и фишка документных БД что данные это и есть код

S>Совершенно верно. Я привёл вам пример "правила конверсии" v1 в v2, только очень убогого. Да, кстати, вы всегда добавляете в объекты, хранимые в монге поле "версия схемы документа"?

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

S>Если вы сели делать миграцию, то вы делаете миграцию. Единственная разница в РСУБД и NoSQL — это в том, что первая бьёт вас по рукам за попытки сделать миграцию неверно. Неопытные разработчики на это обижаются.

Это не миграция, а конверсия. Тут есть существенная разница, миграция подразуменвает что мы меняем данные, а конверсия что мы меняем интерфейсы доступа к данным. И когда мы делаем конверсию, нам помогает вся мощь инструментов разработчика начиная от компилятора и заканчивая автотестами с помощью фаззеров.

S>Кстати, монга уже умеет многодокументные транзакции? Т.е. могу ли я сделать конверсию v1->v2 "на горячую", с гарантированной целостностью изменений?

Чтение-запись документа атомарны и этого достаточно, поскольку не требуется менять всю базу разом.

S>Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
S>Особенно здорово, когда схема меняется не просто как "заменить author на author[]", а как "заменить book[i] на ObjectRef()".

На практике, достаточно быстро появляет политика версионирования. "Поддерживаем последние 2 версии, в течение месяца после релиза в фоновом режиме конвертируем v1 в v2, в следующем релизе выкашиваем v1 из кодовой базы".

Здравствуйте, chaotic-kotik, Вы писали:

CK>у TSDB часто есть функционал, которого нет у RDBMS, например интеграция со всякими коллекторами данных, поддержка графаны и тд, плюс, жрут меньше они не в хайлоаде а в принципе, для нормальной TSDB несколько десятков тысяч вставок в секунду это ничто (0% утилизация цпу), а для реляционной субд это уже хайлоад

при выборе надо оценивать не только скорость вставок, а все имеющиеся use cases.
например мне нужно было не только быстро писать, но и быстрые запросы по записанным данным. на этом TSDB слились.

еще в TSDB трудно менять данные, если сразу не предусмотрел поле в контексте или требования поменялись — то надо достаточно сложный мигрейт делать. в RDBMS чаще всего можно отбиться усложнением запроса, хотя бы на время

Здравствуйте, mogadanez, Вы писали:

M>например мне нужно было не только быстро писать, но и быстрые запросы по записанным данным. на этом TSDB слились.

это какие?

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, mogadanez, Вы писали:

M>>например мне нужно было не только быстро писать, но и быстрые запросы по записанным данным. на этом TSDB слились.

CK>это какие?
да не то что бы особо сложное чтото
чтонить наподобие

  from(bucket: "events")
    |> range(start: -3y)
    |> filter(fn: (r) => r["_measurement"] == "subject_event")
    |> filter(fn: (r) => r["company"] == "2")
    |> filter(fn: (r) => r["event_type"] == "5" or r["event_type"] == "11" )
    |> group(columns: [ "event_type"])
    |> unique(column: "user_subject")
    |> count(column:"_value")

TSDB быстр если ограничивать при запросе временной интервал. те они какбы заточены под UI где есть "временное окно" и там как бы подразумевается что если ты работаешь по данным за долгий период — жди

Здравствуйте, IncremenTop, Вы писали:

IT>С логической точки зрения юнит-тесты должны быть дешевыми, чтобы разработчик их и писал постоянно, и самое главное — запускал.
Какая разница, создать mock-объект, или заполнить фейк-данными таблицу?
Один раз написал скрипт — потом запускаешь себе сколько угодно.

Здравствуйте, IncremenTop, Вы писали:

IT>Т.е. ты вызываешь хранимки из своего кода?
Когда именно?
Если мы говорим про тесты, то у БД проекта есть свои unit-тесты, отдельные от .Net кода.
Погугли sql server unit tests уже...

IT>В скорости, удобстве, что никакие девопсы не нужны.
Э-э-э...
Для настройки CI/CD не нужны девопсы? Ну, тогда нужен кто-то выполняющих их роль и обладающий соответствующими знаниями, всё равно.

И если человек обладает знаниями, как создать CI/CD для .Net Core проекта, он очень быстро разберётся и с юнит тестами для SQL Server, я тебе это гарантирую из собственного опыта, т.к. там разницы вообще практически нет. Нет никакой разницы в скорости, удобстве.

Здравствуйте, Miroff, Вы писали:

M>Но почему-то ровно та же цепочка рассуждений в случае монги не срабатывает.
В такой цепочке рассуждений данные надо будет мигрировать из старой версии в новую. В то время, как ТС утверждает, что не надо. Об этом и речь, собственно.

Здравствуйте, Miroff, Вы писали:
M>Разумеется, в этом суть версионирования и состоит. В РСУБД обычно где-то есть костыльная табличка с номерами версий, а тут версия есть у объектов, а не у хранилища в целом. Думаю, преимущества версионирования объектов перед версионированием всего хранилища подхода достаточно очевидны, чтобы их перечислять.
M>Это не миграция, а конверсия. Тут есть существенная разница, миграция подразуменвает что мы меняем данные, а конверсия что мы меняем интерфейсы доступа к данным. И когда мы делаем конверсию, нам помогает вся мощь инструментов разработчика начиная от компилятора и заканчивая автотестами с помощью фаззеров.
Похоже, мы вышли за пределы моей компетентности.
Можете привести пример кода конверсии с пояснением, как он работает?

M>Чтение-запись документа атомарны и этого достаточно, поскольку не требуется менять всю базу разом.
Ну, для рассматриваемого примера — наверное, достаточно. А что делать в случаях, когда мы превращаем строковый атрибут "автор" в ObjectRef на документ "Автор", мне пока непонятно.
S>>Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
M>На практике, достаточно быстро появляет политика версионирования. "Поддерживаем последние 2 версии, в течение месяца после релиза в фоновом режиме конвертируем v1 в v2, в следующем релизе выкашиваем v1 из кодовой базы".
Подскажите, а откуда вы знаете, что v1 в базе уже нету?

Здравствуйте, gandjustas, Вы писали:

G>ACID это здравый смысл, он нужен всегда.

Нет, в многих нагруженных систем от него ушли в сторону саги. Потому что почти всегда нужна асинхронность на уровне процессов.

G>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.

Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.

G>А чего неудобного в хранении таких данных в БД?

Опустим то, что это надо проектировать, а не из коробки использовать.
Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.

При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее.

G>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.

Прошло почти полсотни лет.

Здравствуйте, elmal, Вы писали:

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

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

Здравствуйте, IncremenTop, Вы писали:

G>>ACID это здравый смысл, он нужен всегда.

IT>Нет, в многих нагруженных систем от него ушли в сторону саги. Потому что почти всегда нужна асинхронность на уровне процессов.

G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.

IT>Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.

Количество табличек для ACID совершенно параллельно, ACID бывает полезен и на одной таблице, если к ней идёт несколько логически связанных запросов, что иногда бывает, т.к. напихать всё в один SQL не всегда получается. Особенно если такое логически связанные запросы к этой таблице могут идти из параллельных потоков или клиентов, т.к. каждый поток создает логическую группу запросов. В этом случае спасает только транзакция, иначе будет race condition.
Я например сейчас пишу шареварную программу с SQLite в качестве локального хранилища, там всего одна табличка, но без ACID в ней появились бы гейнзенбаги, и наверняка уже на стадии прода.

Здравствуйте, IncremenTop, Вы писали:

IT>Спасибо за капитанство, но это не повод лепить микросервисы и одну рбд в один проект.
А где написано что там одна РБД? На деле, ничего не мешает иметь действительно одну реляционку с охрененной нормализацией, с охрененной целостностью. И до черта вспомогательных баз, которые заточены под другие операции, какие то под отчетность, какие то под быструю вставку грязных данных, которые потом отдельными службами вычищаются и очищенные чистые данные переходят в основную хорошо нормализуемую и с хорошей целостностью. Основная база вполне может быть мало нагружена даже в единственном экземпляре, она может использоваться в основном под вставку чистых данных. А запросы могут идти к многочисленным репликам в основном, причем многие будут иной структуры. Причем еще вполне может применяться различное кеширование, соответственно нагрузка на базу вполне может быть достаточно небольшая. Потребность в чистых данных с хорошей целостностью возникает очень и очень часто, и реляционки для обеспечения целостности данных на уровне базы рулят просто неимоверно. А способов избавиться от возможных проблем с производительностью до черта и более.

Здравствуйте, gyraboo, Вы писали:

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

Транзакционность на уровне одной "таблицы" поддерживают многие неРБД.

Здравствуйте, gandjustas, Вы писали:

G>Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу.
G>Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".

Нет. Когда я покупаю товар, то я делаю несколько действий. Т.е. это сага.
Мало того, товар может зарезервироваться на складе, но оплата не прошла и логично не откатить все, а предложить пользователю попробовать еще раз. И это тоже возможно в рамках саги.

G>Асинхронность и ACID не связаны.

Связана.
Если у вас в рамках транзакции 2 и более сервисов, то это распределенная транзакция, которые суть зло по сравнению даже со сложностью саги. И если взаимодействией асинхронное между сервисами, то либо вы еще транзакционность добавляете в шину(а это очень медленно), либо это уже транзакция-сага. Непонятный франкенштейн.
В итоге либо вы шлете к чертям ДДД вместе с кроликами и кафкой, либо вы шлете к чертям 2pc.

G>Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД?

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

G>А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую релеляционную БД.

Так я перечислил эти фичи.

G>>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.

Они это не доказывали, цель была в том чтобы построить максимально полную, непротиворечивую и неизбыточную модель.

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

IT>Нет. Когда я покупаю товар, то я делаю несколько действий. Т.е. это сага.
IT>Мало того, товар может зарезервироваться на складе, но оплата не прошла и логично не откатить все, а предложить пользователю попробовать еще раз. И это тоже возможно в рамках саги.

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

IT>В итоге либо вы шлете к чертям ДДД вместе с кроликами и кафкой, либо вы шлете к чертям 2pc.

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

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

не давал. клоуны с бложиком и комментами не в счет, там бизнес логики нет.

Gt_

Здравствуйте, Gt_, Вы писали:

Gt_>ты втирал "в небольших проектах", применять сагу на небольшом проекте признак проф непригодности. особенно в контексте разговора о производительности.

Мы сейчас в целом о проектах разговариваем, если ты не заметил.

Gt_>не давал. клоуны с бложиком и комментами не в счет, там бизнес логики нет.

Советую следить за речью все же, вас никто не оскорблял.

Здравствуйте, elmal, Вы писали:

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

И зачем?

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

Способов избавиться от проблем с производительностью меньше, потому что не масштабируется горизонтально.

Здравствуйте, gandjustas, Вы писали:

G>Транзакционность (ACID) на уровне одной таблицы поддерживют РСУБД и технически она реализуется также, как и транзакционность на уровне нескольких таблиц.

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

Здравствуйте, gandjustas, Вы писали:

G>Монга не поддерживает ACID на уровне таблицы.

https://www.mongodb.com/blog/post/mongodb-multi-document-acid-transactions-general-availability

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>Монга не поддерживает ACID на уровне таблицы.

IT>https://www.mongodb.com/blog/post/mongodb-multi-document-acid-transactions-general-availability

Хорошо что добавили. Проблема только в том, что такой вид транзакционности не обеспечивает честную изоляцию. Например она не поможет не продать два билета на одно место.

Здравствуйте, elmal, Вы писали:

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