[datamodel] notifications - trigger?
Ik ben bezig met een hobby-project, dus zo af en toe denk ik eens na hoe mijn systeem beter en sneller kan. Ik werk met postgreSQL. Ik zit nu met het volgende:
Gebruikers kunnen zich registreren en hebben zo hun eigen profiel, waar ze van alles kunnen plaatsen (foto's,blogs, enz...). Gebruikers kunnen elkaar toevoegen aan hun contactlijst.
Ik wil nu dat mensen een soort van news-feed te zien krijgen van de dingen die er zijn gebeurd bij hun contacten. Een voorbeeld is te zien bij Facebook.
Een tijdje geleden het ik al eens een topic geopend over dit onderwerp. Hier kwamen wel wat dingen uit, maar niet voldoende voor mij. De oplossing toen was om alle tabellen na te lopen en te kijken of er foto's/blogs/gegevens zijn gewijzigd. Dit is natuurlijk een mogelijkheid, maar zo kun je dus niet ordenen op datum (correct me if i am wrong...).
Nu had ik gedacht om een tabel aan te maken 'notifications' en hierin een veld met het type notificatie, dus bijvoorbeeld 'addfoto' en een verwijzing naar het ID naar de foto. Is dit een logische opzet? Het klinkt mij wat 'gevaarlijk' in de oren. Je zou met een trigger of check (?) kunnen controleren of het ID van het item bestaat.
Graag hoor ik tips of opmerkingen om een zo goed mogelijk datamodel neer te zetten.
Gewijzigd op 01/01/1970 01:00:00 door Simon Blok
Ik vind het niks, dat notifications ding wat je in gedachten hebt. Je moet dan per vriend/contact een notification aanmaken en weer kunnen beheren. Hoop gedoe. Een goede query zoals hierboven beschreven die alleen de activiteit van de laatste maand weer geeft lijkt mij al wel prima!
En wat bedoel jij precies met die inner-joins? Ik kan moeilijk de foto-tabel gaan joinen op de blog-tabel, deze hebben natuurlijk niets met elkaar te maken.
Een tabel met daarin de historie van updates kan zeker geen kwaad. Dat maakt het ophalen van deze historie vele malen eenvoudiger, zeker wanneer er veel tabellen bij zijn betrokken. Een trigger op de bron-tabel kan er voor zorgen dat het id en de naam van de tabel in de tabel 'historie' wordt bijgeschreven. Werkt prima en is voor drukke sites onmisbaar i.v.m. performance.
Is het slim om voor elke data-tabel (foto's, blogs, profieldata) een history-tabel aan te maken?
Ik vraag het maar even om zeker te weten dat ik het beste doe.
Zorg wel voor goede indexen, de history-tabel kan vrij snel veel records gaan bevatten. Een index op datum ligt voor de hand.
Heb je misschien ook ergens een opzetje van hoe een vrij standaard trigger werkt? in plpgsql. Dan kan ik ergens van uitgaan en daar vanuit de functie verder gaan 'onderzoeken'. Alvast bedankt.
De trigger zelf (in de tabel test.users):
Code (php)
1
2
3
4
5
2
3
4
5
CREATE TRIGGER count_users
AFTER INSERT OR UPDATE OR DELETE
ON test.users
FOR EACH ROW
EXECUTE PROCEDURE test.ophogen();
AFTER INSERT OR UPDATE OR DELETE
ON test.users
FOR EACH ROW
EXECUTE PROCEDURE test.ophogen();
En de trigger-procedure:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
CREATE OR REPLACE FUNCTION test.ophogen()
RETURNS "trigger" AS
$BODY$
BEGIN
UPDATE
test.countusers
SET
aantal = (SELECT COUNT(*) FROM test.users WHERE status = 'active');
RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
RETURNS "trigger" AS
$BODY$
BEGIN
UPDATE
test.countusers
SET
aantal = (SELECT COUNT(*) FROM test.users WHERE status = 'active');
RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
Meer informatie kun je in de handleiding vinden.
pgFrank schreef op 31.01.2008 22:03:
Ik zou in m'n systeem 1 history-tabel aanmaken en deze vullen met data die door diverse triggers wordt aangeleverd. Je krijgt dan één overzicht van wat er is gebeurd, welk record in welke tabel is aangepast. Zorg er voor dat je alleen dat opslaat, wat je nodig hebt om de daadwerkelijke gegevens uit bv. het blog te halen.
Zorg wel voor goede indexen, de history-tabel kan vrij snel veel records gaan bevatten. Een index op datum ligt voor de hand.
Zorg wel voor goede indexen, de history-tabel kan vrij snel veel records gaan bevatten. Een index op datum ligt voor de hand.
Ik ga toch nog even door op dit onderwerp. Als ik alles in 1 tabel zet en ik krijg echt veel data. Voor een nieuwsfeed heb ik bijvoorbeeld 50 records met wijzigingen. Ik kan nu niet gaan joinen op de andere tabellen, omdat het niet uit 1 tabel, maar uit meerdere komt. Hoe kan ik dit oplossen? Of zou ik dan bij elk record een aparte query moeten gaan uitvoeren voor de data in de andere tabellen?
Tabel history:
- id
- datumtijdstempel
- record_id
- tabelnaam
Hiermee kun je in 1 oogopslag zien in welke tabel op welk moment welk record is aangepast. Op basis van deze gegevens kun je dan de daadwerkelijke gegevens er zo uitplukken.
Wellicht wil je nog iets meer gegevens in deze tabel opslaan, maar vergeet hier even het idee van normaliseren en foreign keys. Het is niet meer dan een kladblok die jouw query-leven wat eenvoudiger maakt. Met een stored procedure of een stuk PHP-code kun je dan de boel verder uitspitten, maar je weet nu waar je precies moet zoeken.
En wat versta jij onder 'echt veel data' ? In PostgreSQL mag 1 tabel maximaal 32 terabyte groot zijn. Wanneer je tabellen van elkaar laat overerven, kun je deze limiet ook nog eens opheffen. Zorg dus eerst maar eens voor voldoende data en vooral schijfruimte... ;)
Gewijzigd op 01/01/1970 01:00:00 door Frank -