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?