Храните данные в БД, чтобы первичный ключ был известен перед вставкой на основе данных, которые нужно вставить - PullRequest
0 голосов
/ 18 мая 2011

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

Основная суть того, как оноработает с использованием простого тега img, атрибут src будет указывать на сервер изображений в соответствии со следующими строками:

<img src="http://imageserver.com/<clientname>/<primarykey>.jpg">

Это позволяет изменять размер изображения асинхронно, и надругой сервер, таким образом, не замедляя текущий вызов страницы.

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

В настоящее время я делаю это с использованием хэш-системы, где параметры упорядочены в алфавитном порядке, а затем хэшируются.Является ли это разумной системой, или в конечном итоге возникнут коллизии хеширования, даже если хешируемые данные достаточно малы (от 50 до 200 символов).Каждый клиент может хранить до 10 000 изображений (в своей собственной папке, чтобы коллизия хешей не была проблемой для разных клиентов).

Для сокращения вызовов БД при обработке страницы каждый раз, когда требуется обработанное изображениеЯ добавляю информацию об этом изображении в массив.В конце страницы я делаю 2 обращения к БД, сначала она проверяет, существуют ли строки в моем массиве в БД, а затем, если необходимо, добавляет любые несуществующие строки (сохраняя их различные параметры).Дилемма здесь заключается в том, что первичный ключ (или то, что входит в тег изображения) должен быть известен до того, как будет фактически вставлен в БД, поэтому я не проверяю каждое изображение, так как некоторые страницы могут иметьсотни изображений на них, и это было бы очень неэффективно.

Разве коллизии хешей не имеют значения для этого размера выборки (10 тыс. изображений на клиента, сгенерированных 50-200 символьными строками)?А что если я сделал что-то простое, например <width>_<height>_<hash>.jpg, или поместил изображения в папки, такие как /<client>/<width>x<height>/<hash>.jpg, потому что это еще больше уменьшило бы вероятность коллизий хешей (хотя и не удалял их)?

Ответы [ 3 ]

1 голос
/ 18 мая 2011

Как ты хэшируешь? Используйте SHA-512 для алгоритма хеширования, и вы получите строку длиной 128 символов. Вы можете не хотеть URL так долго, но идея в том, что вы можете минимизировать коллизии с помощью более сложных алгоритмов.

http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c52.html

0 голосов
/ 14 сентября 2011

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

0 голосов
/ 20 мая 2011

Даже если я сомневаюсь, что вам придется беспокоиться о коллизиях хеша, вы можете просто использовать UUID.

http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-70de.html

РЕДАКТИРОВАТЬ: Или используйте уникальный идентификатор в качестве первичного ключа таблицы, в которой вы храните файл. Затем после вставки вы можете использовать предложение OUTPUT запроса, чтобы вернуть ключ, который вы хотите использовать.

...