Vilken "VARCHAR(255)-regel" syftar du på?
Varje databasleverantör är fri att implementera VARCHAR hur de vill. Reglerna (och riktlinjerna) för VARCHAR kommer inte nödvändigtvis att vara desamma för varje databas.
När det gäller SQL-standarden har jag inte riktigt tittat på den. Det kan vara ganska löst, så alla VARCHAR-implementationer befinns följa standarden. Om SQL-standarden för VARCHAR är riktigt strikt, kan DBMS-leverantörer antingen utöka standarden eller helt enkelt inte vara kompatibla. Jag tror inte att den faktiska standarden spelar så stor roll. Det som spelar roll är de faktiska reglerna som tillämpas av DBMS.
Vad gäller en allmän riktlinje, ange en VARCHAR-längd som är tillräckligt lång för att stödja systemkraven. Om systemets krav är att inte tillåta mer än 200 tecken, skulle jag ange längden som VARCHAR(200) .
Som en annan allmän riktlinje, definiera inte VARCHAR-längder som är större än de behöver vara. VARCHAR-kolumner som deklareras längre än nödvändigt kan påverka resurser och prestanda.
Oracle-gränsen för VARCHAR-längden är 4000 tecken. (I tidigare versioner av Oracle var maxvärdet 2000. Om du behöver mer än 4000 tecken kan du använda CLOB datatyp.
SQL Server-gräns till VARCHAR(8000) , om du inte anger VARCHAR(MAX) som tillåter en maximal storlek (i byte) på 2^32-1.
MySQL har en gräns på 65 535 för maximal radlängdsgräns. Så det begränsar effektivt storleken på VARCHAR till VARCHAR(21844), om du använder en multibyte-teckenuppsättning som utf8. Med en enkelbyte-teckenuppsättning (som latin1) skulle det maximala vara VARCHAR(65532). Om du behöver fler tecken än så, eller om du stöter på gränsen för den maximala radlängden, kan du använda TEXT-datatypen istället för VARCHAR.
De flesta DBMS VARCHAR-implementeringar lagrar ett "längd"-fält för en VARCHAR-kolumn, tillsammans med värdet. längden lagras som ett heltal.
I vissa DBMS, om den maximala längden (i byte) för en VARCHAR-kolumn inte överstiger 255 byte, kan längdfältet implementeras som ett enstaka byte heltal. Om kolumnen tillåter mer än 255 byte, måste längdfältet vara större än en enda byte.
Med dynamiska radformat, när det gäller radlagring, lagring av 10 tecken i en kolumn, spelar det ingen roll om kolumnen är definierad som VARCHAR(30) eller VARCHAR(1000). Med fasta radformat kommer utrymmet för kolumnens maximala längd att reserveras. Formatet för radlagringar kommer att bero på DBMS, och i vissa fall (MySQL) på lagringsmotorn och det angivna radformatet.
Ja, det är 2016. Och vi har kommit långt sedan introduktionen av det första kommersiella relationsdatabassystemet.
Databasen är bara en del av systemet. Det kan finnas begränsningar i programmet eller andra programvarukomponenter. (Om applikationen är skriven i C och applikationen definierar en struktur med en byte-array för fältet, kommer gränsen för storleken där att vara viktig. Att öka den tillåtna storleken i databasen kommer inte automatiskt att fixa applikationen .
Det kan också finnas längdbegränsningar/begränsningar i Javascript-kod eller i HTML-element på en webbsida. Eller så kan det finnas begränsningar för andra programvarukomponenter. Till exempel har några av de riktigt gamla SQL Server ODBC-drivrutinerna en gräns på 255 tecken (byte?) för både CHAR- och VARCHAR-kolumner.
Så längden på en VARCHAR i databasen är bara en del av historien.
Med allt detta sagt är jag fortfarande inte klar över vad du menar när du frågar
Kan vi bryta mot VARCHAR(255)-regeln?
Jag undrar vilken "regel" du syftar på. I nästan varje databas jag känner till är det möjligt att definiera VARCHAR-kolumner mycket längre än 255 byte eller 255 tecken. Och att göra det bryter inte mot någon regel.