[PG]Tabellen voor ledensysteem ( uitgebreid )
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE leden (
id bigserial,
naam varchar(16) not null,
wachtwoord varchar(40) not null,
email varchar(80) not null,
datum_aangemeld timestamp not null default now(),
datum_geactiveerd timestamp not null default now(),
geactiveerd boolean not null default false,
accode varchar(40) not null
);
CREATE TABLE logs (
uid bigint not null,
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp not null default now(),
);
id bigserial,
naam varchar(16) not null,
wachtwoord varchar(40) not null,
email varchar(80) not null,
datum_aangemeld timestamp not null default now(),
datum_geactiveerd timestamp not null default now(),
geactiveerd boolean not null default false,
accode varchar(40) not null
);
CREATE TABLE logs (
uid bigint not null,
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp not null default now(),
);
Dit heb ik nu.. Wat ik graag wil is er een goed model aanwezig is.. Vanaf het begin al zodat ik later bij wijzigingen minder problemen tegen kom..
Is het model tot nu toe een beetje goed? Wat ik verder wil doen met de logs is dat wanneer iemand bevriend is met iemand anders en 1 van die 2 ( of alle 2 ) twee heeft ingestelt dat de ander mag/kan zien wat de ander allemaal hebt gedaan dit mooi daarin word opgeslagen en dus kan zien.. Maar hoe kan ik dit het beste maken?
ik had eerst zoiets in gedachte:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
CREATE TABLE logs (
uid bigint not null,
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp not null default now(),
log_type_id integer,
);
uid bigint not null,
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp not null default now(),
log_type_id integer,
);
log_type_id maak ik dan een aparte tabel voor en daar staat dan in een varchar veld bijvoorbeeld: ***** is ingelogt
of: ***** is uitgelogt
die sterretjes is dan een lid van de website..
Hoe kan ik dit het beste aanpakken?
Gewijzigd op 01/01/1970 01:00:00 door Mebus vg
Gesponsorde koppelingen:
Code (php)
1
2
2
datum_geactiveerd timestamp not null default now(),
geactiveerd boolean
geactiveerd boolean
Zowel de datum opslaan als een boolean 'geactiveerd', is wat dubbelop. Er zal helemaal niet zijn geactiveerd, zonder dat je een datum daarvan hebt.
Wil je een status van een user bijhouden, maak dan een aparte tabel 'statussen' aan, zet in de tabel leden een kolom 'id_status' en koppel dit met een FK.
Maar, op zich heb je in de tabel leden helemaal geen datums nodig, die heb je al in de tabel logs. Daarin kun je alles bijhouden. Wat ik daar alleen niet zou bijhouden, is of iemand is (nadruk op is) ingelogt. Niemand logt uit, je zult dus de laatste actie van iemand moeten bijhouden.
Relaties tussen users met een meer-op-meer-relatie, houd je bij in een aparte tabel. Hierin sla je 2x een leden_id op, stel 2x een FK in en klaar ben je. Oh ja, nog even een PK zetten op de gezamelijke kolommen.
Ps. Een BIGSERIAL is niet nodig, een SERIAL is groot genoeg.
Ook met dat mensen nooit uitloggen dat weet ik.. maar dat wanneer ze het wel doen dit in de logs word opgeslagen en anderen ( vrienden ) dit kunnen zien.. Ook wanneer iemand inlogt ( niet wanneer der een cookie is waardoor die automatisch word ingelogt )
FK en PK?
bigserial ga ik veranderen^^
nu alleen nog met die logs.. mischien een beter voorbeeldje:
Piet reageert op video id 555
in de logs komt nu te staan: Piet heeft gereageerd op de video $res_a['video_title'] van $res_a['video_uid']
Zoiets.. Maar hoe kan ik dit het beste in mijns logs laten opslaan?
Ook wil ik dat logs ouder als bijvoorbeeld 2 dagen autoatmisch verwijdert worden.. Dit weet ik iig wel hoe ik dit ga doen dan. Niet alle logs zullen verwijdert worden.. Alleen wanneer ze geen nut meer hebben...
PK = primary key
Jouw log is een ramp om uit te lezen, je kunt niet snel zien wie nu wat heeft gelezen. Per tabel moet je eigenlijk apart bijhouden wie nu iets doet met een bepaald record. Ga gewoon normaliseren, dan kom je daar vanzelf wel uit.
Het kán wel om in 1 logboek gewoon een stuk tekst te zetten, maar dat is eigenlijk alleen met een fulltext-search weer uit te vogelen. En dat kost veel tijd, de omvang van een logboek neemt heel snel toe!
In pgSQL heb je Tsearch2 tot je beschikking voor fulltext-search.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE leden (
id serial,
naam varchar(16),
wachtwoord varchar(40) not null,
email varchar(80) not null,
datum_aangemeld timestamp not null default now(),
datum_geactiveerd timestamp not null default now(),
accode varchar(40) not null,
primary key(id, naam)
);
CREATE TABLE logs (
uid integer not null references leden (id),
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp not null default now()
);
id serial,
naam varchar(16),
wachtwoord varchar(40) not null,
email varchar(80) not null,
datum_aangemeld timestamp not null default now(),
datum_geactiveerd timestamp not null default now(),
accode varchar(40) not null,
primary key(id, naam)
);
CREATE TABLE logs (
uid integer not null references leden (id),
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp not null default now()
);
Dit is al vast wat beter Frank?
Gewijzigd op 01/01/1970 01:00:00 door mebus vg
not null en een default is altijd fout, hiermee help je de not null om zeep. Laat hem dan weg, dan hou je jezelf niet voor de gek...
NOT NULL: verplicht een waarde opgeven
NULL: mag leeg zijn
DEFAULT 'waarde': mocht er geen waarde zijn, vul dan de default in.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE leden (
id serial,
naam varchar(16),
wachtwoord varchar(40) not null,
email varchar(80) not null,
datum_aangemeld timestamp default now(),
datum_geactiveerd timestamp default now(),
accode varchar(40) not null,
primary key(id, naam)
);
CREATE TABLE logs (
uid integer not null references leden (id),
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp default now()
);
id serial,
naam varchar(16),
wachtwoord varchar(40) not null,
email varchar(80) not null,
datum_aangemeld timestamp default now(),
datum_geactiveerd timestamp default now(),
accode varchar(40) not null,
primary key(id, naam)
);
CREATE TABLE logs (
uid integer not null references leden (id),
sessie varchar(40) not null,
ip inet not null,
wanneer timestamp default now()
);
= verandert
Code (php)
1
datum_geactiveerd timestamp default now(),
Dit is ook niet logisch. Het lijkt me immers dat dit veld wel NULL mag zijn aangezien een account direct na aanmelden nog niet geactiveerd zal zijn.
Dankje!
een veld is default toch null? of moet ik er alsnog null achter zetten?
constraint = beperking..
Maar wat waarvoor is het eigenlijk? Dat wanneer der toch een iligale actie word uitgevoerd op een kolom met een primary key je met een constraint aangeeft: pk_leden?
http://www.postgresql.org/docs/8.2/interactive/ddl-constraints.html
Stuk voor stuk helpen ze jou voorkomen dat jij geen onjuiste/corrupte data in je database krijgt. Zo zorgt een UNIQUE constraint op een kolom bijvoorbeeld dat er geen dubbele waarden in die kolom voor kunnen komen. Een Foreign Key constraint zorgt er aan de andere kant voor dat de relaties tussen je tabellen bewaard blijven.
Zie de link naar de handleiding voor meer informatie ;)
FOREIGN gebruik je wanneer der meerdere relaties zijn in een tabel met een andere tabel? Zo inplaats van een hele lange rij met allemaal REFERENCES te maken kan het korter met een FOREIGN?
Code (php)
1
2
3
4
5
6
2
3
4
5
6
CREATE TABLE t1 (
a integer PRIMARY KEY,
b integer,
c integer,
FOREIGN KEY (b, c) REFERENCES other_table (c1, c2)
);
a integer PRIMARY KEY,
b integer,
c integer,
FOREIGN KEY (b, c) REFERENCES other_table (c1, c2)
);
