2012-04-28 2 views
1

Вот сложная структура данных и организация данных.Сравнение содержания Java-карты

У меня есть приложение, которое считывает данные из больших файлов и производит объекты различных типов (например, Boolean, Integer, String), которые подразделяются на несколько (менее десятка) групп, а затем сохраняются в базе данных.

Каждый объект в настоящее время хранится в одной структуре данных HashMap<String, Object>. Каждый такой HashMap соответствует одной категории (группе). Каждая запись базы данных создается из информации во всех объектах, содержащихся во всех категориях (структуры данных HashMap).

Требовалось, чтобы проверить, являются ли последующие записи «эквивалентными» в количестве и типе столбцов, где эквивалентность должна быть проверена на всех картах путем сравнения имени (HashMap) и типа (фактического класса) каждого хранимый объект.

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

Идея состоит в том, чтобы просто сортировать ключи (например, заменяя каждый HashMap на TreeMap), а затем пройтись по всем картам. Альтернативой было бы просто скопировать все в TreeMap только для сравнения.

Что было бы самым эффективным способом реализации этой функциональности?

Кроме того, как вы могли бы найти разницу (то есть добавленные поля и удаленные), между последовательными записями?

ответ

2

Создайте мета SortedSet, в котором вы храните все созданные карты.

Средство SortedSet<Map<String,Object>>, например. a TreeSet, который как обычай Comparator<Map<String,Object>>, который точно проверяет ваши требования одного и того же номера и имен ключей и одного и того же типа объекта на каждое значение.

Затем вы можете использовать метод contains() этой структуры метаданных, чтобы узнать, существует ли аналогичная запись.

==== ==== EDIT

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

Все еще я использовал бы упомянутые SortedSet<Map<String,Object>>, но, конечно, Map<String,Object> теперь укажет на ту карту, которую вы и предложили hasxy.

С другой стороны, это может быть шагом вперед, чтобы использовать Set<Set<KeyAndType>> или SortedSet<Set<KeyAndType>>, где ваш KeyAndType будет содержать только ключ и тип с соответствующей Comparable реализации или equals with hashcode.

Почему? Вы спросили, как найти различия между двумя записями? Если каждая запись относится к одному из этих внутренних номеров Set<KeyAndType>, вы можете легко использовать retainAll(), чтобы сформировать пересечение двух последовательных наборов.

Если вы сравнили бы это с идеей SortedSet<Map<String,Object>>, в обоих случаях у вас была бы логика, которая различается между полями в компараторе, одно время сравнивая внутренние множества, одно время сравнивая внутренние карты. И так как эта информация теряется при построении окружающего набора, будет сложно получить различия между двумя записями позже, если у вас нет другой уменьшенной структуры, которая проста в использовании, чтобы найти такие различия. И так как такой Set<KeyAndType> может действовать как ключ, а также как простая основа для сравнения между двумя записями, он может быть хорошим кандидатом для использования в обеих целях.

Если к тому же вы хотите сохранить связь между такой Set<KeyAndType> к вашей записи или группы Map<String,Object> вашей мета-структуры может быть что-то вроде: Map<Set<KeyAndType>,DatabaseRecord> или Map<Set<KeyAndType>,GroupOfMaps> реализован простой LinkedHashMap, которая позволяет простой итерации в первоначальном порядке.

+0

Значит, вы хотите создать собственный TreeSet, который реализует Comparator >? Это будет «сортировать» объекты «Карта» , но как бы сортировать их содержимое? – PNS

+0

@PNS После прочтения вашего описания во второй раз, я не уверен, если я пойму это правильно. Вы читаете такие типы, как String, Boolean, Integer из файла. Позже вы говорите о столбцах в комбинации записей. Примитивы не имеют такого, поэтому я предположил, что запись переведет на один из тех Карт, о котором вы говорите, так как keys = columns. Но, возможно, вы можете сначала прокомментировать это, чтобы прояснить это? – Omnaest

+0

Вы почти правы. Запись - это объединение всех карт, причем именами столбцов являются имена столбцов. – PNS

2

Один soln должен содержать обе категории на основе HashMap и комбинированные TreeMap. Это потребует немного большего объема памяти, но не так много, поскольку вы просто сохраните одну и ту же ссылку в обоих из них.

Так что всякий раз, когда вы добавляете/удаляете до HashMap, вы будете делать ту же операцию в TreeMap тоже. Таким образом, оба будут всегда синхронизироваться.

Вы можете использовать TreeMap для сравнения, хотите ли вы сравнить тип объекта или фактическое сравнение контента.

Смежные вопросы