Come archiviare i dati in un database senza tabelle?

Tutto ciò che ho imparato a scuola era SQL che salva i dati nelle tabelle. In questo momento sto lavorando a un progetto in cui i dati sono archiviati in file XML. Inoltre ogni XML contiene un riferimento a file visivi (JPEG).

Lo stesso XML contiene oltre mille punti di coordinate, oltre a informazioni aggiuntive sui dati.

A mio avviso, non avrebbe senso archiviare queste informazioni nelle tabelle. Inoltre non sono riuscito a memorizzare file JPEG con SQL.

Quale sarebbe la soluzione appropriata o c'è un errore nel ragionamento dalla mia parte?

Come puoi vedere, sono abbastanza nuovo nei database. Pertanto, eventuali suggerimenti, collegamenti e consigli costruttivi sono i benvenuti.

Tutto ciò di cui hai bisogno è la persistenza del tuo XML. Utilizzare una soluzione NoSQL o il file system.

Non vi è alcun vantaggio nell'uso di un RDBMS, a meno che non si desideri utilizzarlo al posto di NoSQL o del file system.

Ho inserito tra i preferiti il post sul blog di Phil Factor Normalization e 'Anima notitia copia' oggi che riassume accuratamente il caso a favore e contro la normalizzazione di alcuni tipi di dati. Esegui la seguente query su un'istanza SQL e verifica se sei d'accordo.

SELECT * FROM sys.syslanguages

SQL consente di creare database relazionali. Tuttavia, anche se ha un cattivo odore, non è un crimine fare cose orribilmente non relazionali con un database SQL fintanto che è necessario e si può dire la differenza; non solo, ma anche solo se sei consapevole dei rischi e delle implicazioni.

Hai menzionato che il file XML contiene "informazioni aggiuntive sui dati". C'è qualche vantaggio nel modellare quei metadati in un database relazionale, forse a fini di interrogatorio? In tal caso, potrebbe esserci un caso per l'estrazione dei dati rilevanti e la persistenza dell'XML rimanente come tipo di documento XML.

... se ti viene passata una stringa JSON o XML e ti viene richiesto di memorizzarla in un database, allora tutto ciò che devi fare è chiederti, nel tuo ruolo di Anima notitia copia (Anima del database) 'ho qualche interesse per il contenuto di questa informazione? '. Se la risposta è "No!" O "nequequam! Quindi è un valore atomico, per quanto complesso possa essere.

L'argomento di Phil Factor è che i campi non relazionali in un database relazionale sono perfettamente accettabili se il campo è trattato come atomico, cioè non cambia, o quando cambia l'intero campo, non una parte costituente di esso. La naturale estensione di questo è che se il tuo documento contiene elementi di tuo interesse, potrebbe esserci un valore nell'applicare un modello relazionale a quegli elementi.

Rilevante per la domanda, ma principalmente per la fraseologia, un'ultima citazione di Phil:

Ovviamente, non ho mai creato consapevolmente un database a cui Codd si sarebbe accigliato, ma intorno ai bordi ci sono interfacce e feed di dati che ho scritto che hanno causato problemi di confusione tra i fondamentalisti della normalizzazione.

Non abbiamo tutti!

Per quanto riguarda i database Oracle, la risposta è che non puoi . Tutti i dati in un database sono archiviati in tabelle, anche metadati. I dati possono essere archiviati in code, ma questi sono solo un modo diverso di usare le tabelle. I file XML possono essere archiviati al di fuori di un database, ma ciò non soddisfa il requisito "nel database".

Andando oltre la domanda dichiarata, i file JPEG o qualsiasi altro file possono essere archiviati in un database. Richiederebbero una tabella e una colonna LOB (BLOB o CLOB). Anche l'XML può essere archiviato in questo modo, ma l'importazione dei dati XML nel database consentirebbe di operare sui dati in modi che non possono essere facilmente eseguiti ora. Fornirebbe anche altri vantaggi dei database, tra cui: ridondanza ridotta, accessibilità, concorrenza, scalabilità, interoperabilità, sicurezza, recupero e prestazioni.

Se i vantaggi di un database non promuovono i tuoi obiettivi, non utilizzarne uno.

Mi sembra che tu stia cercando di implementare un database spaziale . Questo è un tipo di database relazionale (o un componente aggiuntivo a prodotti di database esistenti, ad esempio Oracle Spatial, postGIS) che supporta funzioni di tipi di dati spaziali e viene utilizzato per ottimizzare l'archiviazione e le query per i dati relativi a caratteristiche spaziali come confini poligonali, punti e strati. L'XML in uso suona come coppie di coordinate di confine e le immagini associate sembrano risorse di grafica da visualizzare in quel limite. Se i dati si adattano, prendere in considerazione un database spaziale relazionale che offre la modellazione spaziale integrata per fornire funzionalità che altrimenti si potrebbero trovare difficili o dispendiose in termini di tempo da implementare.