[SQL] Varchar lengte wel/niet limiteren

[Foeijonghaai]

Bij Postgres (en vermoedelijk ook bij de andere fabrikanten) kun je bij varchars er ook voor kiezen geen maximale lengte op te geven. Ook is er het type 'text', maar die zit niet in de SQL standaard. Zie ook: http://www.postgresql.org...e/datatype-character.html

Voor jullie wellicht bekend, voor mij een niet eerder ontdekte mogelijkheid.

Ik heb relatief veel kolommen waar een tekst opgeslagen kan worden waarvoor een bepaalde maximale lengte niet altijd voor de hand ligt. Dus het lijkt me wel een goed idee om die kolommen aan te passen waar geen goede maximum lengte voor de hand ligt, naar kolommen zonder maximum lengte. Dat scheelt ook weer gevalideer op lengtes in formulieren.

Maar ik zit er ook niet op te wachten dat men straks complete verhalen in bepaalde invoervelden kwijt kan.

Voordat ik in blinde paniek al mijn kolommen ga aanpassen, vroeg ik me af wat nu best practice is: wel of geen vaste lengte voor teksten in een database.

Ik zie nu de volgende voordelen:

• geen willekeurig gekozen maximale lengtes
• databasemodel hoeft niet aangepast te worden bij gebleken noodzaak opgerekte maximale lengte
• geen validatie op die willekeurig gekozen maximale lengtes in mijn formulieren

Ik zie nu de volgende nadelen:

• totaal geen (lengte) validatie meer op de invoer, waardoor hele verhalen mogelijk zijn waardoor je mogelijk weer problemen krijgt bij het tonen van die informatie.

Zoeken op internet levert eigenlijk dezelfde informatie op als de handleiding van postgres: je kan een max opgeven, je kan het ook laten. Maar afwegingen kom ik niet tegen.

Wat zijn jullie ervaringen?

[Gamebuster]

Validatie op lengte is iets dat je niet op database-niveau wil doen, lijkt mij. Je wilt de gebruiker een nette melding geven; Ik weet niet hoe Postgres zijn fouten afhandelt, maar als je in MySQL "te lange" data in een "te klein" veld propt, verdwijnen de bytes/chars die niet passen in een zwart gat zonder melding.

Verder, als opeens blijkt dat de validatie gewijzigd moet worden, wil je dit niet op database niveau moeten aanpassen. Stel dat je na een jaar besluit dat gebruikersnamen geen 12 maar 10 tekens max mogen zijn. Jij past het aan in de database en opeens zijn alle bestaande gebruikersnamen langer dan 10 tekens "afgesneden" (of je kan 'm niet meer verkleinen, afhankelijk van het gedrag van de DB; MySQL snijdt zonder pardon je data af.)

Ik vind dat je dit soort validaties op controller-niveau moet afhangen, niet database niveau. Zo kan je de gebruiker veel makkelijker nette feedback geven.

Verder, ik weet niet hoe het met varchar zit, maar alle database types hebben een max grootte. Bij TEXT is dat AFAIK 65535 tekens (of bytes?). Bij varchar is dat 255 of 65535. Bij MEDIUMTEXT is het 16.777.216, enz.

Persoonlijk gebruik ik een database puur om data op te slaan, niet om relaties of validaties bij te houden. Dit laat ik doen door het model of de controller.

[ Voor 18% gewijzigd door Gamebuster op 05-11-2012 16:00 ]

[Foeijonghaai]

Gamebuster schreef op maandag 05 november 2012 @ 15:57:
Validatie op lengte is iets dat je niet op database-niveau wil doen, lijkt mij. Je wilt de gebruiker een nette melding geven; Ik weet niet hoe Postgres zijn fouten afhandelt, maar als je in MySQL "te lange" data in een "te klein" veld propt, verdwijnen de bytes/chars die niet passen in een zwart gat zonder melding.

Verder, als opeens blijkt dat de validatie gewijzigd moet worden, wil je dit niet op database niveau moeten aanpassen. Stel dat je na een jaar besluit dat gebruikersnamen geen 12 maar 10 tekens max mogen zijn. Jij past het aan in de database en opeens zijn alle bestaande gebruikersnamen langer dan 10 tekens "afgesneden" (of je kan 'm niet meer verkleinen, afhankelijk van het gedrag van de DB)

Ik vind dat je dit soort validaties op controller-niveau moet afhangen, niet database niveau. Zo kan je de gebruiker veel makkelijker nette feedback geven.

Ik beweer nergens dat ik de validatie in de database doe.

Verder heb ik het over velden waarbij een maximale lengte niet voor de hand ligt. Je voorbeeld met gebruikersnamen lijkt me daar buiten te vallen.

Ik doel meer op velden als 'description', 'note', 'logmessage'. Het is onzinnig om ze te kort in te stellen maar een maximum is ook al snel beperkend.

[Gtoniser]

Ik weet van MySQL in ieder geval dat TEXT anders wordt afgehandeld dan VARCHAR qua opslag. Het is een idee om dit ook van postgres op te zoeken, het kan nog wel eens wat uitmaken qua performance misschien (en ik denk dat je daar dus ook een goede reden kunt vinden voor het gebruik van de ene of juist de andere).

[Foeijonghaai]

Gtoniser schreef op maandag 05 november 2012 @ 16:09:
Ik weet van MySQL in ieder geval dat TEXT anders wordt afgehandeld dan VARCHAR qua opslag. Het is een idee om dit ook van postgres op te zoeken, het kan nog wel eens wat uitmaken qua performance misschien (en ik denk dat je daar dus ook een goede reden kunt vinden voor het gebruik van de ene of juist de andere).

In de Postgreshandleiding staat daarover het volgende:

Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

En charactery varying heeft dan weer een voorkeur (volgens mij) want 'text' staat niet in de SQL-standaard.

Alhoewel performance belangrijk is, ben ik op zoek naar wat in de praktijk beter uitpakt.

Performanceproblemen kan ik altijd nog oplossen als ze aandienen.

[leuk_he]

Het ligt simpelweg aan de rest van je tooling. Als er verderop in je tools dingen zijn die wel een maximum lengte hebben, en waar dus output kwijt zou raken dan wil je een limiet op het veld zetten.

[Gomez12]

leuk_he schreef op maandag 05 november 2012 @ 16:25:
Het ligt simpelweg aan de rest van je tooling. Als er verderop in je tools dingen zijn die wel een maximum lengte hebben, en waar dus output kwijt zou raken dan wil je een limiet op het veld zetten.

Dit... plus dat het afhankelijk is van je sleutels etc.

Je wilt geen sleutels gaan bouwen met text-velden / varchar(max). Terwijl imho een sleutel nog wel te bouwen is met een varchar(x).

In principe ben ik over het algemeen van mening dat je velden een max-lengte moet kunnen geven, kan je dit niet dan dump je er gewoon maar wat in en hoop je op het beste
Maar of ik ze ook daadwerkelijk op een lengte zet is afhankelijk van een heleboel dingen maar dan spelen er veelal ook meer dingen mee (als dat varchar in sommige situaties slechter/onvoorspelbaarder reageert dan char etc net afhankelijk van of je je row-size afhankelijk maakt van de db-leafsize etc)

Maar zeker velden als logmessage zou ik bijna per definitie een lengte meegeven. Dat moet geen onvoorspelbare grotere lengtes opleveren.

En test alles echt 100% goed door, met vaste lengtes kan je simpelweg testen of als je max-lengte in de dbase invoert of je dan ook max-lengte kan zoeken in je zoekmachine bijv. Maar met variabele velden is dat al wat moeilijker (en ik weet nog wel een zoek-implementatie waar standaard een max van 255 chars per woord in zit altijd leuk om 300 tekenwoorden wel in je dbase te hebben staan maar er niet op kunnen zoeken)

[RobIII]

Gamebuster schreef op maandag 05 november 2012 @ 15:57:
Persoonlijk gebruik ik een database puur om data op te slaan, niet om relaties of validaties bij te houden. Dit laat ik doen door het model of de controller.

Validaties; prima (tot op bepaalde hoogte). Relaties: WTF? Dat is nou precies waar een RDBMS goed in is (En, ja, zélfs MySQL kan dat beter dan jij kunt). En zet je MySQL in strict mode dan worden 'strings die niet passen' ook netjes teruggemeld met een error.

[ Voor 16% gewijzigd door RobIII op 05-11-2012 21:09 ]

[Down]

Gamebuster schreef op maandag 05 november 2012 @ 15:57:
Validatie op lengte is iets dat je niet op database-niveau wil doen, lijkt mij. Je wilt de gebruiker een nette melding geven; Ik weet niet hoe Postgres zijn fouten afhandelt, maar als je in MySQL "te lange" data in een "te klein" veld propt, verdwijnen de bytes/chars die niet passen in een zwart gat zonder melding.

Je kunt natuurlijk prima integriteit afdwingen in je database, de validatie kun je nog steeds elders doen. En dat MySQL het blijkbaar standaard zo doet geeft natuurlijk al te denken. Maar ja, als je database nog niet eens GROUP BY fatsoenlijk afhandelt..

[CubicQ]

Foeijonghaai schreef op maandag 05 november 2012 @ 16:15:
[...]

In de Postgreshandleiding staat daarover het volgende:

[...]

En charactery varying heeft dan weer een voorkeur (volgens mij) want 'text' staat niet in de SQL-standaard.

Alhoewel performance belangrijk is, ben ik op zoek naar wat in de praktijk beter uitpakt.

Performanceproblemen kan ik altijd nog oplossen als ze aandienen.

Hoewel het lang geleden is dat ik met Postgres gewerkt heb (7.4) en ik dus geen praktijkcijfers heb, is de opmerking in de documentation toch iets wat ik enigszins betwijfel. Bij een char / varchar wordt de data in de page zelf opgeslagen, met een text wordt een pointer opgeslagen, en heb je dus een extra indirectie. Aan de andere kant zorgt dit wel weer voor kleine records zelf. In DB2 kan je dit soort LOB's (Large Objects) ook in een specifieke tablespace opslaan, dat zou ook nog een overweging kunnen zijn. Dus of het positief of negatief is qua performance is afhankelijk van de situatie, maar kan me niet voorstellen dat het 'hetzelfde' is.

Wanneer je gewoon een notitie-veldje opslaat, met maximaal een paar gebruikers en <10M records hebt ofzo zijn ga je het verschil waarschijnlijk qua performance niet echt merken. Dus performance zou voor mij in eerste instantie geen reden zijn (en stel je maakt op dit moment de verkeerde keuze, dan refactor je je database zo dat je het veld achteraf omzet).

Niet in SQL standaard zou ik niet heel erg relevant vinden in dit geval (in z'n algemeenheid vind ik het een goed punt om daar rekening mee te houden!). Alle relevante RDMSen ondersteunen Text / CLOB velden. Ook JDBC ondersteunt het.

Nou een praktijk-tip (niet Postgres specifiek): vermijd CLOB's indien mogelijk; backups zien het als uitzondering, meeste SQL tools tonen inhoud niet, bij Oracle / JDBC moet je allerlei trucs uithalen om data te updaten.