Действительно ли Гуид является лучшим типом данных идентификационных данных для Баз данных?
Документация Qt гласит
Что касается
qmake, документация Qt не совсем точна, если не сказать больше. Нужно всегда обращаться к исходному кодуqmake, чтобы узнать правду.Так что после некоторого поиска в источнике это выглядит следующим образом:
- Win :
VERSIONиспользуется для ресурсов Windows (как приложения, так и библиотеки);VER_MAJиспользуется только для суффикса совместно используемой библиотеки (например, «mylib1.dll»); еслиVER_MAJне установлено, то оно инициализируется изVERSION;VER_MINиVER_PATигнорируются.- * nix :
]VERSIONигнорируется, за исключением случаев, когда некоторые изVER_MAJ,VER_MINилиVER_PATне установлены напрямую, тогда они инициализируются косвенно изVERSION.Таким образом, для Win, вероятно, следует использовать только
VERSION. Для * nix реальной разницы нет.
7 ответов
Отредактированный после чтения ответа Frans Bouma, так как мой ответ был принят и поэтому перемещен в вершину. Спасибо, Frans.
GUID действительно делают хорошее уникальное значение, однако из-за их сложного характера, они не действительно человекочитаемы, который может сделать поддержку трудной. Если Вы собираетесь использовать GUID, Вы могли бы хотеть рассмотреть выполнение некоторого анализа производительности объемных операций данных перед совершением выбора. Примите во внимание, что, если Ваш первичный ключ "кластеризируется" затем, GUID не являются соответствующими.
Это вызвано тем, что кластерный индекс заставляет строки быть физически переупорядоченными в таблице на, вставляет/обновляет. Так как GUID случайны, каждая вставка потребовала бы, чтобы фактические строки в таблице были перемещены для освобождения дорогу для новой строки.
Лично мне нравится иметь два "ключа" на моих данных:
1) Первичный ключ
Уникальные, числовые значения с кластеризованным первичным ключом. Это - внутренний идентификатор моей системы для каждой строки и используется для однозначного определения строки и во внешних ключах.
Идентификационные данные могут доставить неприятности при использовании репликации баз данных (SQL Server добавит "rowguid" столбец автоматически для копируемых в слияние таблиц), потому что семя идентификационных данных сохраняется на экземпляр сервера, и Вы получили бы дубликаты.
2) Внешний Ключевой/Внешний идентификатор идентификатора/бизнеса
Часто также предпочтительно иметь дополнительное понятие "внешнего идентификатора". Это часто - символьное поле с ограничением на уникальность данных (возможно включая другой столбец, например, клиентский идентификатор).
Это было бы значением, используемым внешними интерфейсами, и будет выставлено клиентам (кто не распознает Ваши внутренние значения). Этот "бизнес-идентификатор" позволяет клиентам обращаться к Вашим данным с помощью значений, которые значат что-то для них.
Что-либо, что может однозначно определить запись, является хорошим типом данных идентификационных данных. GUID обычно хорош, но это не оптимальные идентификационные данные, если у Вас на самом деле есть уникальный идентификатор, прибывающий из исходных данных. GUID является случайным целочисленным значением, это, как гарантируют, будет уникально; однако, в ситуации с интеграцией, Вы часто хотите обнаружить дубликаты информации, не только подойти записи.
Нет никакого "лучшего" типа данных идентификационных данных. Различные варианты имеют различные достоинства и недостатки. Я использую GUID, как правило, но я должен регулярно иметь дело с разъединенными клиентами и репликацией слияния, таким образом, выбор является соответствующим. Если Вы не должны иметь дело с репликацией (т.е. ситуация, где пользователь добавляет новые записи, в то время как разъединено от центральной базы данных), автоувеличивающее международное поле является лучшим выбором.
GUID лучше в сценариях репликации данных с подходом "идентификационных данных", необходимо быть осторожны относительно не, вызывают коллизии между данными, копируемыми между Базами данных.Надеюсь, это поможет.
Вам, вероятно, будет нужно средство для отслеживания назад к источнику для аудита целей, особенно на финансовых данных.
Даже если Вы используете синтетический продукт, вводит Вашу складскую систему (который Вы почти наверняка хотите сделать, если у Вас будет несколько источников данных), то необходимо будет все еще поддерживать аудит. Поместите столбец 'Data Source' и 'Natural Key' на таблицы в Вашей системе и заполните их с кодом для источника и представления того, что однозначно определяет запись в источнике.
Если Вы делаете это, синтетические ключи должны только быть ints или численными данными, достаточно широкими для хранения достаточного количества значений (ints если <4b строки, численные данные если). Это означает, что они будут намного более читаемыми, чем GUID.
Следует иметь в виду, что GUID (или 'unique_identifier') для PK является плохим выбором как многие, PK имеет кластерный индекс (таким образом, все строки хранятся на диске в индексируемом порядке). Как GUID случайны, не бесспорно, что новая строка будет добавлена в конце индекса, но могла быть вставлена посреди индекса. Это вызывает диск, повреждающий, когда строки должны быть перемещены.
ЕСЛИ Вы рассматриваете гуид, по крайней мере, используйте sqlserver 2005 или и NEWSEQUENTIALID () для значения PK, для получения последовательного гуида, которые всегда больше, чем последний, так всегда добавляются в конце индекса. Если Вы не используете sqlserver (но например postgresql, или Вы используете оракула и используете CHAR (32) или другой тип), рассмотрите РАСЧЕСКУ (см.: http://www.informit.com/articles/article.aspx?p=25862)
Я раньше не любил GUID вообще, но я вырос для любви его. Я люблю его, потому что это относительно универсально и принято, и я заканчиваю тем, что писал меньше кода при помощи его и поддержал тот код, чем я обычно писал бы и поддерживал бы.
Для устройства хранения данных файлов, особенно полезно, где необходимо гарантировать, что имя файла уникально, в каталоге с потенциально большим количеством файлов, включая существующие ранее файлы.