GORM составной ключ на основе даты начала и окончания - PullRequest
0 голосов
/ 03 ноября 2011

Я хочу иметь таблицу, в которой я хочу иметь записи, которые ранжированы по дате.Как я обычно это делал, было иметь таблицу с: someId [не уникально] startDate endDate

Эти три создали бы первичный ключ + я бы добавил несколько ограничений, чтобы убедиться, что даты не перекрываются и т. Д.

Все хорошо с точки зрения базы данных, однако, когда я хочу создать класс домена в Grails для обработки ... ну, это сложнее, чем я думал.Есть ли способ, чтобы убедиться, что если у меня есть отношение: ClassA hasOne ClassB [ClassB будет ранжироваться по дате] и у меня есть записи в ClassB:

Id  StartDate  EndDate     Name
1   2011-11-01 2011-11-05  A
1   2011-11-06 2011-11-10  B

и назначить объект B с именем A для объекта A на2011-11-03, а затем получить объект A 2011-11-07 он будет указывать на объект B с именем B?

Ответы [ 2 ]

0 голосов
/ 18 февраля 2012

В итоге мы сделали: создали индекс и ограничение для трех столбцов [в базе данных, поскольку создание индексов в Grails 1.3.7 нарушено, а обработка ограничений безумна], созданы статические startDate и endDateпеременные, которые содержат дату начала и окончания текущего диапазона.Таким образом, мы смогли сохранить желаемую функциональность, и она работает очень хорошо.

0 голосов
/ 04 ноября 2011

Это похоже на плохой способ проектирования вашей базы данных. В большинстве случаев вам действительно следует использовать один числовой идентификатор для объектов.

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

class Foo {
    static hasMany = [bars:Bar]
    static mapping = {
        bars lazy:false
    }
    ...
}

class Bar {
    static belongsTo = [foo:Foo]
    Date startDate
    Date endDate
    ...
}

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

...