Relaties in PostgreSQL
Ik heb 2 tabellen
Users
client_id(relationeel)
username
password
aamgemaakt(niet relationeel met de kolom als de tabel hieronder).
rank
Profiel
client_id
naam
aangemaakt
..
..
En nog een vraag. Wat zijn de beste datatypes voor:
username 15 karakters
password 32 bits MD5
ik heb trouwens het volgende uitgetypt alleen klopt het niet echt denk ik(de query werkt iig niet).
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE TABLE users
(
id SERIAL,
username VARCHAR(20),
password VARCHAR(32),
CONSTRAINT users PRIMARY KEY(id),
CONSTRAINT users FOREIGN KEY (id)
);
CREATE TABLE profiel
(
id SERIAL,
voornaam VARCHAR(20),
achternaam VARCHAR(20),
geboortedatum TIMESTAMP,
CONSTRAINT profiel PRIMARY KEY(id),
CONSTRAINT profiel FOREIGN KEY (id)
REFERENCES users(id)
);
(
id SERIAL,
username VARCHAR(20),
password VARCHAR(32),
CONSTRAINT users PRIMARY KEY(id),
CONSTRAINT users FOREIGN KEY (id)
);
CREATE TABLE profiel
(
id SERIAL,
voornaam VARCHAR(20),
achternaam VARCHAR(20),
geboortedatum TIMESTAMP,
CONSTRAINT profiel PRIMARY KEY(id),
CONSTRAINT profiel FOREIGN KEY (id)
REFERENCES users(id)
);
Gewijzigd op 01/01/1970 01:00:00 door Jurgen assaasas
Verder zal ik even kijken hoe je e.e.a. netjes opzet, momentje!
pgFrank schreef op 29.11.2007 11:26:
Wat doet de FK in de tabal users? Dat lijkt me niet goed.
Verder zal ik even kijken hoe je e.e.a. netjes opzet, momentje!
Verder zal ik even kijken hoe je e.e.a. netjes opzet, momentje!
Ja, ik heb hier een tut uitgeprint maar het wil niet echt lukken. Ik ben het zoals jij het noemt vervloekte MySQL gewend en die slikt idd alles dus wil ik nu goed SQL leren. En de opzet van een relationele database bestuderen.
Stap 1 is dan ook het aanmaken van een SCHEMA waarin je gaat werken, een soort van object:
Nu heb je het SCHEMA 'test' aangemaakt, daarin gaan we verder werken.
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
CREATE TABLE test.users
(
id serial NOT NULL,
username varchar(20) NOT NULL,
userpassword char(32) NOT NULL,
CONSTRAINT "PK_users" PRIMARY KEY (id),
CONSTRAINT "U_username" UNIQUE (username)
)
WITHOUT OIDS;
(
id serial NOT NULL,
username varchar(20) NOT NULL,
userpassword char(32) NOT NULL,
CONSTRAINT "PK_users" PRIMARY KEY (id),
CONSTRAINT "U_username" UNIQUE (username)
)
WITHOUT OIDS;
Nu is in het SCHEMA 'test' de tabel 'users' aangemaakt.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE test.profielen
(
id serial NOT NULL,
id_users int8 NOT NULL,
voornaam varchar(20),
achternaam varchar(20),
geboortedatum date,
CONSTRAINT "PK_profielen" PRIMARY KEY (id),
CONSTRAINT "FK_profiel_user" FOREIGN KEY (id_users)
REFERENCES test.users (id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITHOUT OIDS;
(
id serial NOT NULL,
id_users int8 NOT NULL,
voornaam varchar(20),
achternaam varchar(20),
geboortedatum date,
CONSTRAINT "PK_profielen" PRIMARY KEY (id),
CONSTRAINT "FK_profiel_user" FOREIGN KEY (id_users)
REFERENCES test.users (id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITHOUT OIDS;
En zie hier de tabel 'profielen' in eveneens het SCHEMA 'test'. Daarin is ook een FK aangemaakt die verwijst naar de tabel 'users' in het SCHEMA 'test'.
Omdat je nu een SCHEMA gebruikt, zul je overal bij het oproepen van een tabel óók de schemanaam moeten opgeven:
Dat lijkt omslachtig, maar dankzij de SCHEMA's kun je OO gaan werken in je database. Denk bv. aan een SCHEMA 'users' met daarin alle gegevens van de users en een SCHEMA 'topics' met daarin de topics van het forum. Een SCHEMA 'boeken' zou dan bv. de boekbesprekingen kunnen bijhouden.
Relaties e.d. kunnen over meerdere SCHEMA's zijn uitgesmeerd, dat is geen enkel probleem. Zorg dat je bij het aanmaken van de FK's de juiste namen opgeeft. Hier even heel goed opletten, het ligt bv. voor de hand dat vrijwel iedere SCHEMA een tabel 'statussen' heeft met daarin de statussen die het object kan hebben. Wanneer je dan naar het verkeerde SCHEMA verwijst, kun je hele rare situaties krijgen...
Met pgSQL heb je geen auto_increment waarvan pas achteraf bekend is welk nummer is toegekend, een SERIAL weet vooraf welk nummer er wordt toegekend. Met bv. de functie NEXTVAL() vraag je deze op, en ga deze waarde gebruiken in de diverse queries.
I.p.v. een SERIAL kun je ook gewoon een INT gebruiken en apart een SEQUENCE aanmaken die je iedere meer met NEXTVAL() ophoogt. Op die manier heb jij de volledige controle over wat er met de id's moet gebeuren.
Succes!
Edit: Hier nog even de syntax om handmatig een SEQUENCE aan te maken:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
CREATE SEQUENCE test.users_id_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;
Dit doe je alleen wanneer je géén SERIAL wilt gebruiken, maar een INT voor je id. Bij het gebruik van een SERIAL wordt de sequence automatisch aangemaakt en opgehoogd wanneer je de tabel gaat vullen. Ik doe dit 'handmatig', geeft me net iets meer controle over wat er gebeurt in de database.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Hoe staat het eigenlijk met de pgSQL-avonturen?
Mooie post Frank. Gebookmarkt om in de toekomst naar te linken :)
Ik ben er nog mee aan het prullen, ik heb de 2 PGSQL tuts hier op PHPhulp ook even uitgedraaid en ik moet zeggen dat het best ingewikkeld is. Ik kan makkelijk de bovenstaande code in een SQL dump gooien maar daar leer ik niets van dus ben ik het nog aan het bestuderen.
Jurgen schreef op 01.12.2007 10:17:
Hoe kan dat nu ingewikkeld zijn? pgSQL is niet meer of minder dan het standaard SQL-gebeuren, met standaard datatypes, etc.Ik ben er nog mee aan het prullen, ik heb de 2 PGSQL tuts hier op PHPhulp ook even uitgedraaid en ik moet zeggen dat het best ingewikkeld is. Ik kan makkelijk de bovenstaande code in een SQL dump gooien maar daar leer ik niets van dus ben ik het nog aan het bestuderen.
Zeker wanneer je met een tooltje (is slechts een stuk gereedschap, maar toch) als pgAdminIII (Windows, Linux, OSX) aan de slag gaat, is het een fluitje van een cent om een correcte database aan te maken.
Vanuit PHP is het eenvoudiger om met pgSQL te kletsen dan MySQL, fouten worden afgekeurd. Uiteraard gebruik je PDO, dan maakt het namelijk voor de PHP-code niet uit of je nu met pgSQL, Oracle of MySQL kletst, het enige verschil is de SQL-syntax.
Edit: In bovenstaand voorbeeld wordt het SCHEMA 'test' aangemaakt. Dit is eigenlijk geen goed voorbeeld, sorry, 'test' is namelijk geen object. Kies dus een betere naam, een echt object zoals bv. users, sessies, cookies, topics, of ik weet niet wat. Het moet in elk geval tastbaar zijn. (ja, ook cookies en sessies zijn 'tastbaar')
Gewijzigd op 01/01/1970 01:00:00 door Frank -