Penso che quello che stai cercando a livello concettuale SQL sia una tabella di giunzioni (mappa, link, resolver, pivot sono anche nomi comuni per la gestione di molte e molte relazioni). Queste tabelle di giunzione sono generalmente tabelle intermedie; tuttavia, gli attributi aggiuntivi possono e sono spesso aggiunti a loro.

L'intenzione dello pseudo schema dichiarato è un po 'torbida, ma penso che quello che intendevi è che gli oggetti possono richiedere più abilità; gli oggetti possono anche richiedere altri oggetti, ciascuno con le proprie abilità richieste, possibilmente possedere elementi necessari, e così via, a molti livelli in profondità. Fai attenzione ai riferimenti circolari nelle tue [molte-a-molte] relazioni autoreferenziali, come ciò che potrebbe accadere in "containerItemMaps". Il seguente pseudo-schema riflette come immagino l'intento dell'OP:

items (itemId PK, itemName, weight, volume, price)

skillMaps ( (itemId, skillId) PK)

skills (skillId PK, skillName)

containerItemMaps ( (containerItemId, componentItemId) PK)
    -- containerItemId is the parent/requiring item id
    -- componentItemId is the child/required item id

La terminologia ActiveRecord suggerisce "has_and_belongs_to_many" come tipo di associazione una relazione in un modello di dati da utilizzare in questa situazione. Per maggiori informazioni si consiglia di consultare la pagina all'indirizzo datamapper.org Associations . In particolare le sezioni intitolate "Ha e appartiene a molti (o molti a molti)" e "Rapporti auto-referenziali da molte a molte"

Perché non sono un rubino a questo punto, posso solo confondere con il codice rubino per dare un esempio, ma questa è la mia migliore approssimazione di come dovrebbe essere la tua classe di articoli:

# revised
class Item
   include DataMapper::Resource

   property :id, Serial

   property :name, String, :required => true
   property :weight, Float
   property :volume, Float
   property :price, Float 

   has n, :componentMaps, :child_key => [:container_id]
   has n, :components, self, :through => :componentMaps, :via => :component

   has n, :skillMaps, :child_key => [:skill_id]
   has n, :skills, :through => :skillMaps, :via => :skill    
end

E la tabella delle mappe per auto-referenziare molti elementi, ad esempio .. elementi richiesti:

#revised
class ComponentMap
  include DataMapper::Resource

  belongs_to :container, 'Item', :key => true
  belongs_to :component, 'Item', :key => true

  property :quantity, Integer, :default => 1
end

Per completezza:

class SkillMap
  include DataMapper::Resource

  belongs_to :item, 'Item', :key => true
  belongs_to :skill, 'Skill', :key => true

  property :mastery, Enum[:none, :aprentice, :journeyman, :craftsman, :master ], :default => :none

end

class Skill
    include DataMapper::Resource

    property :id, Serial
    property :name, String, :required => true

    has n, :skillMap, :child_key =>[:skill_id]     
end

Revisioni:

Notando le tue preoccupazioni, sono andato e ho installato un interprete e un debugger per verificare il codice compilato e lo sql emesso era più ideale. Inizialmente, stavo solo uscendo dall'esame sommario della documentazione. Le strutture di cui sopra dovrebbero produrre sql generalmente ben strutturati dalle mappature.

Indipendentemente dai campi e dalle strutture che usi, e indipendentemente dall'ORM che scegli (datamapper o qualche altro provider), dovrai eseguire il codice attraverso il debugger e prestare attenzione al sql che emette quando a volte i mapping non sono è necessariamente quello che potreste prima aspettarvi.

Una seconda nota sulle tabelle di giuntura (skillMap e componentMap): nota la mia inclusione di campi aggiuntivi (quantità e padronanza). Questi sembrano essere perfettamente adatti al tipo di applicazione originariamente descritta, anche se non originariamente specificata. In una ricetta, alcuni ingredienti sono comuni tra molte combinazioni diverse, tuttavia la quantità da ricetta a ricetta varia. Per le abilità, come gli ingredienti, il livello di abilità necessario per eseguire determinate attività varia, e quindi ho aggiunto un campo di padronanza alla tabella di abilità skillMap.

Ovviamente, probabilmente vorrai aggiungere regole di business e funzioni helper appropriate (per accedere alla composizione delle raccolte in modo programmatico come aggiungere e rimuovere elementi, aggiungere e rimuovere gruppi di elementi e così via).

Speriamo che questo dimostri un po 'meglio una ragione per cui potresti voler considerare e usare la tabella di giunzione su un hash lineare. Naturalmente ogni specifica applicazione è diversa, e forse nel tuo caso non è necessaria la capacità di specificare ulteriori aspetti della relazione tra oggetti e abilità e oggetti e altri elementi.

Avere e utilizzare il controllo extra nella definizione esplicita delle relazioni presenta molti vantaggi rispetto a fare affidamento su una mappatura dinamica / magica. In alcuni casi, sento che è davvero necessario, e penso che nel caso di molti a molti, questo è dimostrato. Per uno-a-molti, la relazione è più facile da dedurre e l'utilizzo di un metodo più dinamico di generazione dei mapping (ad esempio has n,: < attributo group & gt ;,: through = > Resource) sarebbe accettabile.