Memorizzazione di valori in SQL i cui tipi sono determinati in runtime

Question

Memorizzazione di valori in SQL i cui tipi sono determinati in runtime

#1 da (1 voti)

2

Mi sono imbattuto nella necessità di memorizzare i valori determinati dal runtime in un database SQL.

Ad esempio, c'è una GUI in cui un utente può aggiungere nuovi campi modificabili. Quindi l'utente aggiunge un campo Name , sceglie il tipo di valore String e inserisce il valore Arthur . Quindi l'utente aggiunge un nuovo campo Money , sceglie il tipo di valore Decimal e inserisce il valore 10.05 .

Come visto sopra, l'utente può aggiungere qualsiasi campo con qualsiasi tipo di valore.

La mia idea è di avere uno schema di tabella SQL come segue:

FieldName (varchar) - es. 'Money' o 'IsAlive'
FieldType (varchar) - ad esempio 'Decimal' o 'Boolean'
FieldValue (varchar) - es. '10.5' o '1'

Significa che posso memorizzare qualsiasi tipo di dati predefinito nella tabella, sia che si tratti di string , boolean o long .

Il problema è che non sono sicuro che sia l'approccio migliore per trasmettere tali valori a string e quindi eseguire nuovamente il cast durante la lettura dalla tabella.

Un'altra opzione sarebbe quella di avere una colonna di ogni tipo, ma suona anche peggio.

Il mio approccio per trasmettere tutto a suoni di stringa è sensato o dovrei provare qualcos'altro?

sql type-casting

posta Arturs Vancans 27.05.2015 - 22:54

fonte

1 risposta

Leggi altre domande sui tag sql type-casting

Eventi nell'architettura di servizio WCF (lato server) elaborazione di file audio in C ++

score 1 · Answer 1

Tutto si riduce alla necessità di ricercare questi campi aggiuntivi e se si avranno poche righe (centinaia) o molte righe (centinaia di migliaia).

Vedete, la stringa "1000" confronta sotto la stringa "900", quindi qualsiasi ricerca per un numero dovrà essere implementata usando una scansione completa della tabella . Inoltre, è necessario implementare righe ordinate in base a un campo numerico definito dall'utente caricando tutte le righe in memoria, convertendo le stringhe in numeri e ordinando le righe in memoria confrontando i numeri. Che è qualcosa che non vuoi fare se hai centinaia di migliaia di record.

Se i tuoi campi definiti dall'utente non avranno bisogno di essere ricercabili, o se hai solo poche righe, (quindi la scansione completa della tabella è accettabile), allora il cast della stringa dovrebbe andare bene. Di fatto, non hai nemmeno bisogno di andare con una tabella dei valori di tipo nome, puoi semplicemente aggiungere un campo di testo lungo a una delle tabelle esistenti e questo campo di testo può contenere tutti i campi secondari insieme, codificato in XML o JSON.

Tuttavia, se questi campi definiti dall'utente devono essere ricercabili E c'è la possibilità che tu possa avere molte righe, allora questo approccio non funzionerà. Quello che puoi fare in questo caso è avere una tabella di valori nome per tutte le stringhe, una tabella di valori nome per tutti gli interi, una tabella di valori nome per tutti i float, ecc.