Какой лучший способ структурировать эти данные в базе данных?

Question

Мы занимаемся редизайном и консолидацией некоторых таблиц в базе данных. Там, где у нас когда-то было 2 таблицы, 'administrators' и 'users ', теперь мы объединяем в одну таблицу с именем 'users'. Чтобы облегчить это изменение, мы создали таблицу 'user_types' и таблицу 'user_user_types', которая является таблицей связи «один ко многим» между пользователями и 'user_types'.

Причина, по которой мы должны использовать таблицу 'user_types', заключается в том, что существуют разные типы администраторов, один из которых является супер-администратором, который имеет доступ ко всему в нашей системе. В старой настройке в таблице 'administrators' было битовое поле с именем 'SiteAdmin', которое указывало, что данный конкретный администратор является супер-администратором или нет. С тех пор, как я перешел на эту новую систему, я подумал, что в таблице 'user_types' будет тип пользователя, который будет супер-администратором, и мы просто свяжем правильного пользователя с этим типом пользователя в этих случаях, однако, мой коллега-программист говорит здесь он все еще хочет использовать битовое поле 'SiteAdmin' в новой таблице 'users'. Я думаю, что это немного избыточно, но он утверждает, что будет избыточная нагрузка, и на SQL-сервере будет требоваться больше ресурсов процессора для объединения таблиц 'users', 'user_types', чтобы определить, является ли конкретный пользователь супер-администратором. .

Мой вопрос: какой путь лучше? Является ли попадание на сервер SQL настолько великим при объединении двух таблиц, что оправдывает добавление битового поля в таблицу 'users' для пометки супер-администраторов?

Спасибо!

Answer 1

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

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

Answer 2

Мне было бы странно, если бы существенное влияние на производительность оказало соединение с тем, что будет небольшим столом.

Что может быть большей проблемой, так это хранение разных типов пользователей двумя разными способами, что сбивает с толку техническое обслуживание.Я думаю, что ваше решение более простое в долгосрочной перспективе.

Answer 3

Разница в производительности будет зависеть от количества данных в этих таблицах. Если вы говорите о нескольких сотнях или тысячах пользовательских строк, вы не увидите никакой разницы между решениями. Если у вас есть миллионы пользователей и, возможно, большое количество одновременного доступа к данным, вы можете увидеть разницу.