Как спроектировать структуру таблиц для поиска табличных данных быстрее в SQL

Question

Структура основной таблицы

 CREATE TABLE [dbo].[Timetable] (
    [location]                   NVARCHAR (128) NOT NULL,   
    [term]                       NVARCHAR (128) NOT NULL,
    [employeeId]                 BIGINT         NOT NULL,    
    [subjectCode]                NVARCHAR (128) NOT NULL, 
    [lectureComment]             NVARCHAR (MAX) NULL,
    [lectureDate]                DATE           NOT NULL,

   CONSTRAINT [PK_dbo.Timetable] 
   PRIMARY KEY CLUSTERED ([location] ASC,  [term] ASC, [employeeId] ASC, [subjectCode] ASC));

В этой таблице более 400 тыс. Строк

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

Структура TimetableBackup

  CREATE TABLE [dbo].[TimetableBackup] (
    [academicYear]               NVARCHAR (128) NOT NULL, 
    [location]                   NVARCHAR (128) NOT NULL,   
    [term]                       NVARCHAR (128) NOT NULL,
    [employeeId]                 BIGINT         NOT NULL,    
    [subjectCode]                NVARCHAR (128) NOT NULL, 
    [lectureComment]             NVARCHAR (MAX) NULL,
    [lectureDate]                DATE           NOT NULL,

   CONSTRAINT [PK_dbo.TimetableBackup] 
   PRIMARY KEY CLUSTERED ([location] ASC,  [term] ASC, [employeeId] ASC, [subjectCode] ASC));

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

Answer 1

Чтобы оптимизировать поиск по acadamicYear, вы можете выполнить следующие шаги:

• создать год таблицы поиска со следующей структурой:

   [academicYearID] SMALLINT
  ,[acadamicYear] NVARCHAR(128)
  

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

• создал индекс для столбца academicYearID в вашей таблице резервного копирования - индексы будут небольшими (но в нем содержится хранилище PK в порядкедля ссылки на исходную таблицу, поэтому размер здесь относительный);

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

Можно ли применить эту логику к полям исходной таблицы?

Следующие столбцы являются частью вашего ПК:

[location]                   NVARCHAR (128) NOT NULL   
[term]                       NVARCHAR (128) NOT NULL
[employeeId]                 BIGINT         NOT NULL    
[subjectCode]                NVARCHAR (128) NOT NULL

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

Наличие такого PK оптимизирует ваши операции чтения, так как небольшие данные будут читаться.Это также улучшит размер других индексов (оттуда вы снова получаете небольшое чтение и более быстрые запросы).