MT
Например гипотетический набор из SQL запроса с прилепленными к нему DDL-ками таблиц, которые он использует. Чем это плохо (я уверен что плохо) на языке архитектуры, а не интуиции?
Size: a a a
2020 November 23
ЕР
Ну DDL это же синтаксис для описания модели данных, она описывается один раз, а далее можно делать выборки многократные по этой модели
ЕР
Расположением всего добра в памяти/на диске занимается уже СУБД, алгоритм выборки данных по полученным в декларативном формате критериям продумывает SQL-оптимизатор потому что у него это получается лучше или быстрее чем у погромистов
ЕР
Вообще, есть документо-ориентированные БД которые могут работать и без заранее определённой схемы
MT
Ну DDL это же синтаксис для описания модели данных, она описывается один раз, а далее можно делать выборки многократные по этой модели
В точку! Как раз речь о ситуации когда эти DDL-ки имеют право дрейфовать и эволюционировать, существуюя чуть ли не своя каждый запрос. Что-то вроде хранимых представлений, путешествующих в одной сцепке с использующим их кодом запроса.
ЕР
В точку! Как раз речь о ситуации когда эти DDL-ки имеют право дрейфовать и эволюционировать, существуюя чуть ли не своя каждый запрос. Что-то вроде хранимых представлений, путешествующих в одной сцепке с использующим их кодом запроса.
Ну, структуру БД не перестраивают под каждый запрос. Это долго и дорого
ЕР
И не нужно, т.к. обычно запросы всё-таки подстраивают под структуру
MT
Ну, структуру БД не перестраивают под каждый запрос. Это долго и дорого
Да, это хороший аргумент именно как архитектора баз данных. А я чувствую в этом подхоже еще и нарушение какого-то архитектурного принципа (необходимость слабой связи, "смешение слоев", типа не должен запрос что-то знать про детали воссоздания своего окружения, так как это не его слой)
ЕР
Да, это хороший аргумент именно как архитектора баз данных. А я чувствую в этом подхоже еще и нарушение какого-то архитектурного принципа (необходимость слабой связи, "смешение слоев", типа не должен запрос что-то знать про детали воссоздания своего окружения, так как это не его слой)
Ну да, чем меньше деталей можно учитывать в запросе, тем проще)
MT
Но какого именно принципа - пока не сформулировал
MT
Вот-вот. Уменьшение вероятности ошибки Независимость компонент.
ЕР
Ну можно считать что DRY, т.к. инфа получается будет дублироваться в запросах
Та и SRP туда же
Та и SRP туда же
MT
Поразительно то, что как раз такая гипотетическая пара (запрос+метаданные для всех таблиц запроса) будет более устойчива к попыткам запустить ее на базе с другой структурой метаданных
MT
Чем просто запрос
MT
Ну можно считать что DRY, т.к. инфа получается будет дублироваться в запросах
Та и SRP туда же
Та и SRP туда же
Согласен. Если схема базы данных устаканена, то дублироваться. А вот если сама система существует для того, чтобы устаканить такую схему, нащупывая ее форму под каждый запрос (создавая копию таблиц и хранимых представлений), то получается что вроде бы хранение метаинфы и инфы это даже хорошо и не нарушает никаких архитектурных догм, я правильно понимаю?
ЕР
Согласен. Если схема базы данных устаканена, то дублироваться. А вот если сама система существует для того, чтобы устаканить такую схему, нащупывая ее форму под каждый запрос (создавая копию таблиц и хранимых представлений), то получается что вроде бы хранение метаинфы и инфы это даже хорошо и не нарушает никаких архитектурных догм, я правильно понимаю?
Если схема задаётся клиентом то она уже устаканена
ЕР
А если не устаканена и это бд с динамической схемой, то этой схемой занимается уже база а не клиенты
MT
О, круть, большое спасибо! Кажется в этом и разгадка.
АГ
json-поля, таблицы в памяти. зачем что-то извращенское придумывать?
АГ
временные таблицы