Modellazione dei dati - Modello di David Nuescheler data-modeling-david-nuescheler-s-model

CAUTION
AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.

Sorgente source

I seguenti dettagli sono idee e commenti espressi da David Nuescheler.

David è stato co-fondatore e CTO of Day Software AG, uno dei principali fornitori di software per la gestione dei contenuti e l'infrastruttura dei contenuti globali, richiesto dall'Adobe nel 2010. È ora compagno e vicepresidente di Enterprise Technology all'Adobe e guida anche lo sviluppo di JSR-170, l'interfaccia API (Application Programming Interface) Java Content Repository, lo standard tecnologico per la gestione dei contenuti.

Ulteriori aggiornamenti sono disponibili su https://wiki.apache.org/jackrabbit/DavidsModel.

Introduzione da David introduction-from-david

In varie discussioni ho scoperto che gli sviluppatori sono in qualche modo a disagio con le funzioni e le funzionalità presentate da JCR per quanto riguarda la modellazione dei contenuti. Non esiste ancora una guida e poca esperienza su come modellare i contenuti in un archivio e sul perché un modello di contenuto è migliore dell’altro.

Mentre nel mondo relazionale l'industria del software ha molta esperienza su come modellare i dati, siamo ancora alle prime fasi per lo spazio dell'archivio dei contenuti.

Vorrei iniziare a riempire questo vuoto esprimendo le mie opinioni personali sul modo in cui i contenuti dovrebbero essere modellati, sperando che questo possa un giorno diventare qualcosa di più significativo per la comunità degli sviluppatori, che non è solo "la mia opinione", ma qualcosa di più generale applicabile. Considerate questo il mio primo bersaglio veloce ed evoluto.

NOTE
Disclaimer: Queste linee guida esprimono le mie opinioni personali, talvolta controverse. Sono ansioso di discutere questi orientamenti e di perfezionarli.

Sette semplici regole seven-simple-rules

Regola n. 1: Prima i dati, poi la struttura. Forse. rule-data-first-structure-later-maybe

Spiegazione explanation-1

Consiglio di non preoccuparsi di una struttura dati dichiarata in senso ERD. Inizialmente.

Impara ad amare nt:unstructured (& Friends) nello sviluppo.

Credo che Stefano lo riassuma più o meno.

La mia linea di fondo: La struttura è costosa e in molti casi non è assolutamente necessario dichiarare esplicitamente la struttura allo stoccaggio sottostante.

Esiste un contratto implicito sulla struttura che l'applicazione utilizza in modo intrinseco. Supponiamo di memorizzare la data di modifica di un post di blog in una proprietà lastModified . La mia app saprà automaticamente leggere di nuovo la data di modifica da quella stessa proprietà, non c'è davvero bisogno di dichiararlo esplicitamente.

Ulteriori vincoli relativi ai dati, come vincoli obbligatori o di tipo e di valore, dovrebbero essere applicati solo se richiesto per motivi di integrità dei dati.

Esempio example-1

L’esempio precedente di utilizzo di un lastModified La proprietà Date, ad esempio il nodo "post di blog", non significa in realtà che ci sia bisogno di un tipo di nodo speciale. Io userei sicuramente nt:unstructured almeno inizialmente per i nodi del post del mio blog. Dal momento che nella mia applicazione di blog tutto ciò che farò è mostrare la data dell'ultima modifica comunque (possibilmente "ordine entro") Mi importa a malapena se è un Data affatto. Dato che mi fido implicitamente della mia applicazione di scrittura di blog per mettere lì una "data" comunque, non c'è davvero bisogno di dichiarare la presenza di un lastModified data sotto forma di nodetype a.

Regola n. 2: Guidare la gerarchia dei contenuti, non lasciare che accada. rule-drive-the-content-hierarchy-don-t-let-it-happen

Spiegazione explanation-2

La gerarchia dei contenuti è una risorsa molto preziosa. Quindi non lasciate che accada, progettatela. Se non avete un nome "buono" e leggibile per un nodo, probabilmente è qualcosa che dovreste riconsiderare. I numeri arbitrari non sono mai un "buon nome".

Anche se può essere estremamente facile mettere rapidamente un modello relazionale esistente in un modello gerarchico, si dovrebbe mettere un po 'di pensiero in quel processo.

Nella mia esperienza, se si pensa al controllo degli accessi e al contenimento, di solito sono buoni driver per la gerarchia dei contenuti. Immaginalo come se fosse il tuo file system. Forse anche utilizzare file e cartelle per modellarlo sul disco locale.

Personalmente preferisco le convenzioni gerarchiche rispetto al sistema di digitazione dei nodi in molti casi inizialmente, e introdurrò la digitazione successivamente.

CAUTION
Anche il modo in cui è strutturato un archivio di contenuti può influire sulle prestazioni. Per ottenere prestazioni migliori, il numero di nodi figlio associati a singoli nodi in un archivio di contenuti non deve generalmente superare le 1.000.
Vedi Quanti dati può gestire CRX? per ulteriori informazioni.

Esempio example-2

Vorrei modellare un semplice sistema di blog come segue. Nota che inizialmente non mi interessa nemmeno i rispettivi nodetype che uso a questo punto.

/content/myblog
/content/myblog/posts
/content/myblog/posts/what_i_learned_today
/content/myblog/posts/iphone_shipping

/content/myblog/comments/iphone_shipping/i_like_it_too
/content/myblog/comments/iphone_shipping/i_like_it_too/i_hate_it

Credo che una delle cose che emergono sia che tutti comprendiamo la struttura del contenuto basata sull'esempio senza ulteriori spiegazioni.

Ciò che può essere inaspettato inizialmente è il motivo per cui non avrei conservato i "commenti" con il "post", che è dovuto al controllo dell'accesso che vorrei essere applicato in modo ragionevolmente gerarchico.

Utilizzando il modello di contenuto di cui sopra posso facilmente consentire all'utente "anonimo" di "creare" commenti, ma mantenere l'utente anonimo su una base di sola lettura per il resto dell'area di lavoro.

Regola n. 3: Le aree di lavoro sono per clone(), merge() e update(). rule-workspaces-are-for-clone-merge-and-update

Spiegazione explanation-3

Se non utilizzi clone(), merge() o update() metodi nell'applicazione un'unica area di lavoro è probabilmente la strada da seguire.

"nodi corrispondenti" è un concetto definito nelle specifiche JCR. In sostanza, si riduce a nodi che rappresentano lo stesso contenuto, in diverse cosiddette aree di lavoro.

JCR introduce il concetto molto astratto di Workspace che lascia molti sviluppatori incerti su cosa fare con loro. Vorrei proporre di sottoporre a test l'utilizzo degli spazi di lavoro.

Se si dispone di una notevole sovrapposizione di nodi "corrispondenti" (essenzialmente i nodi con lo stesso UUID) in più aree di lavoro, probabilmente le aree di lavoro vengono utilizzate correttamente.

Se non vi è sovrapposizione di nodi con lo stesso UUID, probabilmente si abusano delle aree di lavoro.

Le aree di lavoro non devono essere utilizzate per il controllo degli accessi. La visibilità del contenuto per un particolare gruppo di utenti non è un buon argomento per separare gli elementi in aree di lavoro diverse. JCR dispone di "Controllo accessi" nell’archivio dei contenuti per fornire questo.

Le aree di lavoro sono il limite per riferimenti e query.

Esempio example-3

Utilizzare le aree di lavoro per elementi quali:

  • v1.2 del progetto rispetto a a v1.3 del progetto
  • uno stato di "sviluppo", "controllo qualità" e di contenuto "pubblicato"

Non utilizzare le aree di lavoro per elementi quali:

  • directory home dell'utente
  • contenuto distinto per diversi tipi di pubblico target come pubblico, privato, locale, …
  • caselle di posta elettronica per utenti diversi

Regola n. 4: Attenzione ai fratelli con lo stesso nome. rule-beware-of-same-name-siblings

Spiegazione explanation-4

Sebbene SNS (Same Name Siblings) sia stato introdotto nella specifica per consentire la compatibilità con le strutture di dati progettate ed espresse tramite XML e che siano quindi estremamente utili per JCR, SNS presenta un notevole sovraccarico e complessità per l’archivio.

Qualsiasi percorso nell’archivio dei contenuti che contiene un SNS in uno dei suoi segmenti di percorso diventa molto meno stabile. Se un SNS viene rimosso o riordinato, ha un impatto sui percorsi di tutti gli altri SNS e dei relativi figli.

Per l’importazione di XML o l’interazione con SNS XML esistenti può essere necessaria e utile, ma non ho mai utilizzato SNS e mai lo farò nei miei modelli di dati "campo verde".

Esempio example-4

Utilizzare

/content/myblog/posts/what_i_learned_today
/content/myblog/posts/iphone_shipping

anziché

/content/blog[1]/post[1]
/content/blog[1]/post[2]

Regola n. 5: Riferimenti considerati dannosi. rule-references-considered-harmful

Spiegazione explanation-5

I riferimenti implicano l'integrità referenziale. Trovo importante comprendere che i riferimenti non si limitano ad aggiungere costi aggiuntivi per l'archivio che gestisce l'integrità referenziale, ma sono anche costosi dal punto di vista della flessibilità dei contenuti.

Personalmente mi accerto di utilizzare sempre solo i riferimenti quando non sono in grado di gestire un riferimento pericoloso e utilizzare in altro modo un percorso, un nome o una stringa UID per fare riferimento a un altro nodo.

Esempio example-5

Supponiamo di consentire "riferimenti" da un documento (a) a un altro documento (b). Se si modella questa relazione utilizzando le proprietà di riferimento, ciò significa che i due documenti sono collegati a livello di archivio. Non è possibile esportare/importare i documenti (a) singolarmente, poiché la destinazione della proprietà di riferimento potrebbe non esistere. Sono interessate anche altre operazioni quali l’unione, l’aggiornamento, il ripristino o il clone.

Quindi, modellerei questi riferimenti come "riferimenti deboli" (in JCR v1.0 questo essenzialmente si riduce alle proprietà della stringa che contengono l'uuid del nodo di destinazione) o semplicemente userei un percorso. A volte il percorso è più significativo per cominciare.

Penso che ci siano casi d'uso in cui un sistema non può davvero funzionare se un riferimento è penzolante, ma non riesco a trovare un buon esempio "reale" ma semplice dalla mia esperienza diretta.

Regola n. 6: I file sono file. rule-files-are-files

Spiegazione explanation-6

Se un modello di contenuto espone qualcosa che anche in remoto profumo come un file o una cartella che cerco di utilizzare (o estendere da) nt:file, nt:folder e nt:resource.

Nella mia esperienza molte applicazioni generiche consentono l'interazione con nt:folder e nt:files implicitamente e sanno come gestire e visualizzare tali eventi se sono arricchiti con metadati aggiuntivi. Ad esempio, un'interazione diretta con le implementazioni del file server come CIFS o WebDAV che si trovano sopra JCR diventa implicita.

Penso che come buona regola del pollice si potrebbe usare quanto segue: Se hai bisogno di memorizzare il nome del file e il tipo di MIME allora nt:file/ nt:resource È un fiammifero molto buono. Se si possono avere più "file" una nt:folder è un buon posto per memorizzarli.

Se devi aggiungere metadati per la risorsa, ad esempio una proprietà "author" o "description", estendi nt:resource non il nt:file. Estendo raramente nt:file e frequentemente nt:resource.

Esempio example-6

Supponiamo che qualcuno voglia caricare un'immagine su un post di blog in:

/content/myblog/posts/iphone_shipping

e forse la reazione istintiva sarebbe aggiungere una proprietà binaria contenente l'immagine.

Anche se ci sono sicuramente buoni casi d'uso per utilizzare solo una proprietà binaria (diciamo che il nome è irrilevante e il mime-type è implicito) in questo caso consiglierei la seguente struttura per il mio esempio di blog.

/content/myblog/posts/iphone_shipping/attachments [nt:folder]
/content/myblog/posts/iphone_shipping/attachments/front.jpg [nt:file]
/content/myblog/posts/iphone_shipping/attachments/front.jpg/jcr:content [nt:resource]

Regola n. 7: Gli ID sono malvagi. rule-ids-are-evil

Spiegazione explanation-7

Nei database relazionali gli ID sono un mezzo necessario per esprimere le relazioni, in modo che le persone tendano ad usarli anche nei modelli di contenuto. Principalmente per le ragioni sbagliate.

Se il modello di contenuto è pieno di proprietà che terminano con "Id", probabilmente non stai sfruttando correttamente la gerarchia.

È vero che alcuni nodi hanno bisogno di un'identificazione stabile durante il loro ciclo di vita. Molto meno di quello che potreste pensare. mix:referenceable fornisce un tale meccanismo integrato nell'archivio, quindi non c'è davvero bisogno di trovare un ulteriore mezzo per identificare un nodo in modo stabile.

Tieni presente anche che gli elementi possono essere identificati dal percorso, e tanto quanto i "symlink" hanno più senso per la maggior parte degli utenti rispetto ai collegamenti rigidi in un filesystem unix, un percorso ha senso per la maggior parte delle applicazioni fare riferimento a un nodo target.

Ancora più importante, è mescolare:referenceable significa che può essere applicata a un nodo nel momento in cui è effettivamente necessario farvi riferimento.

Diciamo quindi che solo perché si desidera essere in grado di fare riferimento potenzialmente a un nodo di tipo "Documento" non significa che il vostro tipo di nodo "Documento" deve estendersi da mix:referenceable in modo statico in quanto può essere aggiunto a qualsiasi istanza del "Documento" dinamicamente.

Esempio example-7

Utilizzare:

/content/myblog/posts/iphone_shipping/attachments/front.jpg

anziché:

[Blog]
-- blogId
-- author
[Post]
-- postId
-- blogId
-- title
-- text
-- date
[Attachment]
-- attachmentId
-- postId
-- filename
+ resource (nt:resource)
recommendation-more-help
2315f3f5-cb4a-4530-9999-30c8319c520e