Я создаю базу данных, которая содержит публичные, частные (ограниченные внутренними) и конфиденциальные данные (ограниченные очень немногими).У него есть очень специфические требования, что безопасность данных управляется на стороне базы данных, но я работаю в среде, где у меня нет прямого контроля над разрешениями, и запросы на их изменение будут занимать много времени (2-3дней).
Поэтому я создал структуру, которая должна отвечать нашим потребностям, не требуя большого количества разрешений.Я создал две базы данных на одном сервере, одна из которых внутренняя, таблицы которых могут редактировать только определенные пользователи в определенных подсетях нашей сети.Второй - общедоступная база данных, в которой, используя учетную запись администратора, я создаю представления, ограниченные общедоступными полями таблиц во внутренней базе данных, для предоставления общедоступных данных, и это, кажется, работает хорошо.Однако данные должны передаваться только в одном направлении, и представления не должны иметь возможность записи в исходные таблицы.И я не могу просто заблокировать общедоступную базу данных, чтобы она была только SELECTable, поскольку общедоступная база данных используется для различных задач нашего общедоступного веб-сайта.
Поэтому мне нужно создать представления, чтобы ограничить доступ некоторых сценариев к определенным полям вТаблица.Мне нужно убедиться, что эти представления не могут вставлять, обновлять или удалять данные в исходной таблице.Для создания представления я использую:
CREATE ALGORITHM = UNDEFINED
VIEW `table_view` AS
SELECT *
FROM `table`
При просмотре документации для предотвращения обновлений у представления должны быть агрегированные данные, подзапросы в предложении WHERE и ALGORITHM = TEMPTABLE.Я бы пошел с TEMPTABLE, но в руководстве неясно, повлияет ли это на производительность.В одном абзаце руководство гласит:
Предпочитает MERGE, а не TEMPTABLE, если это возможно, потому что MERGE обычно более эффективен
Тогда сразу говорится:
Причина явного выбора TEMPTABLE заключается в том, что блокировки могут быть сняты на базовых таблицах после создания временной таблицы и до ее использования для завершения обработки оператора.Это может привести к более быстрому снятию блокировки, чем алгоритм MERGE, так что другие клиенты, использующие представление, не будут заблокированы так долго.
Представления будут запрашиваться при загрузке страницы для генерации содержимогоПейдж, MERGE все еще будет more efficient, или более низкое время блокировки будет мне лучше?И нет, обработка этого через разрешения учетной записи на самом деле не вариант из-за неспособности предоставить разрешения GRANT для отдельных полей, чтобы соответствовать требованиям юридической конфиденциальности.Чтобы удовлетворить их, потребуется разбить каждую таблицу на 2-3 таблицы, содержащие поля с однородной конфиденциальностью.
Должен ли алгоритм быть UNDEFINED или TEMPTABLE, или в определении представления есть другая настройка, которая блокирует представление.И какие эффекты производительности я буду испытывать.Кроме того, если я сделаю что-то, чтобы заставить его быть недоступным для редактирования, например, включив HAVING 1, чтобы сделать его агрегатной функцией, заставим его быть ХРАМИМЫМ и выбрал спорный алгоритм.