Какую коллекцию я должен использовать?

Question

У меня есть около 10 000 записей. Каждая запись имеет 2 поля: одно поле содержит строку длиной до 300 символов, а другое поле - десятичное. Это похоже на каталог продуктов с названиями продуктов и ценой каждого продукта.

Что мне нужно сделать, это позволить пользователю вводить любое слово и отображать все продукты, содержащие это слово, вместе со своими ценами в списке. Это все.

1. Какой тип коллекции подходит для этого сценария?
2. Если мне нужно сортировать, исходя из названия или цены продукта, будет ли выбор по-прежнему оставаться таким же?

В настоящее время я использую XML-файл, но я думал, что использовать коллекцию, чтобы я мог вставлять все значения в код, проще. Спасибо за ваши предложения.

Answer 1

Словарь выполнит эту работу. Однако, если вы выполняете быстрые частичные совпадения (например, поиск по типам пользователей), вы можете получить лучшую производительность, создав несколько ключей, которые указывают на один и тот же элемент. Например, слово «Apple» может быть расположено с «Ap», «App», «Appl» и «Apple».

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

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

Следует также отметить, что при строительстве и классификации предметов 10K не следует затягивать, если все сделано правильно (пара сотен миллисекунд разумна). Результаты можно кэшировать до тех пор, пока вы хотите использовать Application, Cache или статические элементы.

Подводя итог, результирующая структура представляет собой Dictionary<string, List<T>>, где строка короткая (2-6 символов хорошо работает), но уникальный ключ. Каждый ключ указывает на List<T> (или другую коллекцию, если вы так склонны) предметов, которые соответствуют этому ключу. Когда поиск выполняется, вы найдете ключ, который соответствует термину, предоставленному пользователем. В зависимости от длины ваших ключей вы можете усекать поиск пользователя до максимальной длины ключа. После определения правильной дочерней коллекции вы затем просматриваете эту коллекцию для полного или частичного совпадения, используя любую методику, которую вы хотите.

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

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

Вышеупомянутые структуры должны обеспечивать функциональность, примерно эквивалентную trie.

Answer 2

10K записей не так много.

Dictionary<string,decimal> подходит для законопроекта. Вы можете сортировать по ключу или по значению с помощью LINQ, а также выполнять поиск.

Это предполагает, что названия продуктов уникальны.