Memorizzazione di un modello gerarchico in un database

3

Se questo titolo è ambiguo, sentitevi liberi di cambiarlo, non so come inserirlo in un foglio singolo.

Esempio:
Supponiamo che tu abbia un modello html che contiene alcuni tag personalizzati, come <text_field /> . Ora creiamo una pagina basata su un modello che contiene più di questi tag personalizzati. Quando un utente vuole modificare la pagina, vede un campo di testo. può inserire le cose e salvarle.

Sembra abbastanza facile da configurare. O hai qualcosa come una tabella template_positions che memorizza il contenuto di quei campi.

Caso:
Ora ho un po 'di blocco mantenendo le cose il più semplice possibile. Supponiamo che tu abbia lo stesso tag indicato nel tuo esempio e in aggiunta, <layout> e <repeat> tag. Ecco un esempio di come dovrebbero essere usati:

<repeat>
  <layout name="image-left">
    <image /> <text_field />
  </layout>

  <layout name="image-right">
    <text_field /> <image />
  </layout>
</repeat>

Ora abbiamo un blocco che può essere ripetuto, ovviamente. Ciò significa: quando creo / modificando una pagina contenente un blocco di template, posso scegliere tra un layout image-left e image-right che poi viene inserito come elemento di contenuto (dove il contenuto per <image /> e <text_field /> viene memorizzato). E poiché questo è all'interno di un <repeat> , gli elementi di contenuto dei layout specificati possono essere inseriti più volte.

Come lo memorizzi? Detto semplicemente, questo potrebbe essere memorizzato con la stessa configurazione che ho scritto nell'esempio sopra, ho solo bisogno di aggiungere un parent_id o qualcosa di simile per mantenere una gerarchia. ma penso che mi manchi qualcosa. Almeno manca la relazione tra un elemento di contenuto inserito e il punto di origine / inserimento. E cosa succede quando aggiorno il file modello?

Devo dare a ogni tag personalizzato che agisce come parte modificabile di un modello un identificatore che corrisponde a un identificatore nel modello per sostituirli correttamente?

Oppure puoi pensare a una soluzione pulita che potrebbe essere migliore?

    
posta pduersteler 16.08.2011 - 20:02
fonte

3 risposte

0

Prima di tutto, grazie per tutte le tue risposte. È ancora più bello qui che su StackOverflow perché le risposte hanno più dettagli in generale e possono essere discusse meglio.

Ora ho trovato una soluzione più o meno solida per questo (più o meno perché sto ancora sperimentando) che ho avuto per sbaglio durante il debug di alcuni css.

La mia soluzione attuale: utilizzo una libreria che la divide internamente in un elenco di nodi gerarchici e restituisce quell'elenco come oggetto. Su questo oggetto, posso attraversare e selezionare i nodi con un selettore css e anche aggiornarli o sostituirli.

Usando xpath, non ho bisogno di memorizzare i dati gerarchici per i campi di base. Ci sono solo due campi nella mia tabella, xpath e sostituzione. Quindi, il rendering del modello ricorsivo consente anche di annidare le cose senza che i dati gerarchici siano archiviati in mysql, poiché vengono risolti tramite xpath. Avevo solo bisogno di aggiungere un'altra tabella e un campo per il percorso di ripetizione / layout, ma questo fondamentalmente si risolve anche tramite xpath.

(Questo è fuori dal mio cervello perché il progetto di cui ho bisogno è attualmente in pausa e, poiché ho trovato una soluzione, volevo condividerlo).

    
risposta data 18.01.2012 - 09:25
fonte
3

per il tuo riferimento puoi vedere l'implementazione di Active Directory è praticamente la stessa cosa. ma preferirei che tu debba usare un database gerarchico per questo scopo.

il tuo problema ha una soluzione nel database No-SQL . ci sono molti database con lo schema key value store sotto l'ombrello no-SQL. I database relazionali non sono progettati per questo scopo anche se puoi utilizzarli con le relazioni figlio genitore , l'inserimento è soddisfacente, ma dovremo affrontare difficoltà mentre recupero dei dati .

se non ci sono restrizioni sulla modifica del database devi andare con quello. ma se non si dispone di un'opzione diversa dal DB SQL come si sarebbe potuto utilizzare SQL per scopi relazionali, sarebbe ingombrante avere una base DB separata solo per questo scopo.

ma ancora una volta non utilizzare il DB SQL per questo scopo.

    
risposta data 28.12.2011 - 09:46
fonte
1

Sembra che molte persone siano come me, hanno difficoltà a capire quello che vuoi. Ma cercherò di espormi, forse potrò sbloccare il tuo post ...

Penso di capire perché consideri la creazione di molti id e il collegamento dei tuoi elementi con loro.

L'archiviazione di una gerarchia in un database relazionale non è facile :

  • se si utilizza solo una tabella, non esiste un metodo SQL standard per ottenere tutti i dati (ma per il database specifico sono disponibili soluzioni non portatili)
  • potresti usare diverse tabelle per i vari livelli, ma sarebbe rigida e non ricorsiva

Forse il modo più semplice sarebbe quello di memorizzare la tua gerarchia come un file (sul tuo file system o nel tuo database). Un file naturalmente può contenere informazioni gerarchiche e puoi analizzare in una struttura di memoria gerarchica, quindi nessun problema (a meno che non sia necessario interrogare le relazioni tra gli elementi).

Il tuo formato file è xml standard, quindi hai molti strumenti disponibili.

    
risposta data 29.08.2011 - 23:27
fonte

Leggi altre domande sui tag