Карта Groovy и отношения таблиц в классах доменов. Как это описать и сохранить? - PullRequest
Новая
       3

Карта Groovy и отношения таблиц в классах доменов. Как это описать и сохранить?

0 голосов
/ 10 января 2011

В Grails / Gorm я храню физический сайт , в котором содержит объекты в определенных позициях .

Класс домена будет просто:

ПРИМЕР A

САЙТ DC

  • имя_сайт
  • позиционная карта (1: собака, 2: кошка, 3: фу, 4: бар, ... в среднем до 30 элементов)

... но объекты меняют свои позиции, и мне необходимо позже увидеть, какие позиции были заняты ЧТО в данный момент (КОГДА).

Таким образом, я добавил еще один класс домена

ПРИМЕР B

ПОЗИЦИИ DC

  • validfrom
  • validto
  • позиционная карта (1: собака, 2: кошка, 3: фу, 4: бар)
  • принадлежит САЙТ

САЙТ DC

Поскольку все объекты будут иметь описание И будет множество сайтов, использующих одни и те же объекты, я добавил класс домена для хранения каждого ОБЪЕКТА. Результат:

ПРИМЕР С

OBJECT DC

  • имя
  • описание

ПОЗИЦИИ DC

  • validfrom
  • validto
  • карта местоположения (1: reference_to_dog, 2: reference_to_cat, 3: reference_to_foo, 4: reference_to_bar)
  • принадлежит САЙТ

САЙТ DC

  • имя_сайт

Теперь мне карта больше не кажется разумной.

Я думаю об удалении карты, замене ее еще одним классом домена:

ПРИМЕР D

OBJECT DC

  • имя
  • описание

ОБЪЕКТ-ПОЛОЖЕНИЕ ПОСТОЯННОГО ТОКА

  • номер позиции (1, 2, 3, 4, ...)
  • объект (reference_to_cat, reference_to_dog, reference_to_foo, ...)
  • принадлежит ПОЗИЦИИ

ПОЗИЦИИ DC

  • validfrom
  • validto
  • принадлежит САЙТ

САЙТ DC

  • имя_сайт

ВОПРОСЫ

  1. Это хорошая / плохая идея - помещать карты в базу данных?
  2. Как это можно сделать проще?
  3. Какой самый эффективный способ сделать это?

РЕДАКТИРОВАТЬ: НОВЫЙ ПОДХОД НА ОСНОВЕ ОТВЕТОВ ROBS

Вдохновленный вашим предложением, Роб, я разработал эту модель данных, которая предоставляет роль "переднего ряда" для "SeasonPlan" (исправленная "ResidenceHistory"). 

class Zoo {
    static hasMany = [seasons: SeasonPlan]
    String name
}

// one way of representing histories
class SeasonPlan = {
    static belongsTo = [zoo: Zoo] // a SeasonPlan belongs to a single particular Zoo
    static hasMany = [cages: Cage]
    DateTime from
    DateTime until
}

class Cage {
    static belongsTo = [seasonPlan: SeasonPlan] // a cage belongs to a single seasonplan
    Species species // a cage has a single Species
    Integer cageNumber
}

class Species {
    // static hasMany = [cages: Cage] // commented out - no reverse-lookup necessary
    String name
}

У этого есть один недостаток: для каждого сезонного плана есть новая клетка - хотя на самом деле клетки остаются прежними ! (Вообразите «Integer squareMeters» внутри «Клетки», чтобы было более очевидно, почему это нежелательно.)

Для меня применение такой вещи к модели данных часто трудно понять - как мне вписать в приложение "псевдостатические" данные, подобные этой, при сохранении реальной корреляции?

Я надеюсь, что я имею в виду, понятно - извините, если нет.

1 Ответ

4 голосов
/ 10 января 2011

Я все еще пытаюсь понять ваш домен;Вы можете немного усложнять вещи.Будет ли эта базовая модель работать?Если нет, можете ли вы объяснить, почему?Я обновлю свой пример, если смогу лучше понять ваши условия.

Редактировать - обновленный пример с учетом комментариев ниже. 

class Cage {
    static belongsTo = [zoo: Zoo] // a cage belongs to a single particular Zoo
    Species species // a cage has a single Species
    String name
}

class Zoo {
    static hasMany = [cages: Cage]
    String name
}

class Species {
    static hasMany = [cages: Cage] // a species can be in many different cages
    String name
}

// one way of representing histories
class ResidenceHistory = {
    Species species
    Cage cage
    DateTime from
    DateTime until
}

Вот как вы можете использоватьдомен, то: 

def sanDiego = new Zoo(name: 'San Diego Zoo').save()
def aviary = new Cage(name: 'Aviary', zoo: sanDiego).save()
def elephantCage = new Cage(name: 'Elephant Area, Cage 5', zoo: sanDiego).save()

def bird = new Species(name: 'Blue-Footed Booby', cage: aviary).save()
def elephant = new Species(name: 'Asian Elephant', cage: elephantCage).save()

new ResidenceHistory(species: bird, cage: aviary, from: new DateTime(), to: new DateTime().plusDays(20)).save()

Чтобы конкретно ответить на перечисленные вами вопросы:

  1. Это зависит - обычно я предпочел бы использовать реляционные возможности базы данных вместо хранения карт в базе данных.Работать с необработанными данными намного проще, если они не являются сериализованными объектами Java.
  2. См. Мой пример выше.
  3. Это не должно иметь значения, если производительность не становится проблемой.Используйте наиболее разумное и простое в обслуживании решение, и, если вы обнаружите, что оно вызывает проблемы с производительностью, профилируйте свое приложение и устраните проблемы индивидуально.
...