Tabella di database tridimensionale

Question

Siamo stati tutti lì - prendi in considerazione il seguente esempio: in primo luogo, il cliente dice "ogni utente deve avere una sola immagine del profilo", quindi aggiungiamo un campo alla tabella degli utenti - sei mesi dopo , i requisiti cambiano e un utente deve effettivamente avere n immagini del profilo.

Ora, questo sembra possibile solo se aggiungi una nuova tabella come user_pictures per gestire la nuova cardinalità 1: n invece di 1: 1. Spesso questo può diventare molto complicato. Ogni volta che mi imbatto in questo problema, mi chiedo perché non usiamo tutte e tre le dimensioni in cui possiamo pensare. Una tabella bidimensionale è limitata in modo un po 'incompleto, e se si riferisse al nostro problema con l'immagine del profilo di nuovo, il campo immagine nella tabella utenti aveva una profondità e tale profondità rendeva il campo una matrice che rappresentava perfettamente entrambe le cardinalità 1: 1 e 1: n allo stesso tempo.

I campi di tabella diventano semplicemente array e supportano automaticamente entrambe le cardinalità: non sarebbe qualcosa? Almeno lo userei. C'è già qualcosa di simile là fuori?

Answer 1

Oracle ha il supporto per arrays e nested tables. Sembra che soddisfi le tue esigenze. In questi giorni, però, le persone preferiscono modellare tutto come tabelle e relazioni per mantenere le cose semplici e coerenti e gli RDBMS moderni non supportano in genere queste cose e non credo nemmeno che siano mai state introdotte in SQL standard.

Answer 2

Lo standard molti-a-molti approccio, molti utenti a molte immagini del profilo, è facilmente coperti dal approccio a tre tavolo:

Tabella: gli utenti
Tabella: Immagini
Tabella: User_Pictures

Tuttavia, se si passa a un approccio NoSQL, è possibile memorizzare un documento Utente (di solito in formato JSON), che memorizza un array di immagini del profilo per quell'utente in una singola tabella.

@gordy +1 per il collegamento Oracle. Non ero sicuro se alcuni array presunti RDBS.

Answer 3

Si sta descrivendo una tecnica di denormalizzazione (più colonne per istanze di un campo) e di solito porta a piangere a meno che non si comprenda completamente le conseguenze della violazione dei principi relazionali di base.

Una difficoltà classica arriva quando si desidera eseguire una query sul campo ("trova l'utente che ha questa immagine") e si scopre che un'istruzione SQL con "AND picture IN (pic1, pic2, pic3)" non può essere indicizzato e il tuo ottimizzatore inizia a pianificare la sua vendetta.