В настоящее время я планирую разработать приложение для потоковой передачи музыки. И мне интересно, что было бы лучше в качестве первичного ключа в моих таблицах на сервере. ID int или уникальная строка.
Методы 1:
Таблица композиций: SongID (int), Название (строка), * Исполнитель ** (строка), Длина (int), * Альбом ** (строка)
Таблица жанров Жанр (строка), Имя (строка)
SongGenre: *** SongID **** (int), *** Жанр **** (строка)
Способ 2
Таблица композиций: SongID (int), Title (string), * ArtistID ** (int), Length (int), * AlbumID ** (int)
Таблица жанров GenreID (int), Имя (строка)
SongGenre: *** SongID **** (int), *** GenreID **** (int)
Ключ: Жирный= Основной ключ, * Поле ** = Внешний ключ
В настоящее время я разрабатываю метод с использованием метода 2, поскольку, как я полагаю, он ускорит работу с поиском и использует меньше места, поскольку int занимает намного меньше места, чем строка.
Есть ли причина, по которой это не очень хорошая идея? Есть ли что-то, о чем я должен знать?
Вы поступаете правильно - поле идентификации должно быть числовым, а не строковым, как для экономии пространства, так и для повышения производительности (сопоставление ключей по строкам происходит медленнее, чем сопоставление по целым числам).
Есть ли причина, по которой это не очень хорошая идея? Есть ли что-то, о чем я должен знать?
Да. Целочисленные идентификаторы очень плохи, если вам нужно однозначно идентифицировать одни и те же данные за пределами одной базы данных. Например, если вам нужно скопировать одни и те же данные в другую систему баз данных с потенциально имеющимися ранее данными или иметь распределенную базу данных. Самое большое, о чем нужно знать, это то, что целое число, подобное 7481, не имеет значения за пределами этой одной базы данных. Если позже вам нужно вырастить эту базу данных, это может быть невозможно без хирургического удаления ваших данных.
Другая вещь, о которой нужно помнить, заключается в том, что идентификаторы целочисленных идентификаторов не так гибки, поэтому их нельзя легко использовать для исключительных случаев. Разработчики Internet Protocol понимали это и принимали меры предосторожности, выделяя определенные блоки чисел как "специальные" так или иначе (широковещательные IP-адреса, частные IP-адреса, сетевые IP-адреса). Но это было возможно только потому, что существует протокол, связанный с использованием этих чисел. Многие базы данных не работают в таком хорошо определенном протоколе.
FWIW, это похоже на попытку решить, лучше ли использовать "строго типизированную" парадигму программирования, чем "слабо/динамически типизированная" парадигма программирования. Это будет зависеть от того, что вам нужно сделать.
С точки зрения программного обеспечения GUID лучше всего уникален во всем мире.
Цитаты из: Первичные ключи: идентификаторы и идентификаторы GUID
Использование идентификатора GUID в качестве значения идентификатора строки кажется более естественным - и безусловно, более по-настоящему уникальным, чем 32-битное целое число. Гуру базы данных Джо Celko похоже, согласен. Первичные ключи GUID являются естественным для многих сценарии разработки, такие как репликация или когда вам нужно генерировать первичные ключи вне базы данных. Но это еще вопрос балансировки компромиссов между традиционными 4-байтными целыми идентификаторами и 16-байтные идентификаторы GUID:
GUID Pros
- Уникально для каждой таблицы, каждой базы данных, каждого сервера
- Позволяет легко объединять записи из разных баз данных.
- Позволяет легко распределять базы данных на нескольких серверах.
- Вы можете создавать идентификаторы в любом месте, вместо того, чтобы совершать кругооборот в базу данных
- В большинстве сценариев репликации требуются столбцы GUID в любом случае
Недостатки GUID
- Это 4 раза больше, чем традиционное 4-байтовое значение индекса; это может иметь серьезные последствия для производительности и хранения, если вы не внимательны.
- Громоздко отлаживать, где userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'
- Сгенерированные идентификаторы GUID должны быть частично последовательными для обеспечения максимальной производительности (например, newsequentialid() на SQL 2005) и для использования кластеризованные индексы
Моя рекомендация: используйте идентификаторы.
Вы сможете переименовать этот "жанр" с 20000 песнями, не нарушая ничего.
Идея заключается в том, что идентификатор идентифицирует строку в таблице. Независимо от того, какая строка имеет значение, это не имеет значения в этой проблеме.
В значительной степени это вопрос личных предпочтений.
Мое личное мнение и практика - всегда использовать целые ключи и всегда использовать суррогатные, а не естественные ключи (поэтому никогда не используйте ничего, например, номер социального страхования или название жанра).
Есть случаи, когда поле автоматического номера не подходит или не масштабируется. В этих случаях может иметь смысл использовать GUID, который может быть строкой в базах данных, для которых нет родного типа данных.
MSSQL может генерировать этот идентификатор для вас при использовании int (см. ключевое слово IDENTITY)