La fascicolazione fa la differenza solo se è necessario ORDER BY o cercare nella colonna. Questi elementi codificati Base64 probabilmente non verranno cercati o ordinati.
Se i vostri articoli codificati sono garantiti per essere meno di 64K byte di lunghezza, definire la colonna in questo modo:
`columnname` TEXT CHARACTER SET ascii,
Questo è esattamente ciò che è necessario per una variabile base64 codificato; il processo di codifica trasforma tutto in ASCII visualizzabile.
Se gli elementi saranno meno di 16 megabyte di lunghezza, ma alcuni saranno più lunghi di 64k, utilizzare MEDIUMTEXT anziché TEXT.
Modificare anni dopo.
La stringa codificata OQ, decodificato, è un oggetto php serializzato:
a:2:{s:20:"Type_of_organisation";s:20:"Member of Parliament";s:8:"Postcode";s:7:"PE1 1JA";}
Osservazione 1: sacco di questa roba viene memorizzato in colonne di testo senza codificarlo utilizzando l'utf8 o set di caratteri utf8mb4. Molte? Sì. WordPress memorizza i dati delle opzioni in questo modo.
Osservazione 2: se può essere convertito in JSON, è possibile utilizzare il tipo di dati JSON nelle versioni recenti di MySQL. Le ricerche JSON non sono ancora sargable, ma sono strutturate.
fonte
2013-08-13 01:10:38
Poiché è * già * base64, perché non solo un CHAR/VARCHAR? BINARY, VARBINARY e BLOB sono modi adatti - a seconda - per memorizzare dati binari (non codificati Base64). Dal momento che sembra essere un valore piccolo, suggerirei BINARY vs. BLOB. – user2246674
geniale, per qualche motivo non ho pensato di usare Binary! :) –
Ah, a volte mi piace decodificare le cose pubblicate su SO. Si noti che con questo tipo di struttura, sarà problematico interrogare correttamente determinati dati da esso. – HamZa