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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_AB>Молча.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--
WBR,
Serge.

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

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

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

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

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

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

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

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

Из личного.

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

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

Ну так вот.

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

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

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

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

И php.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Gt_