Дизайн таблицы базы данных. Есть ли проблемы с использованием длинного столбца в качестве первичного ключа?

Question

Простите за глупый или очевидный вопрос - я новичок в базах данных.

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

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

Таблица будет содержать порядка 10k-100k строк.

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

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

Я планирую использовать VARCHAR(4096), поскольку максимальная длина пути linux 4096 символов.

Есть ли плюсы или минусы в создании таблицы таким образом, с указателем на то, что может быть довольно длинным столбцом VARCHAR? Как вы предлагаете мне разработать таблицы?

Спасибо!

Answer 1

Не используйте длинную символьную строку в качестве первичного ключа.

Используйте синтетический c первичный ключ.

Вот несколько причин:

• Одной из важных целей первичных ключей является поддержка внешних ключей. Вы не хотите, чтобы по всей базе данных скрывалось 4 тыс. Строк, тогда как у вас могло бы быть 4-байтовое целое число.
• Еще одна важная причина для первичных ключей - это уникальный поиск каждой строки. Большинству людей, которых я знаю, не нужно вводить 4k символов, чтобы идентифицировать строку. Я печатаю быстро, и это займет у меня время. И я уверен, что я бы сделал опечатку где-нибудь по пути.
• Две строки могут отличаться только, скажем, в 2017-м символе. Я не хотел бы выяснять, что они отличаются, особенно если символ является 1 против l или O против 0.

Определить автоматическое увеличение / идентификационный / серийный первичный ключ. Вы всегда можете объявить URL-адрес как unique, чтобы он не дублировался (хотя некоторые базы данных могут не разрешать такой длинный ключ в индексе).

Answer 2

Отказ от ответственности: Это очень личное мнение, и, вероятно, многие люди не согласятся.

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

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

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

Я бы порекомендовал вам использовать простой INT или BIGINT в качестве первичного ключа и добавить ограничение UNIQUE к свойству пути. Таким образом, ваша модель будет более гибкой. Если носитель перемещен по другому пути, вам просто нужно обновить одно значение в таблице; если бы путь был PK, вам нужно было бы обновить все внешние ключи, связанные с ним.