Pozd.

Poruka je dosta jasna. Ne mozhesh imati kljuch sa BLOB/TEXT poljem ako ne navedesh duzhinu tog polja u kljuchu. To znachi da ce kljuch uzimati u obzir samo prvih X karaktera takvog polja. Nisam siguran zbog chega ti je za polje USER_ID potreban tip TINYTEXT - u svakom sluchaju, nije preporuchljivo koristiti BLOB/TEXT polja u okviru FK, a i zbog optimizacije je preporuchljivo ovakve kljucheve imati samo sa ordinalnim tipovima podataka, kao shto je INT.


Svako dobro.

Slažem se sa Milanom. INT ključ je mnogo bolja ideja. Ali, ako baš mora primary key da bude tekstualan, daj koristi VARCHAR. TINYTEXT je isto što i VARCHAR 255 tako da ne vidim razlog za TINYTEXT kao primary ključ.
Takođe, sad sam u phpmyadminu probao da stavim primary key nad text poljem i ne mogu.

Pročitaj CREATE INDEX sintaxu i u najmanju ruku promeni polje u VARCHAR (255).

Ucinjeno - Doduse u VARCHAR(20) ali to je to,jer mi i ne treba vise. Moralo je tipa textualno polje jer je rec o Username-u ,a bilo bi besmisleno koristiti i user_id tipa INT i username tipa TINYTEXT/TEXT..

HVALA!

Pa nije bas besmisleno. Ako ne koristis username kao PK vec koristis za user_id koji takodje linkujes u drugim tabelama kao FK onda imas mogucnost promjene username-a. Ukoliko bi u tvom slucaju zelio promjeniti username-a, znaci update-ovati PK morao bi (u slucaju da koristis MyISAM) sam se pobrinuti da se i ostale tabele koje koriste taj PK budu update-ovane. A u slucaju da koristis InnoDB, ne znam da li je uopste i izvodljivo update-ovanje PKa ukoliko je koristen kao FK u relacijama.