Per rispondere:sembra che il testo sia deprecato in molti DBMS, quindi è meglio usare un blob o un varchar con un limite alto (e con blob non avrai problemi di codifica, il che è un grosso problema con varchar e testo) .
Anche come indicato in questo thread sui forum MySQL , i dischi rigidi sono più economici del software, quindi è meglio prima progettare il software e farlo funzionare, e solo allora se lo spazio diventa un problema, potresti voler ottimizzare quell'aspetto. Quindi non cercare di ottimizzare troppo la dimensione della tua colonna troppo presto, meglio impostare una dimensione più grande all'inizio (inoltre questo eviterà problemi di sicurezza).
Informazioni sui vari commenti:Troppo fanatismo SQL qui. Nonostante io sia molto appassionato di SQL e dei modelli relazionali, hanno anche le loro insidie.
L'archiviazione dei dati serializzati nel database così come sono (come l'archiviazione di dati formattati JSON o XML) presenta alcuni vantaggi:
- Puoi avere un formato più flessibile per i tuoi dati:aggiunta e rimozione di campi al volo, modifica al volo delle specifiche dei campi, ecc...
- Meno disadattamento di impedenza con il modello a oggetti:memorizzi e prelevi i dati così come sono nel tuo programma, rispetto a recuperare i dati e poi doverli elaborarli e convertirli tra le strutture degli oggetti del tuo programma e le strutture del tuo database relazionale .
E ci sono molti altri vantaggi, quindi per favore niente fanboyismo:i database relazionali sono un ottimo strumento, ma non distruggiamo gli altri strumenti che possiamo ottenere. Più strumenti, meglio è.
Per quanto riguarda un esempio concreto di utilizzo, tendo ad aggiungere un campo JSON nel mio database per memorizzare parametri extra di un record in cui le colonne (proprietà) dei dati JSON non verranno mai SELECT individualmente, ma utilizzate solo quando il record corretto è già selezionato. In questo caso, posso ancora discriminare i miei record con le colonne relazionali e, quando viene selezionato il record giusto, posso semplicemente utilizzare i parametri extra per qualsiasi scopo io voglia.
Quindi il mio consiglio per mantenere il meglio di entrambi i mondi (velocità, serializzabilità e flessibilità strutturale), basta utilizzare alcune colonne relazionali standard che fungano da chiavi univoche per discriminare tra le righe, quindi utilizzare una colonna blob/varchar in cui verranno visualizzati i dati serializzati essere inserito. Di solito, sono necessarie solo due/tre colonne per una chiave univoca, quindi questo non sarà un sovraccarico importante.
Inoltre, potresti essere interessato a PostgreSQL che ora ha un tipo di dati JSON e al progetto PostSQL per elaborare direttamente i campi JSON come colonne relazionali.
