Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, IncremenTop, Вы писали:
IT>>Как ты будешь писать юнит-тесты? V>По части тестов реляционная база нием не отличается от не реляционной. V>Точно так же моками.
он имеет ввиду если именно бизнес-логика в хранимках
если ее замокать — часть логики будет непротестирована
Re[10]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, Gt_, Вы писали:
Gt_>а теперь понадобилось добавить новую сущность — сборник книг, в noSQL это изменение в схеме "книга" + анал с миграцией данных в новую схему. при этом у большинства noSQL вторичных индексов нет, т.е. поиск по сборнику — полный перебор всех документов.
1. Как бы можно было придумать хотя бы библиотеку. Что за чудо-юдо сборник книг — непонятно, как и непонятно, зачем менять схему. Ну и как вы должны понимать, то анала с миграцией данных в РБД еще больше. По сравнению с монгой — просто небо и земля.
2. Что за большинство? Выборка по той же монге будет быстрее, также как и вставка. Главное, чтобы индекс в память умещался.
Re[11]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>2. Что за большинство? Выборка по той же монге будет быстрее, также как и вставка. Главное, чтобы индекс в память умещался.
Итак. По монге-то не столь много написано, а вот очень хороший материал про DynamoDB
Здравствуйте, IncremenTop, Вы писали:
_AB>>Молча. IT>Молча подключишь ci/cd к автотестам на свои хранимки?
В чем проблема и откуда вдруг взялись хранимки?
IT>Ага, я понимаю, что для комсомольцев нет невыполнимых задач.
Переход на личности демонстрирует слабость твоей аргументации.
_AB>>Э-э-э... А в чём принципиальная сложность? IT>Сложность в том, что диалекты SQL уступают любому современному языку на бэке, даже б-мерзкому джаваскрипту.
Уступают в чем? В выборке и манипуляции с реляционными данными? Ты уверен?
_AB>>Так зачем там микросервисы? Что там вообще надо масштабировать в небольших проектах, да еще частями? IT>Я утверждал, что они там нужны? IT>У ренессанса далеко не мелкая система.
У тебя в сабже что написано?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, 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>Это точно о хранимках?
Это о работе с данными при помощи РСУБД.
Хранимки можно не использовать при желании.
Re[7]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>1. Я не против хранимок в принципе, но это должно быть под строгим контролем.
Как и код в принципе.
IT>Неоднократно наблюдал, как разработчики пытались решить все проблемы одной хранимкой.
А монструозных методов и функций, пытающихся решить все проблемы одним вызовом, ты не наблюдал разве?
Дяденька, а Вы настоящий сварщик?
Да, SQL в плане декомпозиции заметно похуже популярных языков программирования общего назначения, но это не значит, что можно позволять всё пихать в одну хранимку без всякой на то необходимости.
IT>2. И я не против РБД. Мне непонятно, зачем их применять там, где они избыточны/не подходят.
Мне тоже.
Там, где достаточно файла/файлов для хранения, разумеется не место РСУБД, это явно избыточно.
Но "избыточны" и в качестве альтернативы "неизбыточного" для небольших проектов предлагать noSQL? Это серьёзно сейчас было?
Я понимаю, есть сценарии, где noSQL того или иного рода будет лучше альтернатив. Но это не про избыточность или неизбыточность, ИМХО, и не про размер проектов.
Re[3]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, 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. Что за большинство? Выборка по той же монге будет быстрее, также как и вставка. Главное, чтобы индекс в память умещался.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, _ABC_, Вы писали:
IT>>Молча подключишь ci/cd к автотестам на свои хранимки? _AB>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил.
Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"
Re[7]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, mogadanez, Вы писали:
IT>>>Как ты будешь писать юнит-тесты? V>>По части тестов реляционная база нием не отличается от не реляционной. V>>Точно так же моками.
M>он имеет ввиду если именно бизнес-логика в хранимках M>если ее замокать — часть логики будет непротестирована
Смотря что тестируем. Если ту логику, что в прцедурах, то мокать её, конечно, не нужно.
Re[9]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, _ABC_, Вы писали:
IT>>>Молча подключишь ci/cd к автотестам на свои хранимки? _AB>>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил. V>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"
строго говоря в setup/teardown можно убивать все и создавать новое.
Re[10]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, mogadanez, Вы писали:
IT>>>>Молча подключишь ci/cd к автотестам на свои хранимки? _AB>>>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил. V>>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"
M>строго говоря в setup/teardown можно убивать все и создавать новое.
Да тут есть разные варианты. Например, можно всё в транзакции делать а в конце откатывать...
Но фанаты — такие фанаты... Не один раз уже с такими дискутировал.
Re[11]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, vmpire, Вы писали:
IT>>>Молча подключишь ci/cd к автотестам на свои хранимки? _AB>>Э-э-э... Угу. MS SQL Server + SSDT + SQL Server Unit Tests + Azure Devops. Делал самолично, проблем особых не обнаружил. V>Сейчас налетят фанаты TDD с убийственным аргументом "это не юнит-тесты, так как они изменяют базу"
Ну и что? Про юнит-тесты речи же и не было. Там было "автотесты".
Re[12]: Зачем реляционные БД...в небольших проектах?
S>Нет, не больше. В РБД я поменяю схему, и буду вынужден 1 (один) раз подумать над тем, как трансформировать существующие данные в новую схему. Накат миграционных скриптов можно протестировать, отпрофилировать, и сделать частью инсталлятора новой версии кода.
у рдбмс как раз не меняется схема таблиц, добавляется новая табличка сборник со ссылками на книги. ничего никуда мигрировать не надо.
Gt_
Re[10]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, Sinclair, Вы писали:
S>Ну, например, для того, чтобы отразить этот факт: книга, вроде бы, одна (кусок отдельно не купишь), но авторов и названий в ней — три.
Ок, предыдущая сущность по сути авторское произведение, а это будет другая — книга.
Связь между документами через ID, никаких вложенных. Изменение схемы минимально.
S>В Монге у меня возникает иллюзия, что всё это делать не надо. Просто нужно написать у себя в коде проверку, типа "если у книги есть .author — то хорошо, а если есть includedBooks — то это сборник". S>В итоге через пять релизов у меня каждый "запрос" — это спагетти из вот таких if-ов,
Если ты не используешь миграции монги и валидаторы схемы, которые есть, а вместо этого предпочитаешь писать кучу if-в, так это ССЗБ.
S>
