Per convertire in tipi di dati accurati o mantenere il tipo di stringa predefinito

Naviga le tue risposte
1

Scenario:
Ho un'applicazione web che registra e controlla i dati rispetto a due tabelle temporanee (una tabella è una fonte temporanea e l'altra è una destinazione per l'applicazione). Queste tabelle temporanee vengono sincronizzate ogni notte con la rispettiva destinazione / sorgente sql viste .

Il problema:
Le viste di origine / destinazione hanno tipi di dati char / nvarchar, tuttavia il contenuto effettivo all'interno di queste viste è per lo più integer. Come dovrei costruire il mio modello per le tabelle temporanee all'interno dell'applicazione? dovrei convertire i dati nei loro tipi reali (convertendo i tipi durante il tempo di sincronizzazione) o semplicemente tenerli sotto forma di stringhe?

Importante:
Non è necessaria alcuna convalida per i tipi, sarà impossibile per l'utente inserire dati non validi. I tipi di dati true del contenuto rimarranno costanti per ogni colonna senza variazioni accidentali. Quindi la domanda si riduce a, c'è qualcosa di sbagliato nell'elaborazione degli interi come stringhe? Altro che fastidioso da morire.

    
posta S1r-Lanzelot 15.04.2015 - 17:53
fonte

2 risposte

4

Archiviarli nel database come rispettivi tipi di dati. Invece di memorizzare "1234" come stringa, memorizza int 1234 .

Questo fa un paio di cose per te.

  1. Impedisce ai consumatori di dati di dover eseguire la conversione e gli errori possibili (non solo questo eviterà errori, ma massimizzerà le prestazioni per i consumatori di dati. Converti i dati prima che vengano scaricati nella tabella in modo che non devono essere convertiti continuamente al momento del recupero)
  2. Permetterà di fallire rapidamente i dati cattivi e fallirà presto, dato che non potresti mettere male i dati nella tabella di origine (cioè su una colonna int , se non ti aspettavi dati errati ma hai tentato di lancia "123a4" lì dentro fallirebbe: è una buona cosa
  3. Archivia i dati come previsto. Allevierà molte complicazioni.
risposta data 15.04.2015 - 18:10
fonte
1

Ci sono dei compromessi da considerare ...

Se i dati rimarranno sempre interi, potresti considerare la conversione in numeri interi. Ma attenzione a prevedere il futuro. Se i dati devono essere confrontati o ordinati, o comunque analizzati in base all'intervallo in base al valore numerico, è possibile considerare la conversione in numeri interi. Se i dati potrebbero richiedere flessibilità per quanto riguarda la formattazione, potresti prendere in considerazione la possibilità di mantenere le stringhe.

A volte le cose che assomigliano ai numeri finiscono per richiedere un prefisso o suffisso descrittivo aggiunto in seguito, e ciò interromperà le tue conversioni. Se non sono realmente valori numerici che significano qualcosa, per esempio sono semplicemente identificatori, quindi sono molto più facili da gestire come stringhe. Questo ti dà la massima flessibilità nella formattazione e non devi preoccuparti del controllo della validità numerica. È possibile tagliare le stringhe, convalidare le cifre in base alla loro posizione all'interno della stringa - le opzioni sono illimitate.

Supponiamo di avere l'autostrada 70 nel database con 70 nella colonna del numero dell'autostrada. Potresti avere una colonna di direzione che può contenere valori NSEW. Cosa succede se si desidera aggiungere Hwy "70 Alt" Sud? "Alt" non può andare nella colonna di direzione, ma interrompe la conversione del numero dell'autostrada. Il 70 nel numero dell'autostrada non significa che è maggiore della 65 o meno dell'autostrada 75. Dovrebbe essere una stringa sia nel database che nel codice.

Una colonna che contiene un indicatore di miglio specifico su Hwy 70 dovrebbe essere un numero, però.

    
risposta data 15.04.2015 - 18:43
fonte

Leggi altre domande sui tag

Lettura dei nomi degli elementi rispetto agli attributi degli elementi di lettura: velocità Nel mio caso d'uso, ha senso fare in modo che ogni metodo principale restituisca un risultato asincrono?