ArkadiyXIII 25 мар 2021 в 09:00

Разложение монолита: Декомпозиция БД (часть 1)

11 мин

7.9K

Программирование*Анализ и проектирование систем*Проектирование и рефакторинг*Микросервисы*

Комментарии 10

Busla 25 мар 2021 в 11:45

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

вам бы матчасть изучить, а потом уже про базы данных писать:
MySQL 5.6 Reference Manual — 20.5.3 Updatable and Insertable Views

ArkadiyXIII 25 мар 2021 в 12:38

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

Busla 25 мар 2021 в 14:26

Это не нюансы представлений, как вы сейчас пытаетесь преподнести; а базовые знания, опираясь на которые и проектируется структура БД.
Примерно как писать о рефакторинге в ООП, думая что у объектов есть только публичные свойства.

S-type 25 мар 2021 в 22:16

вам бы матчасть изучить, а потом уже про базы данных писать:

А в чём претензия? Вы дали ссылку на то, что не любая вьюшка может использоваться «для записи». Конечно, вьюшка типа «select * from одна_таблица» — да, может использоваться как для чтения, так и для записи. Но, чем сложнее код вьюшки, тем меньше шансов, что данные можно будет сохранить.

Busla 26 мар 2021 в 15:19

Вот не надо демагогией заниматься — и не во все таблицы получится произвольную ахинею записать. Это же не говорит, что в таблицы вообще писать не стоит.
Ограничения на запись для вьюх простые и интуитивно-понятные.

Ну и с такими убеждениями потом «пользователям» дают вьюхи, предполагая, что обеспечили таким образом real only доступ.

S-type 26 мар 2021 в 15:44

Какой то вы прям — агрессивный… На счёт «интуитивно-понятные» — не согласен. В принципе, все ограничения можно убрать. Вопрос только в цене — сколько это потребует усилий от авторов СУБД. Чем сложнее вьюшка, тем меньше вероятность, что вы сможете сделать её «на запись» — это факт. Потому, чем больше будут разниться первоначальная схема данных от текущей, тем больше вероятность, что вы столкнётесь с вариантом, что не получится сделать вьюху «на запись». IMHO, потому, для данной задачи перевода приложения на микросервисы лучше сразу считать вьюхи read-only.

Busla 27 мар 2021 в 12:33

Вот именно: такие считатели думают, что сейчас наведут порядок: дадут legacy-читателям типа как бы real only вьюхи. А потом оказывается, что читатели ещё и иногда писатели, а вьюхи вовсе не read only.