Как мне обработать отношения ManyToMany в JSON? - PullRequest
4 голосов
/ 01 июня 2011

Это дополнительный вопрос к моему предыдущему вопросу " Управление контрактами сотрудников в отношениях" многие ко многим? "И этот вопрос

У меня есть отношения, которые можно объяснить так:

company --< contracts >-- employees

Я импортирую данные через JSON. Для простоты это показано ниже.

{
  "companies" : [
    {
      "name" : "Company A",
      "employees" : [
        {
          "name" : "Tom",
          "contract" : {
            "length" : "10",
            "salary" : "10000"
          }
        }
      ]
    }
  ]
}

Проблема в том, что я не уверен, правильно ли это.

В моих модельных отношениях contract находится между company и employees, тогда как в моем приведенном выше коде я обозначил его как объект, а он как ребенок под сотрудниками.

Следовательно, мой вопрос: где должна находиться распределительная таблица в канале JSON?

Должен ли он сидеть в качестве родителя для сотрудников, или это нормально, где он находится?

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

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

Спасибо.

Редактировать.

Цель / Context

Я пытаюсь прочитать в JSON данные Core, используя TouchJSON. Извиняюсь за не разъяснение контекста ранее. Обновлены теги.

Я прочитал JSON в NSDictionary. Если я начну отделять объекты, я не уверен, как заставить TouchJSON / iOS понимать контекст каждого отношения, когда дело доходит до анализа / чтения данных в память.

Ответы [ 2 ]

2 голосов
/ 02 июня 2011

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

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

{
  "companies" : [
    {
      "id" : 1,
      "name" : "Company A"
    }
  ],

  "employees" : [
    {
      "id" : 1,
      "name" : "Fred"
    }
  ],

  "contracts" : [
    {
      "id" : 123,
      "company_id" : 1,
      "employee_id": 1
      "length" : 10,
      "salary" : 10000
    }
  ]
}

(Кроме того, числовые значения действительны в JSON, их не нужно заключать в кавычки)

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

1 голос
/ 02 июня 2011

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

Однако нет никакой причины, по которой ваша объектная модель должна испытывать ограничения, налагаемыереляционная база данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...