För att svara:text är utfasad i många DBMS verkar det som, så det är bättre att använda antingen en blob eller en varchar med en hög gräns (och med blob får du inga kodningsproblem, vilket är ett stort krångel med varchar och text) .
Också som påpekats i den här tråden på MySQL-forumet , hårddiskar är billigare än mjukvara, så det är bättre att först designa din programvara och få den att fungera, och först då om utrymme blir ett problem, kanske du vill optimera den aspekten. Så försök inte att överoptimera storleken på din kolumn för tidigt, ställ in storleken större först (plus detta undviker säkerhetsproblem).
Om de olika kommentarerna:För mycket SQL-fanatism här. Trots att jag är väldigt förtjust i SQL och relationsmodeller har de också sina fallgropar.
Att lagra serialiserade data i databasen i befintligt skick (som att lagra JSON- eller XML-formaterade data) har några fördelar:
- Du kan ha ett mer flexibelt format för dina data:lägga till och ta bort fält i farten, ändra specifikationen för fälten i farten, etc...
- Mindre impedansmissanpassning med objektmodellen:du lagrar och hämtar data precis som den är i ditt program, jämfört med att hämta data och sedan behöva bearbeta och konvertera den mellan dina programobjekts strukturer och din relationsdatabas strukturer .
Och det finns många fler andra fördelar, så snälla, ingen fanboyism:relationsdatabaser är ett bra verktyg, men låt oss inte diska med de andra verktygen vi kan få. Fler verktyg, desto bättre.
När det gäller ett konkret exempel på användning, tenderar jag att lägga till ett JSON-fält i min databas för att lagra extra parametrar för en post där kolumnerna (egenskaperna) för JSON-data aldrig kommer att SELECT'd individuellt, utan endast används när rätt post är redan vald. I det här fallet kan jag fortfarande särskilja mina poster med relationskolumnerna, och när rätt post är vald kan jag bara använda de extra parametrarna för vilket syfte jag vill.
Så mitt råd att behålla det bästa från två världar (hastighet, serialiserbarhet och strukturell flexibilitet), använd bara några standardrelationskolumner för att fungera som unika nycklar för att skilja mellan dina rader, och använd sedan en blob/varchar-kolumn där din serialiserade data kommer att sättas in. Vanligtvis krävs bara två/tre kolumner för en unik nyckel, så detta kommer inte att vara någon större omkostnad.
Du kanske också är intresserad av PostgreSQL som nu har en JSON-datatyp och PostSQL-projektet för att direkt bearbeta JSON-fält precis som relationskolumner.