sql ID пользователя + имя + профиль оптимизировать вопрос

Question

Скорее всего, мне нужно будет много раз использовать userid-> username. Так что я думал, вместо того, чтобы иметь стол, как показано ниже

userid int PK
username text
userpass_salthash int
user_someopt1 int
user_sig text

чтобы разбить его, как показано ниже

//table1
userid int PK
username text

//table2
userid int //fk
userpass_salthash int
user_someopt1 int
user_sig text

рассуждая, я бы сделал это потому, что я подозреваю, что менее сложная таблица (я могу также делать имена не длиннее 32 байт, если мне нравится) быстрее для поиска вместе с меньшим количеством данных в качестве бонуса Но я знаю, что могу ошибаться, какую версию мне следует делать и какие причины, кроме оптимизации?

Answer 1

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

Производительность:

• Если вы поместите индекс на (UserId, Username), у вас будет индекс покрытия - так что вам никогда не понадобится переходить к таблице, чтобы получить имя пользователя.
• Если вы поместите свой кластеризованный индекс на UserId, вы получите поиск кластеризованного индекса - который в любом случае закончится данными строки.

Нормализация:

• Ваш второй вариант позволяет пользователю существовать в таблице1, но не в таблице2. Поскольку вы, вероятно, не хотите, чтобы пользователь без пароля (который не может войти), я бы посчитал это неправильным.

Мое предложение будет кластеризованным индексом UserId. Если вам нужен кластеризованный индекс где-то еще, индекс покрытия будет почти таким же хорошим.

Answer 2

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

1. Первое правило Клуба оптимизации - вы не оптимизируете.
2. Второе правило Клуба оптимизации - вы не оптимизируете без измерения.
3. Если ваше приложение работает быстрее, чем базовый транспортный протокол, оптимизация завершена.
4. Один фактор за раз.
5. Нет маркетроидов, нет расписаний маркетроидов.
6. Тестирование будет продолжаться столько, сколько потребуется.
7. Если это ваша первая ночь в Клубе оптимизации, вы должны написать контрольный пример.

Answer 3

Я согласен, что для такого узкого стола лучшая ставка почти наверняка - один стол.

Еще одна вещь, которую нужно добавить - текстовый тип данных (если вы используете MS SQL Server) очень широк. nvarchar (200) должен быть более чем достаточно широким. Используйте данные больших объектов по своему усмотрению.