Ho un'app Web a cui è possibile collegare applicazioni esterne per inviare i propri dati. Questo è per scopi di telemetria.
L'app Web non controlla il tipo di dati di telemetria che gli viene inviato: può essere qualsiasi cosa in una forma di Dictionary<string, object> .
Intendo memorizzare ogni chiave di questa coppia di valori chiave come una riga separata nella tabella "TelemetryDetails".
La tabella conterrà Id (int), Key (stringa) - e valori - tuttavia, non sono sicuro in quale formato.
Ci sono due considerazioni:
- Probabilmente il tavolo diventerà di dimensioni enormi, quindi mi piacerebbe mantenerlo il più "leggero" possibile. Suppongo che meno colonne siano "migliori" per il database?
- Voglio consentire la semplice & interrogazione veloce di questi dati
Mi chiedo se è meglio mantenere qualsiasi valore come stringa (avendo così solo tre colonne in questa tabella), o creare una colonna separata (e quindi una proprietà sulla mia entità EF) per ciascuno dei tipi di dati primitivi, ad esempio:
public class MyEntity
{
public int Id { get; set; }
[MaxLength(50)]
public string Key { get; set; }
public string ValueTypeName { get; set; } //maybe also have the type stored...
public string ValueString { get; set; }
public bool? ValueBoolean { get; set; }
public decimal? ValueDecimal { get; set; }
public int? ValueInt { get; set; }
public DateTime? ValueDateTime { get; set; }
}
In questo modo la tabella ottiene più colonne, di cui la maggior parte è nullo, il valore effettivo è memorizzato solo in una di esse - questo potrebbe consentire alle query più veloci / più leggere di ottenere dati "user-chart-friendly", con calcoli come SUM, AVG, MAX ecc. - che non è possibile sulle stringhe.
Inoltre, se vai avanti con questo approccio, forse avrebbe anche senso avere diverse colonne per ValueString con una lunghezza diversa - ad es. non mantenere le stringhe corte nella colonna NVARCHAR (MAX)?
Non sono sicuro che tutto ciò non sia pseudo-ottimizzazione senza senso e / o cattiva progettazione.