Является ли этот шаблон подходящим для Core Data?

Question

Единственными базами данных, с которыми я работал ранее, являются MySQL, поэтому дизайн базы данных CoreData меня немного сбивает с толку.

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

В этом упрощенном дизайне, есть 3 таблицы:

PERSON  BUSINESS  OWNED BUSINESS 
------  --------  -------------- 
id   id   personID 
name   name   businessID 
email  website  acquisitionDate 

Таблица OwnedBusiness является тот, который меня смущает. В MySQL эта таблица используется для поддержки отношений «многие ко многим». Я понимаю, что CoreData не требует этого, однако у меня есть дополнительное поле в OwnedBusiness: acquisitionDate.

---

дополнительное поле, acquisitionDate гарантирует ли использование дополнительного объекта/таблицы? Если нет, то где это поле?

Answer 1

Во-первых, Core Data - это не база данных, полная остановка.

Основные данные - это структура управления графиком объектов, ваша модель в вашем приложении.

Это может упорствовать на диске в базе данных. Он также может сохраняться как двоичный, XML и почти все. Он даже не нужен для сохранения.

Подумайте о Core Data как о объектном графе. В вашем примере у вас будет объект Person, объект Business и объект OwnedBusiness.

Объект OwnedBusiness имеет две связи и одно свойство. Вы не будете управлять внешними ключами, потому что Core Data обрабатывает , если вы в конечном итоге сохраняетесь в базе данных. В противном случае это указатели объектов.

Answer 2

Так что, прежде всего, CoreData не является реляционным db, просто чтобы это исключить.

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

Отношения many-to-many, CoreData поддерживают эти отношения без дополнительных таблиц. Также отношения не основаны на id с, они основаны непосредственно на объектах.

Так что в вашем случае, вы не должны использовать лицо id & бизнес id создать отношения, вы можете создать отношения в Relationship разделе вашего xcdatamodel, то вы можете установить класс отношений (или назначение), обратная к этой взаимосвязи (полезная вещь) и, конечно, тип отношения (to-many to to one).

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