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