Sviluppo Web: è sempre necessario digitare o è possibile digitare su richiesta lavoro?

L'utilizzo della memoria è in fondo alla lista dei vantaggi della digitazione dei dati.

Prendi le date per esempio. Se si accetta una data in un campo modulo, è probabile che si desideri almeno in qualche modo permetterti di accettare i dati in qualsiasi formato l'utente desideri inserirli (ovvero 7/1/77 o 7-1-1977 o 7-77 se stai progettando per un pubblico americano potrebbero essere tutti modi accettabili per rappresentare il 1 ° luglio 1977). Se non lo converti in un tipo di dati DATE , tuttavia, ogni pezzo di codice che tocca la stringa deve sapere in quale formato è inserito. Devono tutti sapere come manipolare quella particolare rappresentazione di stringa se, ad esempio , è necessario ordinare per data o convertirlo in un formato di visualizzazione preferito. È possibile scegliere una sorta di rappresentazione di stringa canonica e convertire la stringa di input nella rappresentazione canonica e quindi codificare tutto il resto per assumere che i dati siano nella rappresentazione canonica prima della manipolazione. Naturalmente, ogni applicazione potrebbe scegliere una diversa rappresentazione canonica, quindi varie librerie potrebbero funzionare in modo diverso su diversi progetti. Stai molto meglio semplicemente convertendo la stringa in una data all'inizio del processo, perché in quel momento tutto può funzionare semplicemente in una data: puoi ordinare sulla data, puoi convertire la data in una rappresentazione di stringa diversa, puoi estrarre componenti di la data, ecc. in modo semplice, diretto e chiaro.

Naturalmente, è possibile progettare l'interfaccia utente per impedire agli utenti di digitare date in formato libero richiedendo che, ad esempio, utilizzino sempre un selezionatore di date o utilizzino campi separati per ciascun componente di data (ad esempio, selezionando "Luglio" da un elenco a discesa). Ciò attenua alcuni dei problemi del paragrafo precedente, ma lega le decisioni prese a livello di vista sul modo migliore di raccogliere dati per le decisioni in altri livelli su come presentare i dati in futuro. E sei ancora bloccato a scrivere codice che converte i vari componenti in vari altri formati al fine di ordinare, scrivere funzioni che fanno cose come determinare se una data è una festa o come aggiungere 30 giorni a una determinata data senza utilizzare alcuna libreria di date .

Oltre a ciò che ha scritto Justin Cave, vorrei aggiungere che non è necessario andare fino alle date per vedere il problema: se i numeri semplici fossero rappresentati in formato stringa nei database, 1111 sarebbero stati ordinati tra 100 e 122. Non funzionerebbe, vero? Quindi, affinché il database possa ordinare correttamente le stringhe numeriche, dovrebbe prima convertirle in numeri reali. Bene, si scopre che salva tutti i tempi, sforzi e mal di testa se vengono semplicemente memorizzati come numeri.

Non vi è alcun motivo per cui non è possibile memorizzare ogni cosa come stringa (livelli db e di presentazione), in particolare se ciò ha senso per l'applicazione. L'unico motivo per ricorrere a tipi specifici è quello di rafforzare l'integrità dei dati (ad esempio tipi di data, come suggerito nel tuo post) o forse perché le prestazioni sono richieste (ad esempio utilizzando gli ints come campi id nelle tabelle del database per unirmi come dovrebbero essere più veloci) . Le prestazioni non dovrebbero essere un problema a meno che non si disponga di una concorrenza molto elevata o di hardware a bassa / bassa potenza.