Java: простой способ преобразования большой строки в меньшую строку фиксированной длины

Question

Я работаю над проблемой, когда мне нужно сравнить содержимое объектов JSON. Я должен делать это многократно для многих записей.Я не могу выполнить сравнение Apple с Apple, поскольку мне нужно пропустить несколько полей для сравнения, а также данные в массивах могут иметь разный порядок.

Например, Следующие JSON считаются имеющими одинаковое содержимое.даже если они имеют

• другое значение "id".
• Другая последовательность значений в массиве «интересов».

Json1:

{
"id":1,
"name":"John",
"dept":"HR",
"interests":["Reading","Cycling"]
}

Json2:

{
"id":5,
"name":"John",
"dept":"HR",
"interests":["Cycling","Reading"]
}

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

• id NUMBER (10)
• name VARCHAR (256)
• отдел VARCHAR (256)
• интересы VARCHAR (256)

Поля, которые сопоставляются со столбцами базы данных(id, name, dept) хороши для прямого запроса.Значения интересов могут расти, и они являются динамическими, я хочу написать метод , чтобы сгенерировать уникальную строку, используя значения из массива «интересов», так что мне не нужно хранитьвсю строку в таблицу.

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

Примечание: В моих JSON есть несколько более сложных объектов, для упрощения я взял простойJSONs.

Answer 1

Вы хотите каким-то образом сохранить длинную строку в коротком (э) пространстве. Стратегия зависит от ваших потребностей. Несколько вещей для рассмотрения:

• Вам нужно проиндексировать поле (чтобы выполнить SELECT на основании этого?)
• Вам нужно сравнить строки на равенство? Если да, допустимы ли ложные срабатывания?
• ...

У вас есть несколько вариантов, все с плюсами и минусами.

Правильный реляционный реферинг один-ко-многим

Как уже упоминалось, правильный способ сделать это - нормализовать ссылки. Таким образом, таблица из (id, interest) кортежей и другой с (data-id, interest-id) ссылками обеспечит без потери информации .

Обрезать строку

Например, 18 символов:

The quick brown fox jumps over the lazy dog -> The quick brown fo
The quick brown fox jumps over the fence    -> The quick brown fo

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

Хэш строка

Например, md5 :

The quick brown fox jumps over the lazy dog -> 9e107d9d372bb6826bd81d3542a419d6
The quick brown fox jumps over the fence    -> 26d68913b492ebb7fe734b973a358ab8

Опять же, это приводит к потере информации:

1. Хеш-коллизии, поскольку выходное пространство (размер зависит от алгоритма) меньше, чем входное пространство (практически не ограничено)
2. Хеширование является односторонней операцией

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

Сжать строку

Например, выкачивают :

The quick brown fox jumps over the lazy dog <-> eJwLyUhVKCzNTM5WSCrKL89TSMuvUMgqzS0oVsgvSy1SKAFK5yRWVSqk5KcDAFvcD9o=
The quick brown fox jumps over the fence    <-> eJwLyUhVKCzNTM5WSCrKL89TSMuvUMgqzS0oVsgvSy1SKAFKp6XmJacCAC1yDsE=

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

---

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