[datamodel] notifications - trigger?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Simon Blok

Simon Blok

31/01/2008 15:39:00
Quote Anchor link
Beste mensen,
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
 
PHP hulp

PHP hulp

14/12/2024 23:51:14
 
Crispijn -

Crispijn -

31/01/2008 16:01:00
Quote Anchor link
Je kan zeker wel ordenen op datum! Met wat innerjoins en evt. een subquery kom je er wel uit. Het worden alleen dan wel draken van query's, daar heb je gelijk in.

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!
 
Simon Blok

Simon Blok

31/01/2008 16:04:00
Quote Anchor link
Dat zou inderdaad werken, maar ik wil ook bijhouden of iemand foto's heeft verwijderd bijvoorbeeld. Dus er zal sowieso een aparte tabel moeten komen.
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.
 
TJVB tvb

TJVB tvb

31/01/2008 16:16:00
Quote Anchor link
voor het verwijderen kun je zorgen door een vakje delete te hebben die standaard leeg is. Als die foto dan verwijderd is zet je er een timestamp van dat moment in. Dan weet je dus meteen wanneer.
 
Frank -

Frank -

31/01/2008 17:31:00
Quote Anchor link
'verwijderd' is een status van een record, dat kun je dus bijhouden in de kolom 'status'. Tevens zorg je voor een kolom 'lastupdate', dan kun je daar later op sorteren.

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.
 
Simon Blok

Simon Blok

31/01/2008 18:31:00
Quote Anchor link
Thx Frank.
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.
 
Frank -

Frank -

31/01/2008 22:03:00
Quote Anchor link
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.
 
Simon Blok

Simon Blok

31/01/2008 22:14:00
Quote Anchor link
Thx Frank. Hier heb ik echt wat aan.
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.
 
Frank -

Frank -

31/01/2008 22:20:00
Quote Anchor link
Hier een voorbeeldje van een trigger die het aantal users bijhoudt.

De trigger zelf (in de tabel test.users):
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
CREATE TRIGGER count_users
  AFTER INSERT OR UPDATE OR DELETE
  ON test.users
  FOR EACH ROW
  EXECUTE PROCEDURE test.ophogen();

En de trigger-procedure:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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;

Meer informatie kun je in de handleiding vinden.
 
Simon Blok

Simon Blok

01/02/2008 19:13:00
Quote Anchor link
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.

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?
 
Frank -

Frank -

01/02/2008 19:39:00
Quote Anchor link
Ik zou helemaal geen JOINs willen hebben in dit geval:

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 -
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.