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

бы хранить в БД.

Например, при удалении: "Вы действительно хотите удалить ... [название элемента]?"

А название элемента передавать в параметр ХП. Строку с сообщением дергать из таблицы. Для каждого случая она была бы своя. Делали что-то подобное?

Чем меньше мы дергаем БД по пустякам, тем лучше. :-) Я делал просто один запрос - получаем текущую локализацию всех сообщений и все. И да, с кешированием - чтобы каждый раз при запуске проги не гонять простыни

А куда кэшировал? SQLite?

в памяти

поразному, мне проще было использовать писанный давно кусок свой - просто сохраняем данные как строку, загоняем в файл и мд5 его считаем. МД5 сохраняем в БД - при обращени прога проста считывает файлы, считаем МД5, если МД5 для каждого файла совпал - то ничего не запрашиваем с БД и сразу приступаем к работе

С MD5 прикольно придумано. Спасибо большое! Возьму на вооружение

CRC32 не достаточно?

МОжно. Но как-то уж повелось, переделывать не хочу - работает и славно :)

MD5 больше уникальности. скс32 я пару раз натыкался что црц=, а данные разные, поэтому на мд5 еще в лохматом году перешел так и повелось

ровесники )

Стикер

Ну так и уникальности больше

Терминологию нужно правильную использовать, уникальности блин...

Она правильная В crc32 мы имеем 32 бита уникальных значений А в md5 мы имеем 128 бит уникальных значений В мд5 уникальности больше очевидно

Стикер

Да это как два пальца об асфальт сделать. Вот тебе три разных файла с одной контрольной суммой равной нулю.

Вот у меня есть блоб, в котором данные, произвольные. Crc32 выдавал несколько раз одно и тоже значение при изменении, в итоге было проворонены изменения и это было плохо очень. Перешёл на мд5 и такие приколы более не повторялись

длина блоба? и количество "провороненных" байт?

Лучше использовать Fnva1a 64 - считается быстро, коллизий мало, оперировать проще чем MD5, который неудобно в базе хранить

64 vs 128

ты еще попробуй столько блобов в базе накопить, чтобы получить коллизии на 64 битной хеш функции

Достаточно двух

Сейчас это сложно вспомнить, но это было обновление картинок, они от 3к до 150к были и надо было отслеживать изменения при заливке новой но не триггером в бд, а внешними сервисами. Хранить вне бд был неудобно, поэтому именно так было. И вот при обнове црц32 поле считалось, и если не совпадало внешний сервис получал новый блок, и вот когда нужно это не произошло и это повлекло цепочку негативных событий

ну, то есть, обновились все байты — налицо неуместное применение алгоритма CRC

Стикер

Фнва нету деф функции , а так в пг есть из коробки мд5, а хранить пофиг, hash индекса хватает, а уникальность индекса тут не нужна

Црц32 может выдать сбой и при перестановке двух байт в одних и тех же данных, но отличающимися только двумя байтами

нет, не путай с дополнением

да, потому что есть границы применения, в которых этот алгоритм доказанно срабатывает

А почему бы не хранить пару хэшей по разным алгоритмам - так вероятность коллизии будет значительно ниже?

Можно, но пока мне мд5 хватает для моих целей :) делать

поясни-ка вот это, покажи на примере, что и как переставить, чтобы сумма не изменилась

я тебе там выше архив приложил с разными данными и одинаковой контрольной суммой

у них длина разная... и вообще - ты ж сам сказал - это разные данные меня интересует ловля искажений одних данных

Могу сделать с одинаковой длиной, меньться будут только 5 байт

процент изменяемой информации слишком велик давай файл килобайт, и поменяй 2 байта )

Могу сделать чтобы это были меговые блобы у которых будут меняться только пять байт :)

Ну ща, 5 мин