У нас есть система, которая имеет сложные пользовательские права, которые определяют, какие контакты пользователь может видеть в приложении, и я ищу лучший способ структурирования таблиц, чтобы мы могли масштабировать.Разрешения слишком сложны, чтобы работать на лету, поэтому их необходимо записать в таблицу, которая затем будет обновляться при выполнении функций администратора или при добавлении / редактировании / удалении контакта.
В таблице контактов 10миллион записей в нем.Моей первой мыслью было создание таблицы contactUserLink, в которой были бы contactUserLinkID, contactID, userID с кластеризованным индексом для contactUserLinkID и некластеризованный индекс для contactiD и userID для быстрого поиска.
Моя проблема в этом заключается в следующем:
Если у нас было 200 пользователей, и у них у всех был разный доступ к большим частям данных, то contactUserLink мог бы выдвигаться к сотням миллионов строк.
Там будет много добавления / редактирования / удаления, происходящих в этой таблице, поскольку контакты были отредактированы и администратор изменил правила.
Изменения администратора могут привести к огромному количеству удаления / вставки, поскольку пользовательские разрешения перерабатываются, что, если они занимают много времени, может оставить пользователей без доступа.
Если новый пользователь добавлен и у него есть доступ ко всем записям, запись 10 миллионов записей в эту таблицу вряд ли будет быстрой?
Мы используемSQL 2008.
Надеюсь, мне удалось объяснить это, чтобы это имело некоторый смысл.
Любая помощь по этому вопросу будет принята с благодарностью.