Для меня это звучит как FUD.

имаюсь разработкой программного обеспечения облачного хранилища поверх стека LAMP.

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

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

Клиенты могут хранить файлы под любой строкой (обычно это какой-то путь и имя файла).

Эта строка гарантированно будет уникальной, потому что на первом уровне это что-то вроде «корзин», которые пользователи должны регистрировать, как в Amazon S3 и Google Storage.

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

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

Но я боюсь столкновений. В настоящее время я думаю об использовании хэшей SHA1.

Я слышал, что GIT использует хэши и идентификаторы ревизий.

Я знаю, что вероятность столкновений действительно очень мала, но возможна.

Я просто не могу судить об этом. Будете ли вы или не хотите полагаться на хэш для этой цели?

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

Ответы на вопрос(2)

Ваш ответ на вопрос