---

Jeg har 2 char felter i min tabel.
Jeg vil gerne lave dem 255 som vist er max for et char fejl(?)

Men nå jeg prøver at opdatere det ene felt fra char 240 -> char 255 ja
så får jeg følgende fejl:

ALTER TABLE `kampe` CHANGE `hjemme` `hjemme` VARCHAR(255) DEFAULT "0"
Error: 1071 - Specificeret nøgle var for lang. Maksimal nøglelængde er
500

En der kan gemmeskue denne fejl?

---

> ALTER TABLE `kampe` CHANGE `hjemme` `hjemme` VARCHAR(255) DEFAULT "0"
> Error: 1071 - Specificeret nøgle var for lang. Maksimal nøglelængde er
> 500

Der skal ingen plinger omkring tabel- og kolonnenavne:

ALTER TABLE kampe MODIFY hjemme VARCHAR(255) DEFAULT '0';

--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"

---

On Thu, 18 Apr 2002 01:02:18 +0200, "Jakob Møbjerg Nielsen"
<vitz@cs.auc.dk> wrote:

>> ALTER TABLE `kampe` CHANGE `hjemme` `hjemme` VARCHAR(255) DEFAULT "0"
>> Error: 1071 - Specificeret nøgle var for lang. Maksimal nøglelængde er
>> 500
>
>Der skal ingen plinger omkring tabel- og kolonnenavne:
>
>ALTER TABLE kampe MODIFY hjemme VARCHAR(255) DEFAULT '0';

Det virker jo fint sådan her:

ALTER TABLE `kampe` CHANGE `hjemme` `hjemme` VARCHAR(255) DEFAULT "0"

HVIS bare VARCHAR er 240 eller mindre!

---

> HVIS bare VARCHAR er 240 eller mindre!

Har du lavet noget lignende:

UNIQUE (hjemme, ude)??

Her står noget om maksimal nøglelængde:
http://www.mysql.com/doc/M/y/MyISAM.html

Prøv at ændre tabellen til

UNIQUE (hjemme(250), ude(250))

--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"

---

On Thu, 18 Apr 2002 12:30:07 +0200, "Jakob Møbjerg Nielsen"
<vitz@cs.auc.dk> wrote:

>> HVIS bare VARCHAR er 240 eller mindre!
>
>Har du lavet noget lignende:
>
>UNIQUE (hjemme, ude)??
>
>Her står noget om maksimal nøglelængde:
>http://www.mysql.com/doc/M/y/MyISAM.html
>
>Prøv at ændre tabellen til
>
>UNIQUE (hjemme(250), ude(250))

De skal IKKE være unikke!

Og det virker helt fint hvis der er ET char(255) felt i databasen, men
hvis der er to eller flere ja så "skal" de være char(240)

Jeg vil tro det er en fejl i mysql-front (et GUI program)

---

> De skal IKKE være unikke!

Jamen, hvad har du lavet? Prøv engang at poste dit create table
statement herinde.

--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"

---

On Thu, 18 Apr 2002 13:57:02 +0200, "Jakob Møbjerg Nielsen"
<vitz@cs.auc.dk> wrote:

>> De skal IKKE være unikke!
>
>Jamen, hvad har du lavet? Prøv engang at poste dit create table
>statement herinde.

CREATE TABLE `kampe` (`id` TINYINT (3) UNSIGNED AUTO_INCREMENT,
`hjemmehold` CHAR (255),
`udehold` CHAR (255) DEFAULT '0',
PRIMARY KEY(`id`),
UNIQUE(`id`),
INDEX(`id`,`hjemmehold`,`udehold`))

også får jeg fejlen:

Error: 1071 - Specificeret nøgle var for lang. Maksimal nøglelængde er
500

Tabellen skal indeholde flg.

id (kampens id)
hjemmehold (hjemmeholdets navn)
udehold (udeholdets navn)

---

-Martin- <admin@natten-i.dk> skrev:

> INDEX(`id`,`hjemmehold`,`udehold`))

> Error: 1071 - Specificeret nøgle var for lang. Maksimal
> nøglelængde er 500

Så vidt jeg kan læse fejlmeddelelsen kan du ikke lave et index på
felter der tilsammen fylder mere end 500 bytes. I dit eksempel kan
du lave index på id (selvom det vel er overflødigt når det er
primærnøglen), id + hjemmehold eller udehold, samt felterne
hjemmehold og udehold hver for sig. Men du kan altså ikke lave et
kombineret index hvor både hjemmehold og udehold indgår.

Der er i øvrigt ikke megen idé i at have et kombineret indeks med
primærnøglen (p) som første element. Da p altid er unik, vil
indekset aldrig benytte de resterende felter.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)

---

On Thu, 18 Apr 2002 13:26:50 +0000 (UTC), "Jens Gyldenkærne Clausen"
<jc@dmf.dk> wrote:

>-Martin- <admin@natten-i.dk> skrev:
>
>> INDEX(`id`,`hjemmehold`,`udehold`))
>
>> Error: 1071 - Specificeret nøgle var for lang. Maksimal
>> nøglelængde er 500
>
>Så vidt jeg kan læse fejlmeddelelsen kan du ikke lave et index på
>felter der tilsammen fylder mere end 500 bytes. I dit eksempel kan
>du lave index på id (selvom det vel er overflødigt når det er
>primærnøglen), id + hjemmehold eller udehold, samt felterne
>hjemmehold og udehold hver for sig. Men du kan altså ikke lave et
>kombineret index hvor både hjemmehold og udehold indgår.
>
>Der er i øvrigt ikke megen idé i at have et kombineret indeks med
>primærnøglen (p) som første element. Da p altid er unik, vil
>indekset aldrig benytte de resterende felter.

Nå okei, jeg "troede" at når et felt var indexseret, så var det
hurtigere at bruge i forskellige joins osv.

Men måske ikke nå det er ID feltet vi snakker om?
Iøvrigt, så skal ID feltet bruges i 4-5 andre tabeller i samme
database. Også havde jeg læst mig frem til at det ville ændre
væsentligt på hastigheden hvis man havde index på det.

Men det er måske ligemeget?

Nu snakker vi godt nok kun <2-300 rækker.

Men hvornår skal man ellers bruge index (og fuldtekst på long***
felter?)

---

> Men hvornår skal man ellers bruge index (og fuldtekst på long***
> felter?)

INDEX (tekstfelt(500))

Det kræves på alle text og blob felter der skal indekseres.

--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"

---

-Martin- <admin@natten-i.dk> skrev:

>>Der er i øvrigt ikke megen idé i at have et kombineret indeks
>>med primærnøglen (p) som første element. Da p altid er unik,
>>vil indekset aldrig benytte de resterende felter.
>
> Nå okei, jeg "troede" at når et felt var indexseret, så var
> det hurtigere at bruge i forskellige joins osv.

Det er skam også rigtigt. Men et indeks læses altid "forfra". Dvs.
at når du indekserer flere felter, er rækkefølgen meget vigtig.

> Men måske ikke nå det er ID feltet vi snakker om?

Primary Key er et indeks i sig selv. Derfor er der ikke brug for at
lave et ekstra indeks på dit id-felt. Og da primærnøglen samtidig
er unik, opnår du ingenting ved at oprette flerfeltsindeks med
noget efter din primærnøgle.

> Iøvrigt, så skal ID feltet bruges i 4-5 andre tabeller i samme
> database. Også havde jeg læst mig frem til at det ville ændre
> væsentligt på hastigheden hvis man havde index på det.

Korrekt - men som nævnt er din primærnøgle også et indeks.


> Men hvornår skal man ellers bruge index

Du skal bruge indeks på felter der benyttes til joins og til
søgninger. Hvis din søgning eller join inkluderer flere felter kan
et flerfeltsindeks komme på tale. Søger man f.eks. ofte på fornavn
og efternavn kunne det være praktisk med et indeks á la
INDEX(efternavn, fornavn) - og så have en søgning med
efternavn=<værdi> AND fornavn=<værdi>.

Bemærk i øvrigt at dit indeks ikke kan benyttes hvis du indleder
søgekriteriet med et wildcard: efternavn LIKE '%havn%' kan ikke
benytte indeks, mens LIKE 'Hans%' godt kan.

> (og fuldtekst på long*** felter?)

Fuldtekst-indeksering kan klare nogle af problemerne med wildcards
- så hvis du ofte søger med dobbelte wildcard ('%<værdi>%') er det
måske en idé. Men med <300 rækker er det ikke sikkert det kan
betale sig. Eksperimentér evt. lidt, og se om du kan mærke forskel.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)

---

>Du skal bruge indeks på felter der benyttes til joins og til
>søgninger. Hvis din søgning eller join inkluderer flere felter kan
>et flerfeltsindeks komme på tale. Søger man f.eks. ofte på fornavn
>og efternavn kunne det være praktisk med et indeks á la
>INDEX(efternavn, fornavn) - og så have en søgning med
>efternavn=<værdi> AND fornavn=<værdi>.
>
>Bemærk i øvrigt at dit indeks ikke kan benyttes hvis du indleder
>søgekriteriet med et wildcard: efternavn LIKE '%havn%' kan ikke
>benytte indeks, mens LIKE 'Hans%' godt kan.
>
>> (og fuldtekst på long*** felter?)
>
>Fuldtekst-indeksering kan klare nogle af problemerne med wildcards
>- så hvis du ofte søger med dobbelte wildcard ('%<værdi>%') er det
>måske en idé. Men med <300 rækker er det ikke sikkert det kan
>betale sig. Eksperimentér evt. lidt, og se om du kan mærke forskel.

Ja så tror jeg næsten jeg har fattet det med index ... DAMN så er der
jo egentlig mange index felter som jeg egentlig ikk behøver :)

Men hvorfor så ikke gøre ALLE felter (foruden ID) til fuldtekst?
Fylder det mere eller?

---

> CREATE TABLE `kampe` (`id` TINYINT (3) UNSIGNED AUTO_INCREMENT,
> `hjemmehold` CHAR (255),
> `udehold` CHAR (255) DEFAULT '0',
> PRIMARY KEY(`id`),
> UNIQUE(`id`),

Denne er unødvendig. En primary key er det samme som unique, den må bare
ikke være NULL.

> INDEX(`id`,`hjemmehold`,`udehold`))

INDEX(hjemmehold(250), udehold(250))

Du bliver nødt til at rekompilere, hvis du vil have en nøgle der er
større end 500.

--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"

---

-Martin- <admin@natten-i.dk> skrev:

> De skal IKKE være unikke!
>
> Og det virker helt fint hvis der er ET char(255) felt i
> databasen, men hvis der er to eller flere ja så "skal" de være
> char(240)

Hvad er feltspecifikationerne på resten af felterne? Det burde ikke
være et problem med to char(255)-felter, men hvis du har en masse
pladskrævende felter kan det være et problem. Omtaler
dokumentationen en max row size (mrs)? Jeg kender ikke mySQL i SQL-
server er mrs = 8060 bytes i version 7 og fremefter, mens version
6.5 har mrs = 1962 bytes.


--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)