Подделывать динамическую схему в Core Data?

Question

Из чтения Apple Docs по основным данным я понял, что не следует использовать базовые данные, когда вам нужна динамическая схема. Если бы я хотел предоставить пользователю возможность создавать свои собственные свойства, в базовой модели данных это сработало бы, если бы я создал несколько «фиктивных» атрибутов, таких как «пользовательское десятичное число 1», «пользовательское десятичное число 2», «пользовательский текст 1», «Пользовательский текст 2» и т. д., что пользователь может назвать и использовать в своих целях?

Очевидно, что это не будет работать для отношений, но для простых свойств это кажется разумным решением. Заметит ли создание на моих объектах несколько фиктивных атрибутов, которые не используются большинством пользователей, заметно снизит производительность для них? Кто-нибудь из вас пробовал что-то подобное? Спасибо!

Answer 1

Сначала посмотрите документы по основным данным о связях . Используя ваш пример, рассмотрим что-то вроде:

1. Сущность CarAttributeType с именем, например "вес в фунтах"
2. Сущность CarAttribute со значением, например 2765.
3. Объект Car с указанными вами необходимыми значениями (такими как "color", "make" и т. Д.)

Затем, между CarAttribute и CarAttributeType есть отношение «многие к одному» (многие CarAttribute могут иметь один и тот же тип), отношение «один ко многим» между Car и CarAttribute (каждая машина может иметь много атрибутов). Это решение немного сложнее в настройке, чем жестко запрограммированные поля NULL. Однако он избегает повторяющихся групп и, как мы надеемся, более удобен в обслуживании.

РЕДАКТИРОВАТЬ: Да, я пропустил это. Я думаю, что вы хотели бы StringCarAttribute, StringCarAttributeType, FloatCarAttribute, FloatCarAttributeType и т. Д. Затем, иметь много-к-одному между StringCarAttribute и StringCarAttributeType и т. Д. Автомобиль будет иметь один-к-другому с StratCarteCatCarteCarteCarCar Причина для сущностей с несколькими типами заключается в том, что у вас нет StringCarAttribute и FloatCarAttribute, оба заявляют, что используют один тип атрибута weight.

Наличие одного CarAttribute со всеми типами идет против 1NF # 4.

Answer 2

Один из вариантов: KSExtensibleManagedObject .Вставьте бит динамической схемы в расширяемые свойства.

Answer 3

Это будет работать, это будет просто ужасно. Подумайте об использовании плоского стола в базе данных, потому что это именно то, что вы будете делать. Вместо этого попробуйте создать схему, которая может описать схему так, чтобы ваше приложение могло ее понять. Тем не менее, все равно будет задействован значительный код, хотя, если все сделано правильно, вы можете имитировать столько же, сколько база данных SQL. Конечно, основные данные построены на основе SQL (или других типов хранилищ, но это не моя точка зрения), но в основном вы создадите слой, который будет имитировать что-то на два уровня ниже, что будет просто глупо.