[MySQL] Type Primary Key?

[CaptBiele]

Ik ben nu een paar dagen met MySQL 4.0.18 aan de gang, en ik heb het volgende opzetje gemaakt voor een van mijn tabellen:

MySQL:

CREATE TABLE Test(
CmpId MEDIUMINT UNSIGNED ZEROFILL AUTO_INCREMENT PRIMARY KEY,
Sequence CHAR (3) NOT NULL,
StartDate DATE NOT NULL, 
BlockedYn BOOL NOT NULL);

Alleen nu zit ik te twijfelen welk type ik moet kiezen voor mijn primary key (CmpID).
Het is een integer van 6 getallen, niet meer en niet minder.
Nu weet ik dat als ik hem als integer declareer, het sneller werkt... ik weet alleen niet hoe ik er voor kan zorgen dat het getal ook altijd 6 cijfers bevat.
Moet ik het dan per se als CHAR(6) declareren?

Verder neem ik aan dat het een algemene regel is dat je de velden moet declareren als types waar ze voor gebruikt worden, zoals bij een boolean veld BOOL in plaats van CHAR(1). Zijn hier ook tegen argumenten voor te bedenken?

Laatste subvraag: ik zie vaker in voorbeelden dat er gebruik gemaakt wordt van een AutoNumber als primary key. Wat is hier precies het voordeel van?

tnx guys!

[whoami]

Het bevat altijd 6 cijfers? Dus 1 wordt bv 000001 ?
Als dat het geval is, dan zou ik een CHAR nemen; 000001 wordt nl. als 1 opgeslagen in een integer veld.

Daarnaast vind ik het zowiezo geen goed idee om een veld dat 'betekenis' heeft als PK te gaan gebruiken. IMO gebruik je beter een extra-veldje (bv. een autonumber veld) die enkel gebruikt wordt als PK, en waarvan de inhoud er eigenlijk niet toe doet, zolang het maar uniek is.
Met autonummer-velden ben je dus zeker dat je een unieke waarde krijgt binnen die tabel.

[NMe]

CaptBiele schreef op 27 april 2004 @ 11:04:
Alleen nu zit ik te twijfelen welk type ik moet kiezen voor mijn primary key (CmpID).
Het is een integer van 6 getallen, niet meer en niet minder.
Nu weet ik dat als ik hem als integer declareer, het sneller werkt... ik weet alleen niet hoe ik er voor kan zorgen dat het getal ook altijd 6 cijfers bevat.
Moet ik het dan per se als CHAR(6) declareren?

Als je auto increment waarden wil, dan kun je bij mijn weten niet met char werken, alleen met numerieke waarden.

CaptBiele schreef op 27 april 2004 @ 11:04:
Verder neem ik aan dat het een algemene regel is dat je de velden moet declareren als types waar ze voor gebruikt worden, zoals bij een boolean veld BOOL in plaats van CHAR(1). Zijn hier ook tegen argumenten voor te bedenken?

BOOL is geen gegevenstype van MySQL bij mijn weten, ik gebruik meestal een ENUM('T','F').

CaptBiele schreef op 27 april 2004 @ 11:04:
Laatste subvraag: ik zie vaker in voorbeelden dat er gebruik gemaakt wordt van een AutoNumber als primary key. Wat is hier precies het voordeel van?

Dat je het nummer niet zelf hoeft te berekenen en dat het altijd uniek is natuurlijk, lijkt me logisch.

[mr_taipan]

Ik weet niet waarmee je deze table gaat gebruiken maar als je 6 cijfers wilt dan vul je het cijfer wat je opgehaald hebt aan met nullen.

als je bijvoorbeeld 12 hebt maak je daar een string van

en dan vul je die aan met nullen en dan word het 000012.

000012 zul je volgens mij alleen in een string op kunnen slaan omdat bij een int de voorste nullen wegvallen.

en autoincrement is handig omdat je dan altijd unike waarden in je tabel hebt en dat is gewoon handig

[CaptBiele]

whoami schreef op 27 april 2004 @ 11:07:
Het bevat altijd 6 cijfers? Dus 1 wordt bv 000001 ?
Als dat het geval is, dan zou ik een CHAR nemen; 000001 wordt nl. als 1 opgeslagen in een integer veld.

Daarnaast vind ik het zowiezo geen goed idee om een veld dat 'betekenis' heeft als PK te gaan gebruiken. IMO gebruik je beter een extra-veldje (bv. een autonumber veld) die enkel gebruikt wordt als PK, en waarvan de inhoud er eigenlijk niet toe doet, zolang het maar uniek is.
Met autonummer-velden ben je dus zeker dat je een unieke waarde krijgt binnen die tabel.

Ja daarom had ik die ZEROFILL optie gebruikt, om er voor te zorgen dat het automagisch met nullen wordt opgevuld.

Maar als ik de primary key met AUTO_INCREMENT gebruik, is die toch ook altijd uniek? ik zie het probleem niet zo

NME84: BOOL bestaat wel. En vanaf 4.1.0 bestaat BOOLEAN ook

[Gert]

Daar is zerofill voor. MySql vult het getal dan op met 0'en tot de gewenste lengte.

[whoami]

mr_taipan schreef op 27 april 2004 @ 11:10:
Ik weet niet waarmee je deze table gaat gebruiken maar als je 6 cijfers wilt dan vul je het cijfer wat je opgehaald hebt aan met nullen.

als je bijvoorbeeld 12 hebt maak je daar een string van

en dan vul je die aan met nullen en dan word het 000012.

Dat vind ik een slecht idee. Op die manier maak je een koppeling tussen je data en je presentatie-laag.
De data moet door de 'data-laag' uit de DB gehaald worden, zonder dat de presentatie-laag nog die data moet formatten.

[CaptBiele]

ok, dus als ik het goed begrijp moet ik een van deze 2 pakken:

code:

CREATE TABLE Test(AutoNr int2 AUTO_INCREMENT NOT NULL, PRIMARY KEY (AutoNr), 
CmpId CHAR(6),
Sequence CHAR (3) NOT NULL,
StartDate DATE NOT NULL, 
BlockedYn BOOL NOT NULL);

of deze

code:

CREATE TABLE Test(
CmpId MEDIUMINT UNSIGNED ZEROFILL AUTO_INCREMENT PRIMARY KEY,
Sequence CHAR (3) NOT NULL,
StartDate DATE NOT NULL, 
BlockedYn BOOL NOT NULL);

[whoami]

Wat is CmpId eigenlijk? Heeft dat veld een bepaalde betekenis ? Is dat bv. iets wat op het scherm getoond wordt, wat kan afgedrukt worden op brieven, .....

Indien CmpId een betekenis heeft, dan zou ik dat veld zeker niet als PK gebruiken. Stel maar bv. dat die waarde plots gewijzigd wordt, dan mag je al je Foreign Keys ook gaan aanpassen. In SQL Server kan je dat wel met een ON CASCADE UPDATE oid doen, maar ik hou zowiezo niet van het idee dat de waarde van een PK kan wijzigen.

Je kan natuurlijk ook dit doen (als CmpId een betekenis heeft):

code:

CREATE TABLE test
(
test_id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(test_id),
CmpId MEDIUMINT UNSIGNED ZEROFILL,
...

[ Voor 22% gewijzigd door whoami op 27-04-2004 11:26 ]

[CaptBiele]

CmpId is een id van een Company. Ik denk niet dat het een betekenis heeft zoals jij bedoeld. Het wordt iig niet op het scherm getoond oid...

[Verwijderd]

whoami schreef op 27 april 2004 @ 11:07:
...
Daarnaast vind ik het zowiezo geen goed idee om een veld dat 'betekenis' heeft als PK te gaan gebruiken. IMO gebruik je beter een extra-veldje (bv. een autonumber veld) die enkel gebruikt wordt als PK, en waarvan de inhoud er eigenlijk niet toe doet, zolang het maar uniek is.
Met autonummer-velden ben je dus zeker dat je een unieke waarde krijgt binnen die tabel.

Ben ik het niet mee eens..
Met autonummer krijg je iid altijd een unieke waarde in je tabel. Maar wat nou als je veld met 'betekenis' maar 1 x mag voorkomen in je table (dat is een PK volgens mij). Dan zou het mogelijk zijn dat je met autonummer 2 x een veld waarvan de betekenis het zelfde is voorkomt.

Stel

code:

create table users(
emailaddr varchar(20) not null primary key,
name varchar(20) not null,
)

Nu zijn al mijn email adressen uniek.

code:

create table users(
id int() auto_increment primary key,
emailaddr varchar(20) not null,
name varchar(20) not null,
)

Nu niet...

Het is natuurlijk wel te omzeilen met 'unique', maar dan nog vind ik het niet netjes.
Ook bij een overzicht van een table waarin een foreign key staat naar je PK, zie je dan alleen een nummer, ipv het emailaddr.

[whoami]

Als het veld CmpId eigenlijk geen toegevoegde betekenis heeft, waarom moet het dan eigenlijk juist 6 cijfers bevatten?

[whoami]

Verwijderd schreef op 27 april 2004 @ 11:33:
[...]


Ben ik het niet mee eens..
Met autonummer krijg je iid altijd een unieke waarde in je tabel. Maar wat nou als je veld met 'betekenis' maar 1 x mag voorkomen in je table (dat is een PK volgens mij). Dan zou het mogelijk zijn dat je met autonummer 2 x een veld waarvan de betekenis het zelfde is voorkomt.

Stel

code:

create table users(
emailaddr varchar(20) not null primary key,
name varchar(20) not null,
)

Nu zijn al mijn email adressen uniek.

code:

create table users(
id int() auto_increment primary key,
emailaddr varchar(20) not null,
name varchar(20) not null,
)

Nu niet...

Nee.
Het is niet omdat een veld uniek moet zijn, dat het daarom al direct maar een PK mag zijn.
Een PK leggen op een e-mail adres vind ik zowiezo al een slecht idee, en wel om de volgende reden: stel ik verander vandaag mijn e-mail adres, dan mag je alle FK 's in de andere tabellen ook gaan aanpassen. Happy happy joy.
Nog afgezien van het feit dat een numeriek veld altijd sneller is dan een alfanumeriek veld.

Als je uniqueness wilt afdwingen kan je dat ook altijd doen mbhv een unique constraint of een unique index.

Het is natuurlijk wel te omzeilen met 'unique', maar dan nog vind ik het niet netjes.

dat is wel net de bedoeling van een unique constraint. Een tabel kan maar 1 pk hebben, en die PK zorgt ervoor dat een record uniek identificeerbaar is binnen de tabel.
Daarnaast wordt de PK ook gebruikt om een relatie aan te geven met andere tabellen. Als jij velden gebruikt die 'betekenis hebben binnen je DB' als primaire sleutel, dan wil dat zeggen dat je vroeg of laat een primair-sleutelveld gaat wijzigen en daar wordt je niet blij van.

Ook bij een overzicht van een table waarin een foreign key staat naar je PK, zie je dan alleen een nummer, ipv het emailaddr.

Euh, ja. Dat is nu eenmaal het principe van relationele databanken.
Trouwens, dat is een non-argument. Je gaat niet direct in je tabel gaan zitten neuzen.

[ Voor 6% gewijzigd door whoami op 27-04-2004 11:44 ]

[NMe]

whoami schreef op 27 april 2004 @ 11:35:
Als het veld CmpId eigenlijk geen toegevoegde betekenis heeft, waarom moet het dan eigenlijk juist 6 cijfers bevatten?

CaptBiele:NME84: BOOL bestaat wel. En vanaf 4.1.0 bestaat BOOLEAN ook

Ehm, ik gebruik MySQL 4.0.18 en heb toch echt GEEN bool datatype bij mijn weten. En als je bekijkt dat veel webservers nog steeds MySQL 3.23 draaien.....

[CaptBiele]

whoami schreef op 27 april 2004 @ 11:35:
Als het veld CmpId eigenlijk geen toegevoegde betekenis heeft, waarom moet het dan eigenlijk juist 6 cijfers bevatten?

Ja ik denk niet dat het hoeft?!
Dat zullen mijn noobish gedachten wel zijn. Ik moet er even over nadenken....

NMe84 schreef op 27 april 2004 @ 11:44:
Ehm, ik gebruik MySQL 4.0.18 en heb toch echt GEEN bool datatype bij mijn weten. En als je bekijkt dat veel webservers nog steeds MySQL 3.23 draaien.....

Ik kan toch echt een BOOL veld aanmaken. Check de docs er maar op na.
En volgens mij gaan de meeste servers nu wel over naar 4.0.18 (van 3.23)

[whoami]

Als het echt geen betekenis hoeft te hebben, maak dan een auto-increment veld van CmpId en maak dat als PK, en klaar.

[NMe]

CaptBiele schreef op 27 april 2004 @ 11:50:
Ik kan toch echt een BOOL veld aanmaken. Check de docs er maar op na.
En volgens mij gaan de meeste servers nu wel over naar 4.0.18 (van 3.23)

http://dev.mysql.com/doc/mysql/en/Column_types.html Dan mag je mij vertellen waar daar in de documetatie wat staat over een boolean veldtype. ALS het al bestaat is het vrij nieuw, en dan duurt het nog wel een tijdje totdat webserverse up to date zijn, een server updaten doe je niet zomaar ff, vandaar dat vele servers zijn blijven steken op 3.23 en volgens mij wachten tot versie 5 uit komt oid.

[CaptBiele]

whoami schreef op 27 april 2004 @ 11:55:
Als het echt geen betekenis hoeft te hebben, maak dan een auto-increment veld van CmpId en maak dat als PK, en klaar.

Lijkt me heel logisch. Ik kom wel met kritiek als ik die kan vinden

NMe84 schreef op 27 april 2004 @ 11:56:
[...]

http://dev.mysql.com/doc/mysql/en/Column_types.html Dan mag je mij vertellen waar daar in de documetatie wat staat over een boolean veldtype. ALS het al bestaat is het vrij nieuw, en dan duurt het nog wel een tijdje totdat webserverse up to date zijn, een server updaten doe je niet zomaar ff, vandaar dat vele servers zijn blijven steken op 3.23 en volgens mij wachten tot versie 5 uit komt oid.

Dit haal ik uit mijn doc van 4.0.18:
BIT
BOOL
BOOLEAN
These are synonyms for TINYINT(1). The BOOLEAN synonym was added in version 4.1.0 Full boolean type handling will be introduced in accordance with SQL-99.

En ik heb 2 webservers zien verhuizen van 3.23 naar de laatste stabel production versie 4.0.18 ..... dan is het puur toeval geweest

[NMe]

CaptBiele schreef op 27 april 2004 @ 12:06:
[...]

Lijkt me heel logisch. Ik kom wel met kritiek als ik die kan vinden

Komt omdat het logisch is.

CaptBiele schreef op 27 april 2004 @ 12:06:
Dit haal ik uit mijn doc van 4.0.18:
BIT
BOOL
BOOLEAN
These are synonyms for TINYINT(1). The BOOLEAN synonym was added in version 4.1.0 Full boolean type handling will be introduced in accordance with SQL-99.

TINYINT(1) wil meen ik zeggen dat je een int veld van -9 tot 9 hebt, waarbij alles behalve 0 true betekent. Dat geldt dan ook voor die types die jij aandraagt. Volgens mij is een ENUM('T','F') dan kleiner, maar ik kan het mis hebben. Iemand een idee hoe het precies zit?

CaptBiele schreef op 27 april 2004 @ 12:06:
En ik heb 2 webservers zien verhuizen van 3.23 naar de laatste stabel production versie 4.0.18 ..... dan is het puur toeval geweest

Er zijn misschien wel servers die upgraden, maar ik hou het liefst alles 3.23 compatible, dan kom ik nooit voor problemen te staan. Lijkt me wel zo veilig. Ik loop ook heel vaak tegen problemen met PHP aan, omdat ik een nieuwere versie op mijn localhost draai dan op de server.

[CaptBiele]

check anders deze link