Уникальное обозначение фотографий - GUID и последовательный номер

Question

Некоторое время назад я написал систему управления планом для совета, над которым я работаю, что позволяет хранить все старые и новые планы в цифровом формате с информацией, связанной с помощью базы данных доступа (В то время я не знал сервер MS SQL).

Каждый план имеет уникальный идентификатор плана, который представляет собой просто инкрементный int (первичный ключ), заголовок и путь к изображению. В то время я просто использовал GUID как имя изображения, чтобы обеспечить уникальность, и мне просто интересно, было ли это плохой ход.

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

Я думал, что, возможно, я должен был просто использовать auto incrementing int как имя файла, а не длинный и не очень дружественный GUID для пользователя/отладки.

Что вы хотите сделать?

EDIT: Извините, забыл упомянуть, что файлы действительно известны только программному обеспечению, после импорта программа создает ярлык для файла в папке, в которую он был импортирован, с именем исходного файла. Я сделал это так, чтобы люди все еще могли попасть в документ, не выполняя программу, и поэтому работали старые гиперссылки и т. Д.

Answer 1

Обычно целые ключи работают быстрее, но при некоторых обстоятельствах вы можете столкнуться с проблемами с архивированием и репликацией, если не будете осторожны. Если у вас нет проблем/проблем с производительностью, я бы склонен придерживаться GUID.

В любом случае я бы рекомендовал вам разрешить пользователю назначать «дружественное» имя каждому изображению, отображаемому в пользовательском интерфейсе.

Answer 2

Зависит; это имя файла, которое используется/видно/указано пользователями или просто с помощью программного обеспечения? Будут ли пользователи «знать» идентификатор плана, а затем поехать посмотреть имя файла на диске?

Я подозреваю, что только что использовал идентификатор плана в качестве имени файла, если ответ «нет, нет» - хотя я не вижу никакого реального недостатка в использовании GUID в этом случае.

Answer 3

Как я понимаю, эти изображения должны использоваться только самим программным обеспечением, а не непосредственно людьми. Если бы я не мог найти веские причины для изменения, я бы оставил его как есть.

Answer 4

Если у вас есть какие-либо планы по тиражированию или «работе в автономном режиме», я бы рекомендовал вам использовать GUID для имени файла и pk таблицы.

Answer 5

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

Если пользователи взаимодействуют непосредственно с центральной папки, я хотел бы использовать GUID в базе данных и понятное имя в файле, используя алгоритм обнаружения столкновения

extension = getFileExtension(); 
filename = getFriendlyName(); 
int i = 1; 
while (File.Exists(filename)) { 
    filename = getFriendlyName() + (i++); 
} 
writeFile(filename+extension); 

Помните, что вы можете иметь более легкое извлечение с помощью имеющие подпапки в этой центральной папке на буквы (A \, B \ и т. д.) или комбинации букв

Answer 6

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

Answer 7

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

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

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

Выбор между GUID или целым числом, чтобы сделать имя более удобным для пользователя? Зачем? Если вы хотите удобные имена, дайте пользователю предоставить их ...

Answer 8

У GUID в Access есть несколько проблем. Все они изложены здесь:

http://trigeminal.com/usenet/usenet011.asp?1033

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

Если вы храните фотографии и нуждаетесь в уникальности, случайный Autonumber будет давать больше, чем достаточно большое числовое пространство для хранения любого количества графических файлов, которые будет создавать любое приложение реального мира. И если вы не добавляете в независимых местах, для этого нет никаких оправданий - стандартный инкрементный Autonumber будет просто прекрасен и отлично подходит для многопользовательской среды (и полностью плавный переход к однопользовательской среде).

Таким образом, NO - GUID не являются хорошим выбором, и они не кажутся оправданными ничем, что вы описали в своем исходном вопросе.