Здравствуйте, _ABC_, Вы писали:
_AB>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил. _AB>Инструменты есть.
Я в курсе аналогичного стека для постгре, думаю, что вполне есть аналогичные мучения и для других, но это все монструозно и уныло. Все это трудноподдерживаемо в принципе(если, кстати, нет подписки azure, то, видимо, собственный костыль).
_AB>В чём конкретно? В работе с данными не уступают.
Бизнес-логика — это тоже по сути работа с данными.
_AB>Ты тему своего топика видел вообще?
Видел. Это была затравка к архитекторам из ада.
Re[8]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, _ABC_, Вы писали:
_AB>А монструозных методов и функций, пытающихся решить все проблемы одним вызовом, ты не наблюдал разве?
Это отсекается на код-ревью, да и в принципе сейчас даже студия экспресс поддерживает парное кодирование.
Чтобы аналогичное сделать для кода на sql — уже надо извращаться.
Re[13]: Зачем реляционные БД...в небольших проектах?
IT>Если ты не используешь миграции монги и валидаторы схемы, которые есть, а вместо этого предпочитаешь писать кучу if-в, так это ССЗБ.
и ради чего этот анонизм с миграциями ? транзакции тормозят, чуть сложнее запросы — сливает даже mysql, мягко говоря не чемпиону в плане разумности оптимизатора.
достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.
Gt_
Re[9]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, vmpire, Вы писали:
V>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"
Ну да, ты прав.
Изменяют базу, которая создается с нуля специально под раунд тестирования.
С логической точки зрения мало чем отличается от оперативной памяти, но религиозное нарушение есть, конечно.
Re[9]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Я в курсе аналогичного стека для постгре, думаю, что вполне есть аналогичные мучения и для других, но это все монструозно и уныло.
Э-э-э... Да вообще нет особой разницы с тестами другого кода, вроде как?
IT>Все это трудноподдерживаемо в принципе
В чём разница с автотестированием, допустим, проекта на .Net Core?
IT>(если, кстати, нет подписки azure, то, видимо, собственный костыль)
Я работаю со своим стеком, поэтому не особо смотрю, что там по сторонам.
Но, насколько помню, SSDT бесплатны, сам фреймворк юнит тестов идёт вместе с ним. Насколько помню, реализация идёт через стандартный mstest.
А уж как к конкретной реализации пайплайна привязать вызов mstest.exe — это пусть девопсы по месту решают.
IT>Бизнес-логика — это тоже по сути работа с данными.
А еще всё вместе по сути работа с ноликами и единичками.
IT>Видел. Это была затравка к архитекторам из ада.
Т.е., заголовок твоей темы не соответствует содержанию твоей головы?
Ты бы так сразу и сказал, что хочешь обсудить кашу в своей голове, я бы время не тратил.
Re[9]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Это отсекается на код-ревью, да и в принципе сейчас даже студия экспресс поддерживает парное кодирование.
И что мешает делать код-ревью для SQL?
IT>Чтобы аналогичное сделать для кода на sql — уже надо извращаться.
Почему? Работа идет в той же самой студии, в том же самом гите, можно создавать точно так же пул реквесты, запросы на код ревью и т.д. В чём разница-то?
Re[14]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, Gt_, Вы писали:
Gt_>и ради чего этот анонизм с миграциями ? транзакции тормозят, чуть сложнее запросы — сливает даже mysql, мягко говоря не чемпиону в плане разумности оптимизатора.
Ты точно смотрел ссылку, говоря про тормоза?
Gt_>достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.
Миллионы мух не могут ошибаться, да.
Хотя я не писал хранимки в монге, так что может быть с точки зрения ХП ты и прав.
Re[13]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, Gt_, Вы писали:
S>>Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода. Gt_>у рдбмс как раз не меняется схема таблиц, добавляется новая табличка сборник со ссылками на книги. ничего никуда мигрировать не надо.
А как тогда узнать в какой сборник попадает конкретная книга? Фулскан таблички со сборниками?
Re[3]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>За распределенный монолит надо увольнять из профессии, а тут еще хуже — распределенный монолит с хранимками. Франкенштейн собственной персоной.
Та картинка у меня не загрузилась, так что могу лишь предположить, что речь про набор микросервисов, обращающихся к одной и той же базе данных.
Такое получается вполне естественным образом как промежуточный этап на пути перехода от монолита к микросервисам. Т.е. может вы просто поймали это на том этапе, когда API уже разнесли по разным сервисам, но доступ к данным у разных сервисов пока ещё частично пересекается.
С уважением, Artem Korneev.
Re[7]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Молча подключишь ci/cd к автотестам на свои хранимки?
Можно. Ну или гонять это с in-memory вариантами баз. Смотря что именно тестируем.
IT>Сложность в том, что диалекты SQL уступают любому современному языку на бэке, даже б-мерзкому джаваскрипту.
На практике никогда не видел чтоб это было проблемой. Все эти переезды с одного движка SQL на другой обычно чисто теоретические, чаще бывает, что какую базу выбрали в самом начале проекта, на той базе проект и живёт всю оставшуюся жизнь.
В тех редких случаях, когда переезд всё-таки случается, код работы с базой можно просмотреть и переписать. Да, это занимает какое-то время, но это сравнительно простая задача. И да, это должны делать люди, хорошо разбирающиеся в SQL'е, даже если там и нет хранимых процедур. Обычно куда больше трудностей с продумыванием самого процесса миграции, чем с диалектами SQL'я.
IT>В том, что все трудно тестируемо,
Да нормально там всё тестируется.
IT>еще тяжелее это сопровождать — любой pgAdmin уступает даже старому jdeveloper-у.
У SQL всё нормально с инструментарием.
Если человек не знает SQL, то ему это сложно сопровождать, да. И да, это отдельный навык и его тоже стоит принимать во внимание при выборе используемых технологий.
В целом, хранимые процедуры я б без реальной необходимости не тащил бы в проект. Но вот разбираться в каких-то базовых фичах SQL придётся — индексы, триггеры, внешние ключи и т.п.
_AB>>В том, что конкретно ты не знаешь sql? IT>В коде хранимок не он, а его диалект. Причем логика в процедурном стиле.
Это всегда диалект. И это не проблема само по себе.
Но, повторюсь, без большой необходимости я б хранимые процедуры в проект не тащил бы.
С уважением, Artem Korneev.
Re[14]: Зачем реляционные БД...в небольших проектах?
S>>>Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода. Gt_>>у рдбмс как раз не меняется схема таблиц, добавляется новая табличка сборник со ссылками на книги. ничего никуда мигрировать не надо.
TG>А как тогда узнать в какой сборник попадает конкретная книга? Фулскан таблички со сборниками?
джоин книг на cборник. пока данных мало будет фулскан, когда данных станет больше — джоин по FK индексу пойдет. в этом основное преимущество рдбмс — у нее есть полноценный оптимизатор и доступ к данным меняется с ростом данным.
Здравствуйте, IncremenTop, Вы писали:
IT>Хотя я не писал хранимки в монге, так что может быть с точки зрения ХП ты и прав.
У тебя какая-то зацикленность на хранимках. Масса проектов пишется где все общение с РСУБД главным образом идет через запросы из кода. А хранимок нет вообще или отдельные узкие места, где они дают серьезный эффект по производительности.
Re[15]: Зачем реляционные БД...в небольших проектах?
Gt_>>и ради чего этот анонизм с миграциями ? транзакции тормозят, чуть сложнее запросы — сливает даже mysql, мягко говоря не чемпиону в плане разумности оптимизатора.
IT>Ты точно смотрел ссылку, говоря про тормоза?
открыл но я не воспринимаю технический текст на русском, как я понял там два тормоза не видевших ничего сложнее блога.
попробуй реализовать бизнес логику сложнее лайков в вебе и поймешь почему монги нет в ентерпрайзе.
Re[16]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, Gt_, Вы писали:
Gt_>открыл но я не воспринимаю технический текст на русском, как я понял там два тормоза не видевших ничего сложнее блога.
А я плохо воспринимаю балобольство без аргументов от человека, который не смог даже загуглить, кем являются докладчики.
Re[17]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>А я плохо воспринимаю балобольство без аргументов от человека, который не смог даже загуглить, кем являются докладчики.
Gt_>>открыл но я не воспринимаю технический текст на русском, как я понял там два тормоза не видевших ничего сложнее блога.
IT>А я плохо воспринимаю балобольство без аргументов от человека, который не смог даже загуглить, кем являются докладчики.
Здравствуйте, fmiracle, Вы писали:
F>У тебя какая-то зацикленность на хранимках. Масса проектов пишется где все общение с РСУБД главным образом идет через запросы из кода. А хранимок нет вообще или отдельные узкие места, где они дают серьезный эффект по производительности.
Почему-то вангую, что лютая доля проектов с хранимками, причем хранимками всемогуторами.
