[mysql] indexen wil niet helemaal

[Verwijderd]

code:

CREATE TABLE replys (
  threadid mediumint(6) NOT NULL default '0',
  replyid mediumint(7) NOT NULL auto_increment,
  status tinyint(1) NOT NULL default '2',
  timestamp int(10) NOT NULL default '0',
  userid smallint(5) NOT NULL default '0',
  content text NOT NULL,
  PRIMARY KEY  (replyid)
) TYPE=MyISAM;

Ik heb dus table replys, en nu wil ik de kolommen 'threadid' en 'replyid auto_increment' indexeren, omdat ik daar dus vaak op select.

Nou had ik dus eerst PRIMARY KEY (threadid,replyid) maar toen ging er wat mis, want wanneer threadid veranderde kon replyid wel weer vanaf 1 beginnen want samen waren ze weer uniek. Dat is dus niet de bedoeling.



Hoe indexeer ik deze tabel zo dat ik wel optimale snelheid heb, en 'replyid auto_increment' wel netjes doortelt ?

[whoami]

Verander je soms de waarden van je primary keys?

[Verwijderd]

Op dinsdag 25 juni 2002 10:46 schreef whoami het volgende:
Verander je soms de waarden van je primary keys?

Neeh daar heb ik niet aangezeten dat heeft ie zelf gedaan!

Is ook helemaal logisch, http://www.mysql.com/doc/e/x/example-AUTO_INCREMENT.html tweede voorbeeld.

[Goodielover]

zoek eens op CREATE (UNIQUE) INDEX

[Verwijderd]

dat voorbeeld is niet hetzelfde als bij jou hoor
tenzij jij ook een group by gebruikt in die select.... maar aangezien het hier om phpmyadmin (zo te zien) gaat is dat waarschijnlijk niet het geval.

Toch raar dat je PK hetzelfde getal heeft.... hij is nu niet meer uniek. Dit ligt niet aan auto_incr hoor

denk dat je toch ergens iets verkeerd doet

[Verwijderd]

Op dinsdag 25 juni 2002 10:54 schreef woeitje het volgende:
Toch raar dat je PK hetzelfde getal heeft.... hij is nu niet meer uniek. Dit ligt niet aan auto_incr hoor

Nogmaals, ik heb me PK over TWEE kolommen.

Dus dan heb je:
1 en 1
1 en 2
1 en 3

En daar passen
2 en 1
2 en 2
2 en 3

ook tussen, ze zijn nu TEZAMEN nog wel uniek.

[Janoz]

Maar dat wil je dus niet?

Lijkt me ook logisch om dat niet te hebben, daarnaast vraag ik me af waarom je threadid ook in je PK mee wilt nemen..

Let wel op, een primary key is wel een key, maar een key hoeft niet perse een primairy key te zijn.

Ik krijg het id dat wat jij wilt simpel te bereiken is door "KEY (threadid)" aan je create statement toe te voegen.

[ACM]

Je moet kiezen: per thread unieke replies of globaal.

Ik raad aan globaal, zodat je replies evt ooit nog kan moven naar andere threads en dat veeeel simpeler te beheersen is.
In dat geval kan je het best de primary key alleen op 'replyid' leggen en de voor de threadid een aparte index aanmaken.

Check in de inhoudelijke FAQ hier in P&W het stuk over indexeren.

Als je bijv op datum wilt sorteren kan het handig zijn daar ook nog eens een index op te leggen.
En als je vaak op userid wilt zoeken is het wellicht handig er ook nog een op userid te leggen.

[Verwijderd]

Op dinsdag 25 juni 2002 10:44 schreef Guanoape het volgende:
Nou had ik dus eerst PRIMARY KEY (threadid,replyid) maar toen ging er wat mis, want wanneer threadid veranderde kon replyid wel weer vanaf 1 beginnen want samen waren ze weer uniek. Dat is dus niet de bedoeling.

Op dinsdag 25 juni 2002 11:07 schreef Guanoape het volgende:

[..]

Nogmaals, ik heb me PK over TWEE kolommen.

Dus dan heb je:
1 en 1
1 en 2
1 en 3

En daar passen
2 en 1
2 en 2
2 en 3

ook tussen, ze zijn nu TEZAMEN nog wel uniek.

nu volg ik je niet meer
Je create table zegt dat alleen PK op replyid hebt. en daar ook auto_inc op hebt..... dan moet het normaal gesproken niet mogelijk zijn dat plaatje te krijgen wat jij aangeeft

Maarja of ik snap je vraag niet, of je snapt niet waar je mee bezig bent, of.... nog iets anders

[Verwijderd]

K thanx allemaal ik snap het nu. (weer wat geleerd)