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

Question

Я создаю веб-страницу, где пользователи смогут создавать учетные записи, и у каждой учетной записи будет свой собственный поддомен.Таким образом, могут быть URL-адреса, подобные этим:

www.user1.domain.com
www.user2.domain.com
...

У них тоже будут свои страницы, например:

www.user1.domain.com/url-1/
www.user1.domain.com/url-2/
www.user2.domain.com/url-3/
...

Поэтому мне нужно хранить account_url и page_url в базе данных.

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

Вот так выглядят мои таблицы:

ПОЛЬЗОВАТЕЛИ:

user_id     PK
user_name
user_pass
...

СЧЕТА:

account_id  PK
user_id     FK
account_url
account_name
account_type
...

СТРАНИЦЫ:

page_id     PK
user_id     FK
page_url    
page_name
page_content
...

Теперь проблема заключается в следующем, так как я получаю URL, как это:

www.user1.domain.com/page-url/

Единственная информация, которую яможет извлечь из URL-адреса account_url и page_url, поскольку в URL-адресе диспетчер / маршрутизатор получает эти две переменные.account_url - это поддомен, а page_url - это сегмент за доменом.

Поскольку будет несколько пользователей, мне всегда нужно получать этот user_id, чтобы я мог обновлять / удалять строки, принадлежащие им.Поэтому мне нужно обновить page_content, где user_id принадлежит этому пользователю, а page_url - это URL-адрес.

Но у меня нет user_id.И когда я хочу обновить page_url_content, сначала мне нужно найти user_id, например:

SELECT user_id FROM accounts WHERE account_url = something 

А потом, когда у меня есть user_id, я могу обновить содержимое страницы или выполнить любое другое действие.

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

Теперь я мог бы использовать account_url для Primary Key, ивсе таблицы относятся к этому первичному ключу.Поэтому, когда я получаю URL-адрес, я уже знаю первичный ключ, поскольку он указан в URL-адресе.

Это хороший случай, чтобы использовать первичный ключ в URL-адресе, или я что-то делаю не так?

Answer 1

Я предпочитаю всегда иметь мои первичные ключи ID как целые числа для объединений.Тем не менее, существует множество способов сделать ваш сайт быстрым.

• Вы можете проиндексировать столбец account_url, чтобы поиск был более эффективным.
• Или вы можете сохранить идентификатор пользователя и использовать это значение вместо того, чтобы каждый раз запрашивать базу данных.Разумеется, вы захотите отследить сеанс, чтобы кто-то не мог подделать кого-то другого.
• Предполагается, что пользователь будет контролировать имя субдомена, поэтому встраивание идентификатора пользователя в имя субдомена, вероятно, будет неэффективным, иначе это также вариант.
• Вы можете хранить ID пользователя и user account_url в отдельной таблице и кэшировать эту таблицу, чтобы вы не обращались к базе данных при подавляющем большинстве поисков.

Моя рекомендация будетсохранить первичный ключ целым числом, индексировать account_url и определить целевое время загрузки страницы;скажем, завершение всего доступа к базе данных и рендеринга страницы менее чем за 1500 секунд.Когда ваш сайт начинает отвечать за ваш порог, вы можете проанализировать свой сайт, чтобы увидеть, где лежат реальные проблемы, и затем устранить их.

Answer 2

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

В этом случаеесли у вас есть отношение m-1 между доменом и учетной записью пользователя, вы можете эффективно рассматривать домен как идентификатор пользователя;Вы просто должны правильно соединить вещи.(и под m-1 я имею в виду, что один домен может «принадлежать» только одному пользователю).

Ключевым моментом является то, что вам не нужно для получения user_id, потому что вы можете получить его, присоединившись к таблице ACCOUNTS по мере необходимости, поскольку она связывает домен с user_id.

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

Answer 3

У вас есть два совершенно разных вопроса. Сопоставление поддоменов и страниц с пользователем является простым из двух. Более сложный вопрос - «Государство». Вам необходимо создать базу данных состояний (или аналогичный модуль), чтобы отслеживать, какие пользователи в данный момент вошли в систему и вошли ли они в систему при получении обновления.

JZ коснулся этого в своем комментарии. Не путайте эти два вопроса, они раздельные и должны рассматриваться как таковые.