char blijft 1 lang ipv 30

[Verwijderd]

Besten,

Ik heb een hele simpele database gebouwd in SQLyog.
Dit om te oefenen met querys. So far so good.

Echter als ik zeg:
Select straat
From adressen

krijg ik als resultaat:

Straat
---------
a
d
k
o

ipv van
Straat
--------
Amsterdamseweg
Dorpstraat
Kalverstraat
Oosterse dwarsstraat

Het zal iets met char zijn maar die heb ik op 30 staan...

Weet iemand wat ik moet doen?

[mcdronkz]

Wat is je reden om CHAR boven VARCHAR te verkiezen?

[DrEvil1986]

Heb je bij de database creation statements aangegeven, dat er bv. char(99) is, zodat stadsnamen in de database passen?

Als er geen plek is voor alle letters, kapt SQL wrs gewoon af.

[ReenL]

Wat is je tabelstructuur? Char gaat uit van een vaste lengte (en vult eventueel aan met spaties), varchar van een variable lengte, waarbij het maximum gespecificeerd wordt tijdens het aanmaken van een tabel.

[Verwijderd]

mcdronkz schreef op zaterdag 22 januari 2011 @ 23:12:
Wat is je reden om CHAR boven VARCHAR te verkiezen?

ik had niet aan varchar gedacht? hetwerkt volgensmij wel...ik ga eens rommelen..

de reden wat dit uit de stencils van school..

****
naam char(30) Not Null
*****

[ReenL]

Heb je toevallig geinsert toen het nog een char(1) was?

Probeer ze eens opnieuw te inserten en daarna uit te lezen.

[Wolfboy]

In nagenoeg alle gevallen is varchar een beter idee dan char. Alleen als je zeker weet dat je altijd precies X tekens (denk aan postcodes bijvoorbeeld) nodig hebt is het een slecht idee.

Vertel voor het gemak ook wat voor database je gebruikt (MS SQL, PostgreSQL, MySQL, welke versie, etc...). Afhankelijk van je database zal die namelijk wel/geen waarschuwing geven op het inserten van meer karakters dan de tabel toelaat.

[Verwijderd]

mensen het gaat goed. Varchar doet het. Mijn kennis is nog niet van dien aard dat ik het met char kan.
Er staan ook prijzen in en die rond hij af naar boven. Dus waar ik dacht dat er 2,75 moest staan staat er gewoon 3...

[Gomez12]

Wolfboy schreef op zaterdag 22 januari 2011 @ 23:23:
In nagenoeg alle gevallen is varchar een beter idee dan char. Alleen als je zeker weet dat je altijd precies X tekens (denk aan postcodes bijvoorbeeld) nodig hebt is het een slecht idee.

Ach, dan heb je je postcode in char(6) staan en dan besluit er weer eens iemand om ook buitenlandse adressen op te nemen...

Let er met varchar enkel op dat je db dit ook goed ondersteunt, antieke / exotische dbases willen zo af en toe nog steeds sneller zijn met char dan varchar.

[ReenL]

Dan is weer de vraag welk datatype je voor die kolom gebruikt hebt. Welke database engine is ook wel handig.

[krvabo]

Verwijderd schreef op zaterdag 22 januari 2011 @ 23:28:
mensen het gaat goed. Varchar doet het. Mijn kennis is nog niet van dien aard dat ik het met char kan.
Er staan ook prijzen in en die rond hij af naar boven. Dus waar ik dacht dat er 2,75 moest staan staat er gewoon 3...

Wellicht zou jezelf even inlezen in data types geen slecht idee zijn.
Toevallig daar INT gebruikt?
Probeer daar eens een Decimal of een Double. Let er hierbij wel op dat:

A DECIMAL(M,D) column permits at most M - D digits to the left of the decimal point.

DECIMAL(4,2) heeft dus als formaat 99.99 en niet 9999.99

[Wolfboy]

Gomez12 schreef op zaterdag 22 januari 2011 @ 23:32:
[...]

Ach, dan heb je je postcode in char(6) staan en dan besluit er weer eens iemand om ook buitenlandse adressen op te nemen...

In dat geval moet je ook met varchar je tabel toch al wijzigen. Ook een varchar ondersteund niet meer dan z'n max

[Olaf van der Spek]

Wolfboy schreef op zondag 23 januari 2011 @ 00:33:
In dat geval moet je ook met varchar je tabel toch al wijzigen. Ook een varchar ondersteund niet meer dan z'n max

Met varchar heb je minder reden een laag maximum te kiezen.

[Cartman!]

Het kan wel degelijk handig zijn om CHAR te gebruiken boven VARCHAR. Als je veel te maken hebt met updates en verschillende lengtes van input dan kan het zijn dat er meer fragmentatie optreedt in je files. Met een CHAR reserveer je altijd al een bepaalde hoeveelheid. Dit stond zo uitgelegd in (zeg ik even uit m'n hoofd) High Performance MySQL. Misschien is dit specifiek voor MySQL hoor, dat kan

[Remus]

Cartman! schreef op maandag 24 januari 2011 @ 19:28:
Het kan wel degelijk handig zijn om CHAR te gebruiken boven VARCHAR. Als je veel te maken hebt met updates en verschillende lengtes van input dan kan het zijn dat er meer fragmentatie optreedt in je files. Met een CHAR reserveer je altijd al een bepaalde hoeveelheid. Dit stond zo uitgelegd in (zeg ik even uit m'n hoofd) High Performance MySQL. Misschien is dit specifiek voor MySQL hoor, dat kan

Dat is echt een implementatie detail die misschien specifiek voor MySQL geldt (en dan verwacht ik dat het niet voor InnoDB geldt). Vaak worden CHAR en VARCHAR in de database hetzelfde (of iig vergelijkbaar) opgeslagen, alleen bij het materialiseren van de gegevens wordt in het geval van CHAR dan gepad met spaties tot de lengte van het veld.

[Olaf van der Spek]

Remus schreef op dinsdag 25 januari 2011 @ 09:40:
alleen bij het materialiseren van de gegevens wordt in het geval van CHAR dan gepad met spaties tot de lengte van het veld.

Dat is juist andersom.

[Remus]

Olaf van der Spek schreef op dinsdag 25 januari 2011 @ 10:26:
[...]

Dat is juist andersom.

Wat bedoel je?

[Cartman!]

Een CHAR krijgt padding. Maar het grote verschil is dat bij een VARCHAR de lengte van het veld bij het record wordt opgeslagen en bij een CHAR zit dat in de tabeldefinitie. CHAR(6) = 6 bytes, VARCHAR(6) gevuld met 6 karakters = 7 bytes.

Zie ook http://dev.mysql.com/doc/refman/5.0/en/char.html Wederom: dit is voor MySQL.

[alienfruit]

Ik vraag mij of is er eigenlijk een 'standaard' of best practice qua opslag van adresgegevens?

[Remus]

Cartman! schreef op dinsdag 25 januari 2011 @ 11:57:
Een CHAR krijgt padding. Maar het grote verschil is dat bij een VARCHAR de lengte van het veld bij het record wordt opgeslagen en bij een CHAR zit dat in de tabeldefinitie. CHAR(6) = 6 bytes, VARCHAR(6) gevuld met 6 karakters = 7 bytes.

Zie ook http://dev.mysql.com/doc/refman/5.0/en/char.html Wederom: dit is voor MySQL.

Volgens mij gaat de definitie van CHAR juist om de output, niet om de storage, maar bij MySQL lijkt het dus andersom en alleen om de storage te gaan.

De SQL-92 paragraaf 9.1: Retrieval Assignment stelt in ieder geval:

c) If the data type of T is fixed-length character string with
length in characters L, and the length in characters M of V
is smaller than L, then the first M characters of T are set
to V, and the last L-M characters of T are set to <space>s.

[ Voor 24% gewijzigd door Remus op 25-01-2011 14:23 ]

[Olaf van der Spek]

Remus schreef op dinsdag 25 januari 2011 @ 10:30:
Wat bedoel je?

De input/output wordt getrimd (conceptueel). Anders zou een where name = 'Olaf' niet werken voor een char(99).
De implementatie gebruikt (waarschijnlijk) spaties als opvulling.

[Olaf van der Spek]

alienfruit schreef op dinsdag 25 januari 2011 @ 12:18:
Ik vraag mij of is er eigenlijk een 'standaard' of best practice qua opslag van adresgegevens?

Qua veldtypen? Ik zou gewoon varchar(255) gebruiken met inputvalidatie in de app zelf.

[Remus]

Olaf van der Spek schreef op dinsdag 25 januari 2011 @ 15:00:
[...]

De input/output wordt getrimd (conceptueel). Anders zou een where name = 'Olaf' niet werken voor een char(99).
De implementatie gebruikt (waarschijnlijk) spaties als opvulling.

En dat is dus niet waar het trimmen is incorrect gedrag van de kant van MySQL. Eveneens uit SQL92 (8.2 Comparison predicate):

3) The comparison of two character strings is determined as fol-
lows:

a) If the length in characters of X is not equal to the length
in characters of Y, then the shorter string is effectively
replaced, for the purposes of comparison, with a copy of
itself that has been extended to the length of the longer
string by concatenation on the right of one or more pad char-
acters, where the pad character is chosen based on CS. If
CS has the NO PAD attribute, then the pad character is an
implementation-dependent character different from any char-
acter in the character set of X and Y that collates less
than any string under CS. Otherwise, the pad character is a
<space>.

[ Voor 30% gewijzigd door Remus op 25-01-2011 15:48 ]

[Olaf van der Spek]

Remus schreef op dinsdag 25 januari 2011 @ 15:46:
En dat is dus niet waar het trimmen is incorrect gedrag van de kant van MySQL. Eveneens uit SQL92 (8.2 Comparison predicate):

Wat is het effectieve verschil dan?

[Remus]

In geval van een comparison in principe niets, maar bij opvragen via een query dus wel (aangezien MySQL blijkbaar dan de spaces trimt wat niet hoort).

[Gomez12]

Cartman! schreef op maandag 24 januari 2011 @ 19:28:
Het kan wel degelijk handig zijn om CHAR te gebruiken boven VARCHAR. Als je veel te maken hebt met updates en verschillende lengtes van input dan kan het zijn dat er meer fragmentatie optreedt in je files. Met een CHAR reserveer je altijd al een bepaalde hoeveelheid. Dit stond zo uitgelegd in (zeg ik even uit m'n hoofd) High Performance MySQL. Misschien is dit specifiek voor MySQL hoor, dat kan

Nee, in principe geldt het (tot op zekere hoogte) voor elke dbase.
Char(30) is gewoon altijd 30 karakters ( in de betreffende karakterset ) ongeacht inhoud.
Varchar(30) is hooguit 30 karakters gereserveerd maar db moet er wel nog even de exacte lengte bijlezen (extra actie)

In theorie is varchar dus langzamer. In de praktijk wordt dit oa ruimschoots vergoedt door huidige hardware etc. Op een 286 maakt die extra handeling veel uit, op een hedendaagse computer niet meer.
Totdat je op een gegeven moment boven een bepaalde belasting komt, dan maakt het performance wijs weer iets uit. Maar wordt die performancewinst weer teniet gedaan door caching etc (er passen veelal meer varchars in het geheugen. Een char(255) kost altijd en overal 255 karakters)

Bij echt high High Performance SQL kan je misschien een extra 1% winnen door char te gebruiken ipv varchar, enkel moet je dan wel 100% van je char compleet gevuld hebben en je hebt redelijk wat op te ruimen aan de app kant omdat opeens alles binnenkomt als char(30) ook al staat er 1 teken in.

[Cartman!]

Gomez12 schreef op dinsdag 25 januari 2011 @ 20:37:
[...]

Nee, in principe geldt het (tot op zekere hoogte) voor elke dbase.
Char(30) is gewoon altijd 30 karakters ( in de betreffende karakterset ) ongeacht inhoud.
Varchar(30) is hooguit 30 karakters gereserveerd maar db moet er wel nog even de exacte lengte bijlezen (extra actie)

Zover ik het heb begrepen is dat dus niet zo. Een varchar(255) reserveert niet daadwerkelijk die 255 maar een variabel aantal bij insert/update. Als het nu dus 10 byte inneemt en na een update 20 byte dan gooit ie die 10 byte ergens anders neer, fragmentatie en daarmee verlies in performance. Correct me if i'm wrong maar dit stond dus in het boek van O`Reilly herinner ik me.

Bij echt high High Performance SQL kan je misschien een extra 1% winnen door char te gebruiken ipv varchar, enkel moet je dan wel 100% van je char compleet gevuld hebben en je hebt redelijk wat op te ruimen aan de app kant omdat opeens alles binnenkomt als char(30) ook al staat er 1 teken in.

Niet perse, als jij bijv. codes binnen krijgt die 5 of 6 karakters lang zijn heeft CHAR(6) al voorkeur, ja... je slaat bij de 5 een extra space op, maar anders krijg je bij de 5 en de 6 een extra byte voor de length.

[ Voor 3% gewijzigd door Cartman! op 25-01-2011 23:32 ]

[Gomez12]

Cartman! schreef op dinsdag 25 januari 2011 @ 23:31:
[...]
Zover ik het heb begrepen is dat dus niet zo. Een varchar(255) reserveert niet daadwerkelijk die 255 maar een variabel aantal bij insert/update. Als het nu dus 10 byte inneemt en na een update 20 byte dan gooit ie die 10 byte ergens anders neer, fragmentatie en daarmee verlies in performance. Correct me if i'm wrong maar dit stond dus in het boek van O`Reilly herinner ik me.

Bij de simpelste implementaties doet hij het zo. Bij de huidige implementaties heb je geen used-space fragmentation meer. Hij pakt gewoon het hele record, markeert het als deleted en insert een nieuw record waar wel genoeg ruimte is.
Dan heb je enkel wat free-space fragmentation, waar je weer tools voor hebt om dit periodiek op te ruimen.