MySQL: как обеспечить безопасность на уровне строк (например, виртуальную частную базу данных Oracle)? - PullRequest
2 голосов
/ 03 апреля 2011

Скажите, что у меня есть продавцы, продающие различные продукты.Итак, на базовом уровне у меня будут следующие таблицы: vendor, product, vendor_product.

Если vendor-1 добавляет Widget 1 к таблице product, я хочу толькоvendor-1, чтобы увидеть эту информацию (потому что эта информация «принадлежит» vendor-1).То же самое относится и к продавцу-2.Скажем, vendor-2 добавляет Widget 2, эту информацию должна видеть только vendor-2.

Если vendor-1 пытается добавить Widget 2, который уже был введен vendor-2, дублирующую запись для Widget 2 не следует вносить в таблицу product.Это означает, что каким-то образом мне нужно знать, что vendor-2 теперь также «владеет» Widget 2.

Проблема с наличием нескольких «владельцев» фрагмента информации заключается в том, как обращаться с владельцами, редактирующими / удаляющимиданные.Возможно, vendor-1 больше не хочет, чтобы Widget 2 был доступен для него / нее, но это не обязательно относится к vendor-2.

Наконец, я хочу пометить (?) Определенные записи как«Да, я проверил эти данные, и они верны», так что они становятся доступными для всех поставщиков.Скажем, я отмечаю Widget 1 как хорошие данные, этот продукт теперь должен видеть каждый поставщик.

Похоже, что решение - это защита на уровне строк.Проблема в том, что я не слишком знаком с его концепциями или с тем, как реализовать их в MySQL.Любая помощь высоко ценится.Спасибо.

ПРИМЕЧАНИЕ: эта проблема несколько обсуждается здесь: Дизайн базы данных: использовать составной ключ в качестве FK, пометить данные для совместного использования? .Когда я задал вопрос, я не был уверен, как правильно сформулировать вопрос.Надеюсь, на этот раз я объяснил свою проблему лучше.

Ответы [ 3 ]

5 голосов
/ 03 апреля 2011

Mysql изначально не поддерживает безопасность на уровне строк в таблицах. Тем не менее, вы можете реализовать это с помощью представлений. Итак, просто создайте представление в вашей таблице, которое отображает только те строки, которые должен видеть данный клиент. Затем предоставьте этому клиенту доступ только к этим представлениям, а не к базовым таблицам.

См. http://www.sqlmaestro.com/resources/all/row_level_security_mysql/

1 голос
/ 03 апреля 2011

Вы уже предложили таблицу сопоставления vendor, product и vendor_product. Вы хотите, чтобы поставщики совместно использовали один и тот же продукт, если они оба хотят его использовать, но вы не хотите дублировать продукты. Правильно?

Если это так, тогда определите уникальный индекс / ограничение для естественного ключа, который идентифицирует продукт (название продукта?).

Если поставщик добавляет продукт, а он не существует, вставьте его в таблицу продуктов и сопоставьте его с этим поставщиком через таблицу vendor_product.

Если продукт уже существует, но сопоставлен с другим поставщиком, не вставляйте ничего в таблицу продукта и добавьте еще одну строку сопоставления, отображающую нового поставщика в существующий продукт (чтобы теперь продукт сопоставлялся двум поставщикам) .

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

Наконец, укажите в таблице продуктов флаг, который говорит о том, что вы просмотрели продукт, а затем используйте что-то подобное для запроса продуктов, доступных для просмотра данному поставщику (мы будем называть идентификатор поставщика 7):

select product.*
from product
left join vendor_map
on vendor_map.product_id = product.product_id
where vendor_map.vendor_id = 7
or product.reviewed = 1;

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

0 голосов
/ 03 апреля 2011

Мне кажется, что вы хотите нормализовать ваши данные. У вас есть отношение 1 (продукт) ко многим (поставщикам). То, что отношение составляет 1: 1 для большинства случаев и только 1: n для некоторых, на самом деле не имеет значения, я бы сказал - в общих чертах это все еще 1: n, и поэтому вы должны проектировать свою базу данных таким образом. Базовая раскладка, вероятно, будет такой:

Vendor Table
VendorId    VendorName    OtherVendorRelatedInformation

WidgetTable
WidgetId    WidgetName    WidgetFlag     CreatorVendor   OtherWidgetInformation

WidgetOwnerships
VendorId    WidgetId      OwnershipStatus     OtherInformation

Обновление : Вопрос о том, кому разрешено делать то, что является бизнес-проблемой, поэтому вам необходимо изложить все правила. В приведенной выше структуре вы можете указать, какой поставщик создал виджет. А в собственности вы можете пометить, каков статус собственности, например

  • CreatorFullOwnership
  • SharedOwnership
  • ...

Вы должны будете создать флаги на основе ваших бизнес-правил, а затем соответствующим образом спроектировать бизнес-логику и часть доступа к данным.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...