Дизайн модели основных данных - поиск по отношению к отношениям?

Question

Я знаком с базовыми базовыми данными и проделал некоторые работы, но на самом деле не сделал каких-либо крупных приложений. Теперь мне нужно планировать это. И вопрос не в основном о Core Data, а о дизайне данных в целом, хотя я собираюсь использовать Core Data для его реализации на iPhone, что важно для рассмотрения производительности.

Представьте, что я делаю приложение электронной почты, где электронные письма являются основным объектом. Мне нужно предоставить несколько просмотров в хранилище электронной почты: поиск по пользователю, а также многие другие критерии: скажем, «все электронные письма с более чем двумя получателями», «все письма, в которых тема длиннее X», «все письма, содержащие слово X »и т. д.

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

Таким образом, чтобы делать такие вещи, как «письма с> 2 получателей» и «электронные письма, где субъект более чем X», я думаю, что у меня есть две стратегии:

1) модель их как специальный «поиск» объекта , и создавать отношения «многие-ко-многим» между сообщениями электронной почты и объектами поиска при вставке новых объектов в хранилище, так что это простой запрос соединения при поиске;

2) не моделируйте ничего за пределами основного объекта электронной почты и просто выполняйте поиск с предикатами из хранилища во время выполнения.

Мой вопрос:

на основе ваших инстинктов Core Data, насколько велика разница между этими двумя стратегиями с точки зрения производительности? Моя кишка говорит мне, что №1 всегда будет быстрее, но если это 10%, я готов принять удар производительности, чтобы быть более гибким с # 2. Но если # 2 будет на 200% медленнее, мне нужно больше работать над моделированием объекта поиска и, по сути, предварительно генерировать все результаты поиска.

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

Answer 1

Как правило, я бы рекомендовал идти со стратегией два и только тратить время на изучение и разработку других методов, если вы на самом деле сталкиваетесь с проблемами производительности во время тестирования. Core Data часто быстрее, чем люди думают, особенно на iPhone.

Однако, если вы в состоянии определить все возможные варианты досрочно, это дает вам преимущество. Похоже, что когда создается электронное письмо, вы проверите его и добавьте его ко всем соответствующим «поисковым» объектам. Мое чувство кишки заключается в том, что стратегия будет значительно быстрее, особенно в десятках тысяч почтовых объектов.