Question

In Grails/Gorm I am storing a physical site which holds objects at defined positions.

The domain class would simply be:

EXAMPLE A

SITE DC

• sitename
• positionmap (1: dog, 2: cat, 3:foo, 4:bar, … up to an average of 30 items)

… but the objects change their positions and I need to later be able to see WHICH positions were occupied by WHAT at a given time (WHEN).

Thus I added another domain class

EXAMPLE B

POSITIONS DC

• validfrom
• validto
• positionmap (1: dog, 2: cat, 3:foo, 4:bar)
• belongsTo SITE

SITE DC

• sitename

As all the objects will have a description AND there will be loads of SITEs using the same objects in it, I added a domain class to hold each and every OBJECT. Result:

EXAMPLE C

OBJECT DC

• name
• description

POSITIONS DC

• validfrom
• validto
• positionmap (1: reference_to_dog, 2: reference_to_cat, 3:reference_to_foo, 4:reference_to_bar)
• belongsTo SITE

SITE DC

• sitename

Now the Map, to me, doesn’t seem reasonable anymore.

I am thinking about removing the map, replacing it by yet another domain class:

EXAMPLE D

OBJECT DC

• name
• description

OBJECT-TO-POSITION DC

• positionnumber (1, 2, 3, 4, …)
• object (reference_to_cat, reference_to_dog, reference_to_foo, …)
• belongsTo POSITIONS

POSITIONS DC

• validfrom
• validto
• belongsTo SITE

SITE DC

• sitename

QUESTIONS

1. Is it generally a good/bad idea to put maps into the database?
2. How could this be achieved easier?
3. What’s the most performant way to do it?

EDIT: A NEW APPROCH BASED ON ROBS ANSWER

Inspired by your suggestion, Rob, I drafted this data model which grants a “front-row” role to the “SeasonPlan” (amended “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
}

This has one drawback: For every season plan there’s a new cage – though in reality the cages stay the same! (Imagine a “Integer squareMeters” within the “Cage” to make it more obvious why this isn’t desired.)

For me applying such a thing to a data model is often hard to comprehend – how do I fit “pseudo-static” data like this into the application while retaining real-world corelation?

I hope what I mean is understandable – sorry if not.

Answer 1

I’m still trying to understand your domain; you may be overcomplicating things a bit. Would this basic model work? If not, can you explain why? I’ll update my example if I can better understand your conditions.

Edit – updated example given the comments below.

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
}

Here’s how you might use the domain, then:

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()

To answer your listed questions specifically:

1. It depends – usually I’d prefer using the database’s relational capabilities instead of storing maps in the database. It’s much easier to work with the raw data if they aren’t serialized Java objects.
2. See my example above.
3. This shouldn’t matter unless performance becomes an issue. Use the solution that makes the most sense and is the easiest to maintain, and if you find that it causes performance problems, profile your application and fix the problems individually.