Django CharField vs TextField


302

Qual'è la differenza tra CharField()e TextField()in Django? La documentazione dice che CharField()dovrebbe essere usato per stringhe più piccole e TextField()dovrebbe essere usato per stringhe più grandi. Va bene, ma dov'è tracciata la linea tra "piccolo" e "grande"? Cosa sta succedendo sotto il cofano qui che rende questo il caso?

Risposte:


354

È una differenza tra RDBMS varchar(o simili) - quelli di solito sono specificati con una lunghezza massima e potrebbero essere più efficienti in termini di prestazioni o archiviazione - e text(o simili) tipi - quelli di solito sono limitati solo da limiti di implementazione codificati (non un Schema DB).

PostgreSQL 9, in particolare, afferma che "Non vi è alcuna differenza di prestazioni tra questi tre tipi" , ma AFAIK ci sono alcune differenze, ad esempio MySQL, quindi questo è qualcosa da tenere a mente.

Una buona regola empirica è che si utilizza CharFieldquando è necessario limitare la lunghezza massima, TextFieldaltrimenti.

Anche questo non è specifico per Django.


43
E viceversa, se usi CharField devi avere una lunghezza massima
Sam Svenbjorgchristiensensen

17
Ho scoperto che l'utilizzo TextFielddi default può influire sulla portabilità della tua app. Postgres potrebbe non avere un impatto sulle prestazioni, ma Oracle lo memorizzerà come un CLOBelemento che presenta alcuni fastidi, come non poter utilizzare il campo nelle istruzioni WHERE. Solo qualcosa da considerare.
Rob,

3
Si dovrebbe anche considerare che in Oracle CharFieldnon può essere max_lengthmaggiore di 2000 o che genera un ORA-00910: specified length too long for its datatypeerrore.
Dinei,

È utile notare, quando si considerano gli attributi dei campi, che anche i documenti Postgres dicono (enfasi il mio): "la stringa di caratteri più lunga possibile che può essere memorizzata è di circa 1 GB. (Il valore massimo che sarà consentito per n nella dichiarazione del tipo di dati è meno di quello [...] Se desideri memorizzare stringhe lunghe senza un limite superiore specifico, usa il testo o il carattere che varia senza un
identificatore di

3
Credo che la differenza davvero importante tra i due nel django sia come una vista gestirà il campo. In una vista di modifica generica, TextField verrà visualizzato come input ridimensionabile a più righe; mentre CharField è un input a riga singola. Non ho esaminato la fonte di django per TextField, ma suppongo che se un HTML generato è collegato a un TextField, molto probabilmente implementerà un modo per manipolare correttamente il testo multilinea.
Mitchell Walls,

36

In alcuni casi è legato a come viene utilizzato il campo. In alcuni motori DB le differenze di campo determinano come (e se) cercare il testo nel campo. I CharField sono in genere utilizzati per gli oggetti in cui è possibile effettuare ricerche, ad esempio se si desidera cercare "uno" nella stringa "uno più due". Poiché le stringhe sono più brevi, richiedono meno tempo per la ricerca del motore. I campi di testo in genere non sono pensati per essere cercati (come forse il corpo di un blog) ma devono contenere grossi pezzi di testo. Ora la maggior parte di questo dipende dal motore DB e, come in Postgres, non importa.

Anche se non importa, se si utilizza ModelForms si ottiene un diverso tipo di campo di modifica nel modulo. ModelForm genererà un formato HTML della dimensione di una riga di testo per un CharField e multilinea per un TextField.


2
Questa è di gran lunga la migliore spiegazione perché menziona come genera il campo in una forma. Charfield sarà solo un input di una riga, ma TextField sarà un multilinea ridimensionabile. TextField ha senso quando si implementano principalmente viste di classe generiche. Funziona benissimo per un campo di descrizione o simili. Mi piace anche il modo in cui renderbox ha affermato che non vorresti usarlo per nessun filtro / ricerca.
Mitchell Walls,

8

Per es.,. 2 campi vengono aggiunti in un modello come di seguito ..

description = models.TextField(blank=True, null=True)
title = models.CharField(max_length=64, blank=True, null=True)

Di seguito sono riportate le query mysql eseguite quando vengono applicate le migrazioni.


per TextField(descrizione) il campo è definito come alongtext

ALTER TABLE `sometable_sometable` ADD COLUMN `description` longtext NULL;

La lunghezza massima TextFielddi MySQL è di 4 GB in base alla panoramica del tipo di stringa .


per CharField(titolo) max_length (richiesto) è definito comevarchar(64)

ALTER TABLE `sometable_sometable` ADD COLUMN `title` varchar(64) NULL;
ALTER TABLE `sometable_sometable` ALTER COLUMN `title` DROP DEFAULT;

1
nit: i documenti di Django raccomandano Avoid using null on string-based fields such as CharField and TextField:: docs.djangoproject.com/en/2.0/ref/models/fields/#null, quindi è meglio tenerlo null=False.
Modulitos,

7

CharFieldha max_length di 255caratteri mentre TextFieldpuò contenere più di 255caratteri. Utilizzare TextFieldquando si dispone di una stringa di grandi dimensioni come input. È bene sapere che quando il max_lengthparametro viene passato in a TextFieldpassa la validazione della lunghezza al TextAreawidget.


"Tutti i campi memorizzati con VARCHARtipi di colonna hanno un max_lengthlimite di 255 caratteri se si utilizza unique = True per il campo. " (Il mio accento.)
l0b0

-4

Ho avuto uno strano problema e ho capito una spiacevole differenza spiacevole: quando ricevo un URL dall'utente come CharField e poi lo utilizzo in html un tag di href, aggiunge quell'URL al mio URL e non è quello che voglio. Ma quando lo faccio con Textfield passa solo l'URL inserito dall'utente. guarda questi: il mio indirizzo del sito web:http://myweb.com

Ingresso CharField: http://some-address.com

quando si fa clic su di esso: http://myweb.comhttp://some-address.com

Testo inserito: http://some-address.com

quando si fa clic su di esso: http://some-address.com

Devo dire che l'URL viene salvato esattamente lo stesso nel DB in due modi, ma non so perché il risultato sia diverso quando si fa clic su di essi

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.