Рекомендации по индексации таблиц для проекта SaaS

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

CREATE TABLE [dbo].[TenantID](
    [TenantID] [smallint] IDENTITY(1,1) NOT NULL,
    [TenantName] [varchar](128) NOT NULL
) 
CREATE TABLE [dbo].[MenuType](
    [MenuTypeID] [int] IDENTITY(1,1) NOT NULL,
    [TenantID] [smallint] NOT NULL,
    [MenuTypeName] [varchar](128) NOT NULL
)
  • MenuTypeName должно быть уникальным для каждого клиента. Таким образом, у меня будет Уникальный указатель для TenantID и MenuTypeName.
  • На TenantID следует ссылаться на таблицу Tenant. Итак, Внешний ключ на TenantID.
  • Я все еще думаю, нужен ли мне первичный ключ или просто кластерный индекс для MenuTypeID, который является столбцом с автоматическим приращением.
  • В будущем, когда размер таблицы вырастет, я смогу легко разделить данные на основе TenantID на новый сервер базы данных.

Вопросы:

  1. Мне действительно нужно определять первичный ключ для MenuTypeID, потому что мы знаем, что SQL Server гарантирует добавочные начальные значения. Могу я просто определить кластерный индекс по MenuTypeID.
  2. Определите уникальный ключ для TenantID и MenuTypeName.

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


sql-server database-design indexing saas primary-key-design
person Yamsuh    schedule 01.08.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Хотя SQL Server должен назначать инкрементные значения IDENTITY, дублирование может быть введено с помощью IDENTITY_INSERT ON. Рассмотрим ограничение составного первичного ключа для TenantID и MenuTypeID, чтобы гарантировать уникальность первичного ключа и ограничение уникальности для TenantID и MenuTypeName < / em>, чтобы обеспечить уникальность MenuTypeName для каждого клиента. Уникальный индекс / ограничение только для MenuTypeID здесь не имеет значения, если предполагается, что он никогда не используется без TenantID.

Укажите CLUSTERED для одного из индексов ограничения. Лучший выбор кластеризованного индекса зависит от ваших наиболее частых запросов. В случае сомнений обычно лучше сделать индекс первичного ключа кластеризованным.

person Dan Guzman    schedule 01.08.2015