Оптимизируйте базы данных SQL путем добавления столбцов индекса

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

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

Я не мог бы сказать лучше, поэтому ознакомьтесь с этим ответом: Следует ли мне создавать таблицу с первичным ключом varchar или int , процитируйте этот ответ:

Использование VARCHAR (10) или (20) просто использует слишком много места - 10 или 20 байт вместо 4, и что много людей не знаю - значение ключа кластеризации будет повторяться для каждого индекса запись для каждой некластеризованной index в таблице, поэтому потенциально вы тратите много места (не только на диске - это дешево - но также в основной памяти SQL Server). Также, поскольку это переменная (может быть 4, может быть 20 символов) сложнее для SQL-сервера правильно поддерживать хороший индекс структура

Целочисленный тип данных в большинстве реализаций будет меньше по размеру, чем строка (CHAR, VARCHAR и т.д.), это сделает ваш индекс меньше по размеру.

Кроме того, есть некоторые проблемы со сравнением строк:

1. Некоторые базы данных, а именно MySQL, сжимают строковые ключи, что может сделать поиск менее эффективным.

2. Строковые B-деревья, использующие идентификаторы естественного языка, имеют тенденцию быть менее сбалансированными по параллельности, чем целочисленные B-деревья. Поскольку слова естественного языка распределены по алфавиту неравномерно, больше обновлений и вставок будет происходить в один и тот же блок, что увеличивает количество разбиений страниц и, в конечном счете, увеличивает размер индекса. Чтобы обойти эту проблему, Oracle поддерживает REVERSE клаузулу в индексах.

3. При сравнении двух строк необходимо учитывать коллизию. Обычно это не имеет большого значения, однако добавляет некоторые накладные расходы.

целочисленный столбец действует лучше, чем строка в соединениях

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

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

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

Если, например, на продукте был проставлен серийный номер, который должен был существовать на момент ввода строки в базу данных и гарантированно был уникальным, то IMO, который сделал бы хороший первичный ключ. Причина в том, что это значение будет использоваться в качестве внешнего ключа в других таблицах, что избавит вас от затрат на дополнительный поиск серийного номера продукта. Дополнительное пространство для хранения не имеет значения, пока вы не попадете в миллионы строк. Однако, если серийный номер проштампован каким-то другим производителем, поэтому у вас нет гарантий уникальности («вероятно, уникальный» недостаточно), тогда подойдет суррогат. Фактически, я бы пошел так далеко, чтобы сказать, что значительная часть, если не большинство таблиц «продуктов», используют суррогатные ключи, потому что никакое значение, которое гарантированно будет доступно во время входа, гарантированно уникально и будет относительно неизменным, не доступно как ключ.

Однако , многие разработчики, использующие суррогатные ключи, упускают из виду необходимость, чтобы каждая таблица, имеющая суррогатный ключ, также имела другой ключ (то есть уникальное ограничение). Таким образом, в вашем случае с продуктами, даже если вы добавите целочисленный первичный ключ, у вас все равно должно быть уникальное ограничение на имя продукта. Уникальное ограничение на имя продукта создает так называемый ключ-кандидат с целочисленным значением, являющимся первичным ключом.

Суррогатные ключи предназначены для скрытой информации. Хотя целочисленные ключи работают лучше всего и их легко создать, у них есть один недостаток: разработчики приложений легко, даже соблазнительно, показывают значение ключа пользователям. Это ошибка ИМО. Пользователи никогда не должны видеть значение ключа, иначе они будут полагаться на само значение, что создает проблемы, если вам нужно изменить последовательность значений (например, при слиянии базы данных) или если вы используете значения, которые были созданы в промежутках, созданных Значение идентичности, и они полагаются на то, что значения являются последовательными. Если вы никогда не показываете значение пользователям, можно использовать целочисленный PK.