Metodo suggerito per "semplificare" EAV

Question

Metodo suggerito per "semplificare" EAV

#1 da (2 voti)

4

Sto lavorando su una piattaforma GIS che gestisce fondamentalmente le strade con funzionalità. Il sistema utilizza un modello EAV per archiviare tutti i dati in un database. Il sistema è in circolazione da un po 'e non c'è nulla che io possa fare per cambiare completamente il modello del database. EAV è stato scelto perché ogni installazione aveva caratteristiche uniche con attributi unici.

Vogliamo creare API (ad esempio un Web Api) e viste di database su questa piattaforma per una facile integrazione con altri sistemi, principalmente di sola lettura.

La sfida che stiamo affrontando oggi durante la progettazione delle API è principalmente due:

Prestazioni: in genere prestazioni lente / query complesse quando si tenta di elencare le funzioni insieme agli attributi
Ricercabilità: difficile eseguire una query con i tipi corretti (surface = 'ghiaia' e larghezza > 2) perché tutto è memorizzato come stringhe nel database

Idealmente, vorremmo avere un set di tabelle nel database, uno per ogni funzione con le colonne e i tipi di dati corretti.

Un'idea è di utilizzare i trigger sul database per creare e gestire uno schema separato contenente queste tabelle con le colonne corrette (una per ogni tipo di funzionalità). Questo schema dovrebbe ricreare le parti interessate, ad esempio se un attributo viene aggiunto o rimosso da un determinato tipo di funzionalità. La creazione di questi trigger non è un compito banale.

Qualcun altro ha un'idea migliore?

api-design database-design

posta Emil G 30.11.2016 - 08:32

fonte

1 risposta

Leggi altre domande sui tag api-design database-design

Quali sono i diversi approcci al filtraggio sui dati aggregati? Unione di una tabella con tabella da database / API esterni

score 2 · Accepted Answer

Questa non è un'idea migliore di quella che suggerisci. Si arricchisce un po 'di più.

Esistono molte situazioni in cui l'uso commerciale dei dati risulta in due database. Uno è orientato alle transazioni e l'altro è orientato all'analisi. Questo secondo database è talvolta chiamato un database di reporting, un data mart o persino un data warehouse. Il processo di mantenere aggiornato il database di reporting è chiamato Extract, Transform, and Load (ETL). L'ETL può essere fatto su base individuale o ci sono strumenti ETL che possono essere applicati a molte situazioni. Questi strumenti non sono banali.

Ci sono due differenze tra il tuo caso e i casi in cui ho effettivamente funzionato. Il primo è che il database delle transazioni è EAV, mentre i casi che ho lavorato sono iniziati con un database delle transazioni relazionali. In secondo luogo, si sta tentando di rendere il processo di aggiornamento guidato dagli eventi tramite trigger, mentre i casi in cui ho lavorato hanno utilizzato un processo di aggiornamento durante la notte e consentito al database di report di rimanere indietro rispetto ai dati correnti di un giorno o addirittura fino a un mese. ETL non è banale nelle migliori circostanze e il tuo caso presenta sfide uniche.

Se sei interessato a un layout specifico per le tabelle che renderà facile produrre un'ampia varietà di rapporti o estratti, ti suggerirò di esaminare un modello di progettazione chiamato "schema a stella". Uno schema a stella inizia fondamentalmente con un modello multidimensionale dell'argomento e lo sovrappone al tipo di tabelle SQL in genere utilizzate per creare database relazionali. C'è un modello simile chiamato schema fiocco di neve in cui alcune delle tabelle in uno schema a stella sono state normalizzate in una certa misura.

C'è molto schema a stella o schema a fiocco di neve, e non ho intenzione di provare a riepilogare qui.

Buona caccia!