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

[@Busla]

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

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

[@ArkadiyXIII]

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

[@Busla]

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

[@S-type]

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

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

[@Busla]

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

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

[@S-type]

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

[@Busla]

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

[@S-type]

повышает робастность системы

Что такое «робастность»? Опечатка?

[@ArkadiyXIII]

ru.wikipedia.org/wiki/%D0%A0%D0%BE%D0%B1%D0%B0%D1%81%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C

[@S-type]

Спасибо, буду знать.