Дизайн модели данных ядра - Атрибуты против объектов

Question

Я разрабатываю приложение для базовых базовых данных уже более года (Toy Collector, http://bit.ly/tocapp), и я смотрю на то, чтобы сделать редизайн, чтобы я мог построить iCloud поддержка. Я подумал, что, когда я это делаю, я мог бы также обновить мою базовую модель данных (если необходимо), и у меня есть время отслеживания «лучших практик» для следующего:

В настоящее время я есть 2 сущности:

игрушки, ключевые слова

Игрушка имеет всю информацию об объекте: название, год, Set, ImageName, находящиеся в собственности, Требуются, Производитель, и т.д., (18 атрибутов во всех)

У ключевых слов есть нормализованные слова, чтобы ускорить поиск

Мой вопрос в том, есть ли какое-либо преимущество в том, чтобы разбить некоторые из атрибутов Toy на свои собственные сущности. Например, у меня может быть организация-производитель, которая хранит около дюжины производителей, вместо того, чтобы хранить эту информацию в объекте Toy. Моя кишка говорит мне, что это может уменьшить площадь памяти (вместо 50 000 объектов, хранящих строку производителя, было бы просто 12 строк производителя в объекте с отношением к основному объекту Toy). Действительно ли такая организация имеет значение? Я пытаюсь переусердствовать? Я просто чувствую, что у моей сущности много атрибутов, и я не уверен, что если потратить время, чтобы разбить ее на несколько сущностей, это изменит ситуацию.

Любые советы или указатели будут оценены!

Zack

Answer 1

Ваш вопрос довольно широк, так как он обращается к теме database design. Позвольте мне сказать заранее, что почти невозможно дать вам какие-либо разумные предложения, так как мне нужно будет узнать гораздо больше о вашем приложении, случаях использования и т. Д., Чем это возможно через S.O. вопрос.

Подойдя к вашим конкретным вопросам, я бы сказал, что вы правильно определили одно из преимуществ разбивания таблицы на несколько; Фактически, преимущество этого заключается не только в сокращении базы данных, а в том, чтобы сохранить data redundancy до минимума. Избыточность не только влияет на объем памяти, но также управляемость и изменчивость ваших данных, а отсутствие избыточности может даже вызвать аномалии или коррупцию. Существует даже целая тема теории базы данных, которая известна как database normalisation, которая адресована этому королю проблем.

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

Использование Core Data, который является диспетчером графов реляционных объектов, который часто работает над SQLite, который является реляционным менеджером баз данных, также должен учитывать тот факт, что Core Data автоматически построит ваш граф объектов и выберет память данных, когда вам это нужно. Это означает, что если вы можете считать меньший объем памяти на диске само собой разумеющимся, это может быть не так, когда дело доходит до объема ОЗУ ваших результатов запроса (основные данные будут «взрываться», так сказать, в какой-то момент ваши данные из несколько таблиц в один объект плюс его атрибуты).

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

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

EDIT:

Если вы хотите, чтобы исследовать производительность данных ядра и попытаться понять, где узкие места, дать попробовать на инструмент Инструменты/Основные данные (меню Product/Profile). Есть много вещей, которые могут пойти плохо.

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

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

Также верно, что в зависимости от того, как вы его используете, данные ядра не могут быть лучшим способом обработки ваших данных. Посмотрите на это Brent Simmons' post relating his experience.