Ha mai senso creare tabelle dinamicamente?

1

Sto costruendo un servizio in cui ho bisogno di filtrare le attività da diversi prodotti. I dati effettivi si trovano in un altro archivio di valori chiave. Poiché il servizio deve supportare il filtraggio anche sulle attività, era previsto l'utilizzo di mysql per il solo uso dei filtri. Poiché le attività di diversi prodotti possono essere diverse e anche i campi che devono essere indicizzati possono essere diversi, stavo pensando di creare nuove tabelle per ogni serie di attività con le colonne che devono essere indicizzate. Vedi qualche problema nella creazione di tabelle in volo anche per questi tipi di casi d'uso?

Poiché il servizio cerca di essere generico, non ha una struttura dei dati prima della mano. Sto immaginando che lo schema per ogni tipo di attività sarebbe qualcosa di simile a questo

__________________________________________________________________________
tenant_id| activity_id | filter_1(actor_id) | filter_2(group_id)| filter_3(segment_id)
__________________________________________________________________________

primary key(tenant_id, activity_id) (activity_id is a timebased id to sort activities based on time)
index_1 : tenant_id| filter_1 | activity_id
index_2 : tenant_id| filter_2 | activity_id
index_3 : tenant_id| filter_2 | activity_id

if the activity usecase queries certain fields together then always then we might replace the indexes with a composite index(Eg. filter_2 and filter_3 are always present in the queries)
index_4: tenant_id| filter_2 |filter_3 | activity_id

Sono anche preoccupato per il numero di indici che potremmo finire con la creazione di questo approccio. Va bene avere così tanti indici?

    
posta dakrpssngr 04.12.2018 - 14:26
fonte

1 risposta

2

I problemi con la generazione dinamica di tabelle non sono specifici per l'utilizzo. Tende solo ad essere problematico in generale. Ecco alcune preoccupazioni in cima alla mia testa:

  • Sicurezza: per creare tabelle, un utente ha bisogno di un livello piuttosto alto di privilegi. Questo in genere non è qualcosa con cui si desidera che il codice venga eseguito. Devi considerare come attenuerai questa situazione se avanzerai con l'idea.

  • Parole chiave e parole riservate: è necessario assicurarsi di generare un buon DDL. Ci sono molte parole comuni che non puoi usare come nomi di colonne ecc.

  • Modifiche alla struttura: ad un certo punto le cose cambieranno e dovrai considerare come funzionerà. Crei una nuova tabella per un prodotto esistente? La continuità è importante?

  • SQL dinamico: se generi tabelle dinamicamente, presumo che dovrai generare SQL in modo dinamico. Molto è stato scritto sulle sfide con questo (in particolare la sicurezza) e non ho intenzione di ripeterlo qui.

Il mio primo pensiero è che dovresti esplorare un approccio normalizzato per farlo. Il grosso lato negativo che vedo è che l'indicizzazione potrebbe non essere altrettanto efficace. Ma senza costruirlo e fare qualche analisi è difficile dirlo. Ciò eviterebbe la maggior parte, se non tutti, di questi aspetti negativi. Ti suggerisco di provarlo prima e se non ottieni prestazioni ragionevoli, riconsidera la tua idea o guarda altre opzioni come quelle che hai menzionato.

Un'altra opzione è quella di avere strumenti che generano DDL dai tuoi dati e gestirli in un modo più tradizionale. Suppongo che se senti il bisogno di renderlo dinamico, potresti ricevere nuovi prodotti a una velocità troppo elevata per renderlo gestibile.

    
risposta data 04.12.2018 - 19:07
fonte

Leggi altre domande sui tag