Database per la memorizzazione di libri raggruppando, le loro pagine e il sommario

Question

Database per la memorizzazione di libri raggruppando, le loro pagine e il sommario

#1 da (3 voti)
#2 da (2 voti)

3

Sto cercando un modo migliore per gestire il design che ho qui, non sono sicuro che sia davvero adatto.

Per dare un po 'di contesto, diciamo che abbiamo un gruppo di gruppi, un gruppo potrebbe essere "SQL" e un altro potrebbe essere "Cucinare".

Il gruppo SQL avrebbe libri come "Normalizzazione" e "T-SQL", mentre la cucina potrebbe avere "Fare pasta" e "La pizza è fantastica".

I libri stessi avranno molte pagine, che potrebbero non finire per essere scolpite nella pietra, devo essere in grado di cambiarle (e questo è davvero un problema con il mio schema già ideato).

Un sommario per Pizza è Fantastico potrebbe essere simile a questo:

1. History
    1. The great pizza revolution of 13901AD
    1. The first pizza
2. Making pizzas
    1. Mental preparation
        1. Think like a gazel
        1. Hunger like a lion
    1. Building the oven
        1. Real pizza is made with flamethrower.
            1. How to make a flamethrower
                1. How to get a permit for your flamethrower
3. Enjoying pizza
4. Credit

Quindi corro e riempio le mie tabelle SQL in questo modo:

Gruppi: pizza, SQL Libri: la pizza è fantastica Pagine: tutte le 13 pagine che ho elencato nell'esempio Table of contents.

Ecco l'intoppo: Indice dei contenuti.

Sotto il mio design esistente, avrei una tabella che assegna a ciascun elemento la sua posizione, quindi "crediti", "cronologia" e altri elementi di primo livello vengono assegnati alla loro posizione con un valore annidato di 0. Elementi come "La fame di un leone" si trova nella posizione 7 del sommario, con un valore annidato di 2 (perché è profondo 2 livelli).

Questo in realtà non fornisce un sacco di esigenze senza una programmazione complessa:

Che cosa succede se volevo spostare le pizze sopra la cronologia? Devo ri-indicizzare l'intera cosa!
E se volessi fare il nido facendo pizze sotto le pizze?
Cosa succede se scrivo una sezione completamente nuova?
Come faccio a garantire che i livelli annidati abbiano senso?

Fondamentalmente devo aggiornare l'intero indice, e il livello "annidato" non ha modo di controllare se qualcosa ha senso (cioè, il primo elemento potrebbe essere annidato 6 volte).

Sto cercando una risposta migliore.

Come nota a margine, il database effettivo include le modifiche di revisione di ogni pagina e un posto per contenuti extra come i commenti.

sql database database-design

posta Incognito 21.07.2011 - 16:17

fonte

2 risposte

2

Nella mia umile opinione dovresti prestare attenzione alla vera forma dei dati. E la struttura-core del tuo non è relazionale e tabulare nella sua natura.

Non penso che un database relazionale sia adatto al tuo dominio aziendale in modo naturale. Un database per archiviare dati gerarchici, ad esempio un database XML per esempio ( eXist ), potrebbe adattarsi meglio al tuo dominio aziendale, poiché offre più libertà nella memorizzazione e nel recupero di dati gerarchici. eXist integra anche alcune funzionalità come FullText-Search senza problemi (integrazione di Lucene).

È possibile considerare un approccio ibrido, archiviando solo una parte dei dati come XML in un database relazionale con funzionalità XML (mi viene in mente Oracle).

In ogni caso, l'estrazione delle gerarchie può essere davvero difficile su alcuni RDBMS, sebbene alcuni possano recuperare tali dati in una singola query, ad esempio Oracle con la sua istruzione CONNECT BY. E anche la manipolazione di tali gerarchie può essere ingombrante.

risposta data 22.07.2011 - 15:43

fonte

Leggi altre domande sui tag sql database database-design

Mio padre vuole imparare PHP-MySQL per portare la sua applicazione. Cosa dovrei fare per aiutare? [chiuso] L'intelligenza funzionale e la navigazione del codice sono più vantaggiose rispetto all'impiego di contenitori di dipendenze per iniezione

score 3 · Accepted Answer

Un numero di raccomandazioni e note .:
1) Devi elencare un ordine delle pagine da qualche parte (io non fare affidamento su qualsiasi cosa tranne una specifica colonna 'order' per questo) - Questo può essere ottenuto con una colonna di tipo 'page_number' ( come position_in_TOC sembrerebbe implicare), o un equivalente di tipo di lista collegata ('la prossima pagina ha questo id').
2) C'è un'enorme possibilità di aver bisogno di più gruppi per libro; Vorrei raccomandare una tabella di correlazione book_group , che ti permette di avere libri che trattano cose come ORM Framworks o accesso al database del programma (con gruppi come "Java", "SQL", "C #", "Ibernazione", ecc.).
3) Invece di avere un "fattore annidato", prendi in considerazione l'utilizzo di una relazione padre-figlio ricorsiva (che è precisamente ciò che è la relazione). Questo cambierà anche quale sezione è nidificata dove molto più semplice.
4) Non importa quello che fai, avrai una sorta di programmazione "complessa". Dovrai solo occupartene.

Penso che un design leggermente più flessibile sia più vicino a questo (nota: questo non è stato completamente normalizzato, ma dovrebbe essere un buon punto di partenza):

Questo consente diverse cose:
1) I libri possono essere parte di più gruppi o nessuno.
2) Le sezioni sono specificatamente elencate come figli di altre sezioni ( null se sono le prime). Ciò consente alle sezioni di essere spostate all'interno di un diverso genitore semplicemente riassegnando parent_section .
3) Le pagine e le sezioni hanno entrambe una% ordinale diindex. Ciò consente loro di essere riordinati all'interno della loro sezione di contenimento, senza riguardo all'indice dei loro genitori; Pagina 1 è la pagina 1 di quella sezione, non dell'intera struttura, eliminando la necessità di riordinare l'intero albero se cambia solo una sezione.

Ci sono una serie di cose che potrebbero essere fatte per distruggere questo progetto, magari aggiungendo pagine di intestazione di sezione o qualcosa del genere.