Pull to refresh

Comments 10

Способы реализации представления отличаются, но в типичной ситуации они являются результатом запроса. Это означает, что само представление доступно только для чтения.
вам бы матчасть изучить, а потом уже про базы данных писать:
MySQL 5.6 Reference Manual — 20.5.3 Updatable and Insertable Views
Спасибо конечно, что выделили время на статью. Я представления не использую активно. В данной ситуации доверился автору книги. Но это не отменяет ценность материала. Ваша претензия в таком тоне выглядит больше не на замечание, а на самоутверждение, типа «какой я умный». Только перед кем вы решили это показать непонятно.
Это не нюансы представлений, как вы сейчас пытаетесь преподнести; а базовые знания, опираясь на которые и проектируется структура БД.
Примерно как писать о рефакторинге в ООП, думая что у объектов есть только публичные свойства.
вам бы матчасть изучить, а потом уже про базы данных писать:


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

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


Что такое «робастность»? Опечатка?
Sign up to leave a comment.

Articles