Индексирование varchars & Foreign Keys

Question

У меня есть две таблицы, определенные ниже.

Create table tickets (id long not null,
reseller long not null,
constraint pk_lock primary key (id)); 

Create table ticketRegistrations (id long not null,
customer long not null,
constraint fkTicketRegistrationTicket 
  foreign key (id) references tickets (id) on update cascade); 

Клиент может вводить тикеты (следовательно, нет автоинкремента для первичного ключа). Поскольку id является первичным ключом и внешним ключом таблицы регистрации заявок, существуют ограничения целостности и все такое прочее. Проблема, с которой я столкнулся, - это запрос функции, который должен допускать заполнение нулями идентификатора билета (то есть 00070). Насколько мне известно, целые числа нельзя хранить с нулевым заполнением.

Какое решение я придумал, это добавить столбец ticketID varchar (8), не равный NULL, в таблицу заявок и использовать фактический идентификатор для ОБОИХ СТОЛОВ в качестве суррогатного ключа. Тогда внешний ключ таблицы регистрации билетов будет указывать на тикетид.

У меня вопрос к эффективности и скорости. Ранее я мог добавить регистрацию заявок в системе, и база данных накладывала бы ограничение целостности на добавление, чтобы увидеть, находится ли билет с тем же идентификатором в базе данных. Теперь у меня есть строка varchar для идентификатора, который будет проиндексирован.
Когда клиент "регистрирует билет", будет ли проще сохранить тикетид varchar в таблице тикетов и использовать внешний ключ тикетида в таблице регистрации тикетов (также varchar (8))?

Или будет проще НЕ иметь ticketid varchar (8) в регистрации заявок, оставить внешний ключ к таблице заявок в качестве первичного ключа таблицы регистрации заявок и сначала проверить наличие тикетида в таблице заявок, получить значение, и ввести его в строку внутри регистрации заявок?

Это создаст индексированный поиск varchar в таблице заявок перед каждой вставкой в ​​таблицу заявок на регистрацию.

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

Меня беспокоит время поиска.

Answer 1

У меня есть два решения.

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

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

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

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

Answer 2

Я бы оставил идентификаторы и ограничения по иностранным лей как есть. Добавьте второй вычисляемый столбец varchar и добавьте в него ведущие нули. Используйте первый столбец для всей работы и отобразите второй столбец.