progettazione di database PHP / MySQL per vari contenuti / variabile - sistema modulare

StackOverflow https://stackoverflow.com/questions/2135978

Domanda

Sto cercando di costruire (in questo momento solo pensiero / pianificazione / Relazioni disegno:]). Piccolo sistema modulare per costruire siti web di base (per lo più per semplificare le operazioni più comuni che come webdesigner fanno abitualmente)

mi sono po 'bloccato con database di progettazione / intera idea di memorizzazione di contenuti.

1, Che cosa è per lo più dolorosa sulla maggior parte dei siti web (dalla mia esperienza), sono pagine con quasi stesso layout / scheletro, con diverse informazioni -. Per esempio Titolo, foto, e una serie di informazioni - ma, rendendo modelli speciali / moduli speciali in CMS succede a costare più energia di quanta modificarlo come un testo - tuttavia, qui si perde un po 'di potenziale operativo - non possiamo ottenere "solo i titoli", perché, CMS / sistema comprende contenuti intero come uno campo di testo

Quindi, vorrei questo due tavoli - uno per contenere le informazioni quale struttura il contenuto deve (ad esempio quantità solo variabili di foto <1; 500):], il titolo e il testo e foto (grande) e galleria) - COME - e un altro tavolo con tutti i contenuti, i moduli e parti di "collezioni" (il mio nome di lavoro per le varie informazioni strutturate) - COSA 

table module_descriptors (HOW)  
id int  
structure - *???*  

table modules (WHAT)  
id int  
module_type - @link to module_descriptors id
content - *???*
.

2, Quello che mi piace di questo è - non ho bisogno di molti tavoli - Non mi piacciono i database con 6810 tabelle, una per ogni modulo, per la sua descrizione, per Misc. numero al testo delle relazioni, ... e ho anche non mi piace tavoli con 60 colonne, come content_us, content_it, category_id, parent_id.

Sto pensando che potrei tenere la descrizione della struttura e contenuto stesso (notarono la ??? ?) Come XML o CSV, ma forse sto cercando di reinventare la ruota e rispondere alle questo è nascosto in qualche modello di progettazione non ho guardato in.

Spero di fare alcun senso a tutti e vorrei avere alcune risposte - mi dare la vostra opinione, pro, cons ... o mandarmi a quel paese. Grazie

Modifica : La mia domanda è anche questo: Questo approccio ha senso? E 'edit-friendly? Non c'è qualcosa di meglio? E 'morale? Non fare i gattini muoiono quando faccio questo? Non è troppo per il server, se voglio leggere e confrontare 30 XMLs tirati da DB (ad esempio voglio confrontare qualcosa)? La parte tecnica - come si fa - è solo una parte della domanda:)

È stato utile?

Soluzione

Il modello di progettazione si sta accennando a è chiamato Serialized LOB . È possibile memorizzare alcuni dati nel modo convenzionale (come colonne) per gli attributi che sono gli stessi per ogni ingresso. Per gli attributi che sono variabili, li formatta come XML o MarkDown o quello che volete, e conservarla in un BLOB di testo.

Naturalmente si perde la capacità di usare espressioni SQL per interrogare i singoli elementi all'interno del BLOB. Tutto ciò che è necessario utilizzare nella ricerca o l'ordinamento dovrebbe essere in colonne convenzionali.

Re commento: Se il vostro blob di testo è in formato XML, è possibile cercare con funzioni XML supportate da MySQL 5.1 e versioni successive. Ma questo non può beneficiare di un indice, quindi sta andando a provocare nelle ricerche molto lenti.

Lo stesso vale se si tenta di utilizzare LIKE o RLIKE con caratteri jolly. Senza l'utilizzo di un indice, le ricerche si tradurrà in full table-scan.

Si potrebbe anche provare a utilizzare un MySQL FULLTEXT indice, ma questa non è una buona soluzione per la ricerca di dati XML, perché non sarà in grado di capire la differenza tra il contenuto del testo e nomi dei tag XML e gli attributi XML.

Quindi, solo utilizzare le colonne convenzionali per tutti i campi che si desidera cercare o Ordina per. Sarai più felice in questo modo.

Re domanda: se i documenti veramente richiedono struttura variabile, si hanno poche scelte. Se usato correttamente, SQL presuppone che ogni riga ha la stessa struttura (cioè, colonne). Le alternative sono:

Alcune persone ricorrono a un antipattern chiamata Entity-Attribute-Value (EAV) per memorizzare gli attributi variabili, ma onestamente, non ci vanno. Per una storia su quanto male questo può andare male, leggere questo articolo: Bad CARMA .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top