Почему большинство баз данных SQL позволяют определять один и тот же индекс дважды?

Question

Почему большинство баз данных SQL позволяют определять один и тот же индекс (или ограничение) дважды?

Например, в MySQL я могу сделать:

CREATE TABLE testkey(id VARCHAR(10) NOT NULL, PRIMARY KEY(id));
ALTER TABLE testkey ADD KEY (id);
ALTER TABLE testkey ADD KEY (id);
SHOW CREATE TABLE testkey;
CREATE TABLE `testkey` (
  `id` varchar(10) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `id` (`id`),
  KEY `id_2` (`id`)
)

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

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

Answer 1

Есть только две веские причины, о которых я могу подумать, для возможности определения одного и того же индекса дважды

1. для совместимости с существующими сценариями, которые действительно определяют один и тот же индекс дважды.
2. изменение реализации потребует работы, которую я не желаю ни делать, ни платить за

Answer 2

На ум приходит несколько причин.В случае продукта базы данных, который поддерживает несколько типов индексов, возможно, вы захотите, чтобы одно и то же поле или комбинация полей были проиндексированы несколько раз, причем каждый индекс имеет свой тип в зависимости от предполагаемого использования.Например, некоторые (возможно, большинство) продуктов баз данных имеют древовидный индекс, который подходит как для прямого поиска (например, KEY_FIELD = 1), так и для сканирования диапазона (например, KEY_FIELD> 0 AND KEY_FIELD <5).Кроме того, некоторые (но определенно не все) продукты баз данных также поддерживают тип хешированного индекса, который полезен только для прямого поиска, но очень быстр (например, будет работать для сравнения, такого как KEY_FIELD = 1, но который не может быть использован длядиапазон сравнения).Если вам нужно очень быстрое время прямого поиска, но все же необходимо обеспечить ранжированное сравнение, может быть полезно создать как древовидный индекс, так и хешированный индекс. </p>

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

Answer 3

Все языки программирования позволяют писать резервы:

<?php
$foo = 'bar';
$foo = 'bar';

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

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

Вас может заинтересовать инструмент под названием Maatkit, который представляет собой набор необходимых инструментов для пользователей MySQL. Один из его инструментов проверяет наличие дубликатов ключей:

http://www.maatkit.org/doc/mk-duplicate-key-checker.html

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

Что касается именования индексов, это позволяет вам сделать это:

ALTER TABLE testkey DROP KEY `id`, DROP KEY `id_2`;

Если бы они не были названы, у вас не было бы возможности отбросить отдельные индексы. Вам придется отбросить всю таблицу и воссоздать ее без индексов.

Answer 4

Я вижу, что некоторые базы данных предотвращают дублирование индексов.Oracle Database предотвращает дублирование индексов https://www.techonthenet.com/oracle/errors/ora01408.php, в то время как другие базы данных, такие как MySQL и PostgreSQL, не имеют предотвращения дублирования индексов.

Answer 5

Потому что базы данных, которые поддерживают покрывающие индексы - Oracle, MySQL, SQL Server ... (но не PostgreSQL, как ни странно). Покрывающий индекс означает индексирование двух или более столбцов и обрабатываются слева направо для этого списка столбцов, чтобы использовать их.

Так что, если я определяю индекс покрытия для столбцов 1, 2 и 3 - мои запросы должны использовать, как минимум, столбец 1, чтобы использовать индекс. Следующая возможная комбинация - это столбцы 1 и 2 и, наконец, 1,2 и 3.

Так что насчет моих запросов, которые используют только столбец 3? Без двух других столбцов индекс покрытия не может быть использован. Это та же проблема, что и для использования только в столбце 2 ... В любом случае, в такой ситуации я бы рассмотрел отдельные индексы для столбцов 2 и 3.

Answer 6

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

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