noget om et felts attributter

Jeg ville nok bruge DATETIME typen, men ellers er der 8 tegn i din streng altså
VARCHAR(8).

INT(5) betyder et heltal mellem minus 2 milliareder og plus 2 milliarder. Som hvis
MySQL skal vise den vil forsøge at vise med en felt bredde på 5.

Jeg forstår ikke helt den sidste der, arne.
felt-bredde ?

hvad er forskellen på int(2) og int(5) f.eks ?

Jeg har brugt mit lidt sære datoformat for at kunne sortere DESC, kan jeg det med DATETIME ? Jeg tænkte at hvis der står Mandag d. 17 September eller sådan noget, er det lidt kompliceret at få dem i kronologisk rækkefølge.

Hvis xxx er et felt af typen DATETIME så vil ORDER BY xxx virke.

Nu har jeg aldrig set den helt store effekt af den bredde.

Men ideern er at det angiver bredden tallet udskrives med.

SELECT a,b,c FROM t med feltbredde 2 bør give
1 2 3
4 5 6
7 8 9

mens det med feltbreded 5 bør give:
    1    2    3
    4    5    6
    7    8    9

Hvis så dateofentry er DATETIME, skal jeg så inserte med (php):

a) INSERT INTO blah(dateofentry) VALUES('time()') ??

b) og hvad får jeg tilbage når jeg selecter fra det felt ?

c) Hvis jeg vil have mulighed for at gemme/hente f.eks et tal fra 0-1000, er det så ligemeget om jeg skriver int(1) eller int(47) ?

:) Lav din kommentar til et svar i samme omgang

re c)

Ja

I selve MySQL vil den blive vist pænest i f.eks. INT(4), men din PHP/ASP/whatever
applikation er helt ligeglad.

re a & b)

En DATETIME !

:-)


Du kan indsætte i bl.a. formatet:

'yyyy-mm-dd'

Når du henter ud er det normalt ikke et problem.

Hvis det sprog du udvikler i understøtter parameters, så kan du helt undgå
format problemerne.

Som jeg skrev øverst i spørgsmålet, indsætter jeg nu som varchar med yy-mm-dd, du anbefaler at bruge DATETIME, her nederst foreslår du så formatet yyyy-mm-dd (det "samme" som min indledning), så forstår jeg ikke pointen i at bruge DATETIME i stedet for. Jeg troede lige der var et eller andet smart ved det ?!

Men anyway, konklusionen er at tallet i parantesen efter int bør bruges som længden af de ønskede værdier, men jeg kan sagtens gemme tallet 2524234 i en int(1). OK !

Jeg beholder min varchar(8) tror jeg, og prøver at forsvare det ved den kommende eksamen... Jeg kan ikke helt se pointen i DATETIME.

Mange tak for hjælpen endnu en gang :)

Der er nu flere fordele ved DATETIME.

Der er en hel stribe smarte funktioner som kan manipulere DATETIME
værdier.

Den checker delene er valid. Du kan sagtens læse '2004-02-31' ind
i en VARCHAR, men ikke i en DATETIME.

Du kan (i visse sprog) bruge parameters og helt undgå format
problemerne.

Etc.etc..

ok, så kan jeg godt se forskellen. Men det er da sjovt at du ikke kan indlæse '2004-02-31' som du siger, for hvis man nu var interesseret i år, time og minut, skulle det jo være muligt... Men hvad hulen :P

Jeg ved desværre ikke hvad du mener med de parameters.

Det er noget det gør at man kan indlæse tiden som et binært objekt og
ikke som en tekst streng.

MySQL kan også godt forstå yy-mm-dd, så du behøver ikke skrive din dato anderledes, for at putte ind i et DATETIME-felt.

Det rigtigt smarte ved et DATETIME-felt er, at det kan MySQL umiddelbart sortere og beregne på med diverse funktioner. (Da netop din varchar-variant umiddelbart kan oversættes til en DATETIME-værdi kan de fleste funktioner nok også arbejde med den, men jeg vil tro, at en rigtig DATETIME vil være hurtigere at arbejde med, da indholdet så ikke først skal fortolkes og oversættes til en rigtig DATETIME.)

Hele årsagen til at jeg bruger det lidt sære format yy-mm-dd er at man kan trykke på en knap, og så bliver der sorteret efter dette. Et andet sted i samme system, bliver datoen vist som dd/mm - yy. Så der bliver substringet lidt osv. Jeg tror ikke datetime datatypen kan bedre dette, men hvis den kan - vil jeg da naturligvis gerne høre mere... :) Tak for input