Gli elementi di dati personalizzati devono essere archiviati come voci XML o database?

Question

Gli elementi di dati personalizzati devono essere archiviati come voci XML o database?

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

3

Ci sono un sacco di domande come questa, ma sono per lo più molto generalizzate, quindi mi piacerebbe avere alcune visualizzazioni sul mio uso specifico.

Generale:

Sto costruendo un nuovo progetto da solo a Django. L'attenzione sarà concentrata sulle piccole imprese. Mi piacerebbe renderlo in qualche modo personalizzabile per i miei clienti in modo che possano aggiungere al loro cliente / fattura / dipendente / qualsiasi oggetto. I miei modelli rifletteranno gli articoli di tipo standard che potrebbero avere tutti i ModelX. Ad esempio:

nome
cognome
e-mail
Indirizzo
...

Quindi il mio utente sarebbe in grado di aggiungere campi per qualsiasi dato desiderati. Sono ancora in fase di progettazione e lo sto costruendo da solo, quindi ho alcune opzioni.

Lavorando su ...

Al momento i modelli 'extra items' hanno un FK per il modello generico ( Customer e CustomerDataPoints per esempio). Tutti i valori nei punti dati extra sono memorizzati come char e saranno forzati / convertiti nel loro formato attuale al momento della visualizzazione. In questa build l'utente potrebbe teoricamente aggiungere i valori desiderati, raggrupparli in set e generalmente accedervi a piacimento dalle viste relavent a quel modello.

Pro: sovraccarico di archiviazione ridotto, molto estensibile, disponibile per la ricerca
Contro: più sql join

La mia altra opzione è di usare un certo tipo di markup, o l'abbinamento di valori-chiave memorizzato direttamente sui modelli di boilerplate. In pratica, questo coul è solo un XML di metereologia o stringhe letterali con metodo low-overhead. La visualizzazione e il modulo generato dai dati memorizzati assumono il controllo della convalida e la reoganizzazione degli aggiornamenti. Quindi si limiterebbe a scaricare nuovamente i dati come char / blob / qualunque.

Qualcosa come:

<datapoint type='char' value='something' required='true' />
<datapoint type='date' value='01/01/2001' required='false' />
...

Pro: Nessun join richiesto, Aggiornamenti per la convalida e le viste sono disaccoppiati dai dati
Contro: Sovraccarico di archiviazione molto più elevato, capacità limitata di cercare contenuti extra

Quindi la mia domanda è:

Se non vivessi nei vincoli imposti dalla tua azienda, quale metodo useresti? Perché? Quali sono i vantaggi o le insidie che mi vengono in mente come piccole aziende che cercano di aiutare altre piccole imprese?

Giusto per chiarire, non sto chiedendo informazioni sugli elementi dell'interfaccia utente personalizzati, su quelli che posso gestire con moduli e snippet di modello. Sto chiedendo in primo luogo l'archiviazione dei dati e il recupero di dati non standardizzati rispetto a un modello di piastra calda.

database xml django custom-control

posta meteorainer 10.06.2014 - 22:29

fonte

3 risposte

Leggi altre domande sui tag database xml django custom-control

Il mergesort parallelo viene eseguito in modo diverso su mesh vs array lineare di processori? Callback: quando restituire il valore e quando modificare il parametro?

score 3 · Answer 1

Prima di tutto, la tua applicazione non dovrebbe mai interessarsi della tua archiviazione dei dati. L'archiviazione dei dati, ad es. Un database, è un dettaglio. Ciò di cui la tua applicazione dovrebbe interessare sono le sue entità. Laddove queste entità arrivano i dati da è irrilevante per l'applicazione. Tutta la tua applicazione dovrebbe fare è usare un gateway di entità per manipolare i dati, cioè un'interfaccia che ha metodi per le entità. Ad esempio, un OrderGateway ha metodi come PutOrder , GetOrderById . Le interfacce sono implementate nel livello di accesso ai dati. Seguendo questa architettura, puoi quindi implementare qualsiasi meccanismo di archiviazione che desideri: database, file system, servizio Web, ecc. Questo approccio lascia aperta la tua applicazione per l'espansione.

Inizia con il più semplice, che di solito è l'accesso al file system di base. Quindi, se i tuoi clienti o utenti lo richiedono, implementa altri mezzi di archiviazione dei dati. Non costruire cose con ipotesi vaghe come "forse i miei clienti vorrebbero lavorare su un server SQL, o forse i miei utenti vogliono cercare contenuti extra" -non hai ancora bisogno di questo (ancora).

Vai con il tuo approccio XML (o qualche soluzione simile basata su file system). Preoccuparsi per l'overhead di storage? Bene, ha dimostrato di essere un problema? In caso contrario, non è un problema. Preoccuparsi della capacità di ricerca? Stessa cosa. Se diventa un problema, quindi ottimizzare di conseguenza. L'ottimizzazione anticipata e i problemi previsti devono essere supportati da prove solide prima che possano essere giustificati nello sviluppo del software.

score 1 · Answer 2

Penso che il tuo primo modello sarebbe perfetto se usato con un database No SQL. Non sono un esperto di No SQL DB ma, a quanto ho capito, penso che questo sarebbe uno scenario in cui potresti essere in grado di eliminare i join aggiuntivi. Ecco la pagina su Nessun DB SQL da Wikipedia. Prenderò una lettura e vedrò se questa è una valida opzione per te.

score 1 · Answer 3

Penso che i tuoi dati personalizzati rientrino nella # 3 di questa risposta a una domanda simile :

Values are likely to change frequently and/or meant to be edited by non-developers, but yet this changes will not affect the logic - database with ORM or at least key-value storage with some user-friendly interface.

Probabilmente non vuoi essere responsabile dell'aggiunta dei punti dati personalizzati per ciascuno dei tuoi utenti, quindi renderli più facili da fare da soli dovrebbe essere una priorità piuttosto alta. Chiedere a un proprietario di una piccola azienda di aggiungere punti di dati personalizzati a (essenzialmente) un file di configurazione spegne molte persone, e se hai già familiarità con il lavoro con i database nel codice, memorizzarli li renderà molto più semplice per costruire un'interfaccia utente per loro.

Fintanto che le tue tabelle sono indicizzate bene - la Customer chiave esterna su CustomerDataPoints è indicizzata - i join extra non aggiungeranno un apprezzabile sovraccarico di prestazioni.