Как убедиться, что строки, вставленные в представление SQL, будут элементами этого представления?

Question

Вот сценарий:

У меня есть простая таблица «Инвентаризация».Эта таблица имеет три столбца: один внешний ключ, который ссылается на продукт, один внешний ключ, который ссылается на магазин, и одно числовое значение для цены.В этой таблице не указывается количество доступного продукта, она просто используется для информирования пользователей о том, что магазин продает конкретный продукт.

Эта таблица инвентаризации доступна для публичного просмотра (в этом весь смысл приложения:пользователи должны иметь возможность искать различные товары в различных (потенциально не связанных) магазинах).Магазины должны иметь возможность обновлять свои собственные товарные запасы, не влияя на товарные запасы других магазинов.

Теперь у каждого магазина есть собственная учетная запись и представление.Представления по сути настраиваются следующим образом:

CREATE VIEW MY_INVENTORY AS SELECT I.ProductID, I.StoreID, I.Price FROM Inventory I WHERE I.StoreID = id

Каждый магазин имеет полное разрешение на свой собственный вид инвентаря, так что каждый магазин может добавлять предметы в свой инвентарь, обновлять их и т. Д.

Вот загвоздка: каждый магазин может добавлять элементы в это представление с идентификатором StoreID, который не соответствует их собственному StoreID!Таким образом, они могут добавлять товары в запасы других магазинов (что, безусловно, нет-нет).

Я уже создал интерфейсное приложение для доступа к базе данных, и это достаточно просто программноубедитесь, что ни один магазин не влияет на инвентарь другого магазина, но я хочу более надежную защиту, чем эта.Как мне применить это на уровне базы данных?Триггеры?Ограничения?Я изучил оба варианта и не совсем уверен, как это сделать.

И последнее: только учетная запись корня БД и отдельные хранилища имеют доступ к представлениям отдельных хранилищ.

Answer 1

Я думаю, что вы можете получить то, что хотите, создавая представление с помощью предложения WITH CHECK OPTION. Это не позволит никому использовать представление для вставки информации, которая не соответствует предложению Where, поэтому, если представление магазина для «Where StoreID = 500», оно не может использовать это представление для вставки записей для хранилища 501.

Согласно документации MySQL здесь ,

Предложение WITH CHECK OPTION может быть задано для обновляемого представления, чтобы предотвратить вставки или обновления строк, кроме тех, для которых предложение WHERE в select_statement имеет значение true. Предложение WITH CHECK OPTION было реализовано в MySQL 5.0.2.

В предложении WITH CHECK OPTION для обновляемого представления ключевые слова LOCAL и CASCADED определяют область проверочного тестирования, когда представление определяется в терминах другого представления. Ключевое слово LOCAL ограничивает опцию CHECK только определенным представлением. CASCADED заставляет также проверять проверки для базовых представлений. Если не указано ни одно ключевое слово, по умолчанию используется CASCADED.

Для получения дополнительной информации об обновляемых представлениях и предложении WITH CHECK OPTION см. Раздел 17.4.3, «Обновляемые и вставляемые представления».

Answer 2

Вы не можете применить это на уровне базы данных; вам придется применять это на стороне сервера, возможно, путем проверки на уровне сценариев (PHP, Python и т. д.), что идентификатор хранилища потенциально добавляемой записи соответствует идентификатору хранилища, назначенному пользователю. *