Memorizzazione e presentazione di dati di tabelle personalizzate

1

Ho un sito web sul quale voglio fornire agli utenti la possibilità di creare tabelle di dati. Queste tabelle verranno da un elenco predefinito di definizioni di tabella di cui aggiungerò a me stesso. Questo elenco sarà probabilmente aumentato a centinaia. Le definizioni di tabella verranno create come classi Java. Definiranno quante colonne ci sono e i loro tipi di dati (stringa, numerico, booleano, seleziona dalla lista). Predefinirà anche alcune colonne come automaticamente calcolate da altre colonne. Il numero di righe sarà limitato ma potrebbe variare da 10 a 10000. Inoltre, darò agli utenti un'opzione per creare un tipo di tabella personalizzato in cui impostano il numero di righe e colonne e i tipi di colonna (stringa, numerico, booleano, selezione dalla lista - nessuna formula).

Le tabelle devono essere ordinabili su determinate colonne (con colonne di ordinamento secondarie in base alla prima). L'ordinamento dei dati sarà (probabilmente) eseguito dall'applicazione anziché dal database in quanto includerà una logica diversa nelle diverse definizioni di tabella. Potrei includere una semplice ricerca di testo ma non un filtro. I dati della tabella potrebbero essere aggiornati, ma mi aspetto che ciò non sia frequente (a distanza di giorni, quasi mai).

Quello che non riesco a decidere è il modo migliore per memorizzare queste informazioni. Sto usando una relazione db (postgres). Poiché ogni riga sarà composta da vari tipi di colonne differenti, non posso memorizzare i dati in righe di database separate con tipi di campi rilevanti per ciascuna colonna.

Sul lato web voglio che gli utenti siano in grado di visualizzare i dati pagati. Gli utenti che non hanno JavaScript abilitato possono gestire una tabella di base dei dati paginati senza opzioni di ordinamento. Gli utenti con JavaScript abilitato dovrebbero avere opzioni per ordinare i dati.

archiviazione

Opzione 1

Crea un documento XML contenente tutti i dati e archivia in una riga del database. Questo sarà facile da leggere e scrivere, ma significa che l'intera tabella web deve essere caricata in memoria anche se si forniscono solo poche righe al browser.

Opzione 2

Crea un frammento XML per ogni riga e archivia in righe di database separate. Poiché i dati verranno ordinati in base all'applicazione, l'ordine deve essere calcolato quando viene visualizzata la prima pagina e quindi per le altre pagine vengono restituite solo le righe richieste oppure, quando i dati vengono aggiornati, viene creato un indice predefinito per ciascuna opzione di ordinamento. L'indice predefinito sembra l'opzione migliore in quanto non cambierà spesso, ma verrà letto numerose volte.

Consegna dei dati nel browser

Opzione 1

Per i browser abilitati JS ottenere tutti i dati utilizzando AJAX / JSON. La risposta verrebbe memorizzata nella cache del browser e utilizzando JS popolare una tabella con i dati. Ulteriori interventi sul server non dovrebbero essere richiesti a meno che i dati non vengano aggiornati (rilevati solo quando la pagina viene aggiornata utilizzando l'ultima ora aggiornata incorporata nella pagina). Le visite successive alla pagina dovrebbero utilizzare la copia cache dei dati.

Opzione 2

Incorpora dati paginati in html. Se JS è abilitato, ulteriori aggiornamenti utilizzando AJAX.

Non voglio utilizzare la memoria offline di HTML 5 per supportare i browser più vecchi.

Penso di dover utilizzare entrambe le opzioni 2 per ospitare browser non JS e minimizzare l'utilizzo della memoria.

Ci sono altre possibili soluzioni?

    
posta Goose 21.08.2014 - 13:32
fonte

1 risposta

2

Va bene, prima di tutto, questo suona pericolosamente come se si costruisse una piattaforma interna : un cattivo reimplementata la versione visibile all'utente dello strumento che stai utilizzando anche per lo sviluppo del sistema. Ma se quelli sono davvero i requisiti, allora va bene, parliamo di come archiverai tali dati.

Non c'è motivo per cui devi passare da un database a XML per archiviare i dati degli utenti a meno che non vi sia un motivo specifico per farlo. "ogni riga sarà composta da vari tipi di colonne" non è una buona ragione. Si può ancora semplicemente avere una tabella DB le cui righe memorizzano le tabelle definite dall'utente e un'altra tabella DB che memorizza le colonne delle tabelle definite dall'utente. In generale, le basi di dati relazionali possono gestire abbastanza bene dati utente ricorsivi, anche se i dati dell'utente stessi costituiscono una sorta di base dati.

Ma fa ancora più freddo. Perché non associare le tabelle definite dall'utente alle tabelle effettive e le loro colonne alle colonne effettive? La maggior parte dei motori di database ti consente di mettere da parte uno schema, uno spazio dei nomi ecc. In modo che tu possa usare qualsiasi nome senza scontrarti con i tuoi nomi esistenti usati dal tuo programma, quindi potresti semplicemente implementare la creazione di una tabella utente come% reale co_de % e cancellazione come%% co_de effettivo. Non c'è nulla di intrinsecamente pericoloso nell'eseguire le dichiarazioni CREATE come risultato dell'input dell'utente, se le tabelle interessate sono state create dall'utente in primo luogo.

    
risposta data 21.08.2014 - 13:40
fonte

Leggi altre domande sui tag