С новым старым глюком в TPS!

[Губин Игорь]

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

У меня есть кусок. когда хеш генерится за раз для, около, 100000 случайных строк в несколько килобайт. И раза два в год эта уникальность ломается. Я много могу об этом рассказать.

[Игорь Столяров]

Размер локатора вторичен от размера строки для проверки на дублирование

Возможно мы разное называем "локатором" ?
Для меня локатор - это последовательность вводимых (для BROWSE) символов, для которой сразу
отображается запись в списке. Кто-то будет вводить для поиска более 40 (120) символов таких формул ?

Кроме того, выравнивание регистров не всегда допустимо

Не нормализуйте - это опция. Если у Вас "a+b-c" и "a+ b-C" - это разное, просто желаю удачи в поиске.

И раза два в год эта уникальность ломается. Я много могу об этом рассказать.

Таки попробуйте взять современный алгоритм, вместо 30-летнего SHA1 / MD5.
Или по ГОСТ от Crypto-Pro c допуском для гостайны, если есть достойная задача.

[Губин Игорь]

Возможно мы разное называем "локатором" ?
Для меня локатор - это последовательность вводимых (для BROWSE) символов, для которой сразу
отображается запись в списке. Кто-то будет вводить для поиска более 40 (120) символов таких формул ?

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

Если у Вас "a+b-c" и "a+ b-C" - это разное, просто желаю удачи в поиске.

Пробелы, да и кое что ещё, я подчищаю. А вот "a+b-c" и "a+b-C" у меня, действительно, разные формулы, что порождает массу проблем, но это совсем другая история.

Поясняю, в формуле в пару десятков символов уже сложно найти отличия, замыливается глаз у девочки, а когда формулы в 1000 символов и различие всего в одной цифре... Вот тут без точной проверки на уникальность не обойтись. Иначе девочки, в начале, наплодят кучу одинаковых или почти одинаковых записей, а потом в них запутаются.

Таки попробуйте взять современный алгоритм, вместо 30-летнего SHA1 / MD5.
Или по ГОСТ от Crypto-Pro c допуском для гостайны, если есть достойная задача.

Одному мне кажется, что проще оказалось решить проблему с длиной строки?

[Губин Игорь]

ЛЮДИ!!! Объясняю ещё раз: сверхзадача самыми простыми и надёжными методами отловить случай ввода уже ранее введённой строки, если оператор "поплыла" и начинает не замечать записи. Т.е. самый примитивный Duplicate идеально решает эту задачу.

А проблема возникла из-за того, что если длина строки в ключе 1024, что совсем не много, то для файла TPS ломается или ключ или драйвер или не знаю что, но ни одно из средств просмотра содержимого файла (ни среда, ни topscan, ни view, ни примитивный SetNext) по ключу не отрабатывает нормально. Сейчас всё решилось урезанием строки до 512 символов (90% случаев) и особыми алгоритмами ввода для более длинных записей.

[Игорь Столяров]

сверхзадача самыми простыми и надёжными методами

1. Есть проблема с индексаций длинных строк в TPS (скорее всего просто незаявленное ограничение).
2. Если тупо работать с строкой "как есть" - то либо перебор и сравнение, либо смена драйвера для списка.
3. Давно хочу попробовать встроенный SQLite, там вообще нет понятия длины строки, а просто TEXT ...

[Губин Игорь]

1. Есть проблема с индексаций длинных строк в TPS (скорее всего просто незаявленное ограничение).

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

2. Если тупо работать с строкой "как есть" - то либо перебор и сравнение, либо смена драйвера для списка.

Тупой перебор это жестоко. Такое у меня есть в куске упаковки файлов и не самая быстрая операция.

3. Давно хочу попробовать встроенный SQLite, там вообще нет понятия длины строки, а просто TEXT ...

Я с ним работал в задачах обмена с мобильными устройствами. Для небольших файлов вполне приемлемо.

[kreator]

Сортировка по ключу не работает. А если без ключа, просто по ORDER?

[RaFaeL]

У меня есть кусок. когда хеш генерится за раз для, около, 100000 случайных строк в несколько килобайт. И раза два в год эта уникальность ломается. Я много могу об этом рассказать.

А можно примеры?

[Губин Игорь]

А можно примеры

Если честно, то очень долго вырезать. Это во встроенном контроле целостности критических данных. И кстати, как по заказу, только что вывалилось.

[Игорь Столяров]

Чего вырезать-то ? Просто покажите 2 текстовых строки у которых одинаковый SHA1 / MD5 ...

[Губин Игорь]

Чего вырезать-то ? Просто покажите 2 текстовых строки у которых одинаковый SHA1 / MD5 ...

Хорошо, когда будет - постараюсь прислать. Это "глухой" кусок, который надо будет переделать для вывода. Да и самого совпадения надо ждать. Надеюсь, что долго

[Игорь Столяров]

Лет десять назад, на каком-то саммите по безопасности, были предъявлены 2 читаемых PDF файла с одинаковым SHA1.
Это вызвало переполох, но разработчики SHA1 тогда заявили, что это сложный, но именно фокус, т.к. формат PDF
позволяет набивать в него бинарный мусор и любой дурак может попробовать получить коллизию методом перебора.
И попросили тревожных предъявить текст с одинаковым хешем SHA1. На том всё и заглохло навсегда ...

[Губин Игорь]

И попросили тревожных предъявить текст с одинаковым хешем SHA1. На том всё и заглохло навсегда ...

У меня сходная ситуация, т.к. не какой-то внятный текст, а бессмысленный набор байтов с некоторой закономерностью.

Ну вот, сегодня, тьфу, тьфу, тьфу, без совпадений. Хотя прогнал в несколько раз больше записей.

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