Hej Frippe... Ok, det kanske kan vara ngt... Hej, Notifieringsfunktion vid uppdatering
Skall skapa en notifieringsfunktion till ett intranät.
Det jag tänkt är att man skall få en lista på det ändringar som gjorts (sedan senaste inlogg) direkt i en liten table när man loggat in. Ändringarna skall vara klickabara så att man kan följa upp varje förändring.
Varje post som skapas är knytet till ett uppdrag. Varje användare har läs/skrivrättighet till ett antal uppdrag.
Den lösning jag funderat på är att vid varje uppdatering av en post kolla:
1.) Vilket uppdrag denna post tillhör
2.) Vilka användarID:n som har minst läs-rättighet till detta uppdrag
Därefter lägger jag in en rad i db:n för varje användare. (innehåller länk, datum etc.)
När varje användare klickar på sin länk på startsidan skall han redirect:as till posten samtidigt som raden i db:n markeras som läst (alt. raderas) så att den försvinner för användaren.
Det jag är lite skpetisk mot är att det kan bli en himla massa insert:s mot db:n.
Vissa uppdraget idag har 50 användare...detta innebär alltså att vid varje uppdatering så måste det inserta:s 50 rader i ett svep. Kanske kommer gå segt?
Någon som har byggt en liknande funktion? Synpunkter eller tips på hur det kan lösas?
Tacksam.
/AndersSv: Notifieringsfunktion vid uppdatering
Jag gjorde inte direkt en sådan lösning men liknande.
Hade så en nyhet kom upp som en liten popup när man loggade in. Om man valde att inte visa nyheten igen markerades den som läst för användaren. Alltså jag sparade ner nyhets ID samt UserID i en tabel för lästa nyheter. Om man inte valde att de var lästa så visades det flera nyheter tills man valde att inte se dem som existerade. Popuprutan dök inte upp om nyhet inte fanns.
Du kan göra på ett liknande sätt. Om inte nyheten eller infon är unik för just användaren så skapar du en tabel som du kallar till ReadNews eller nått, lägg till ID för nyheten och ett id för med användaren.
När du listar nyheter utgår du från denna tabel. Du baserart på nyhets idn som inte finns i den med din användar id.
Att spra i DB måste du göra får att få detta att fungera. 50 samtliga användare bö rinte vara ett problem. Särkilt inte om det är ett intranet då ni har full access till linanan. Inga andra begränsningar.
Har jag hängt med rätt nu?
Mvh JohanSv: Notifieringsfunktion vid uppdatering
...men blir det inte en himla massa data i tabellen för lästa nyheter då? Alltså man kan inte radera en rad med ett nyhetsID och ett userID för då dyker den upp som oläst igen.
Har även gjort lite prestanda tester, att göra 50 Insert:s i ett svep verkar inte vara några som hellst problem.
Har jag hängt med rätt nu? =) Sv: Notifieringsfunktion vid uppdatering
Det har du rätt i, det blir en massa data. Men man kanske vill följa en historik i framtiden över vilka nyheter folk verkligen läst? Om en nyhet plockas bort tas ju dess övriga data oxå bort vilket minimerar mängden data.
Problemet ligger nog inte i vilken lösning du väljer att ha, utan snarare vilket krav kommer du ha?
Kanske historik i framtiden? Du kanske kommer på, oj gammal nyhet måste finnas kvar, vid update måste ett nytt ID skapas och på så vis måste du ju veta om det nya ID blivit läst eller ej. Du kanske oxå vill se vilka nyheter läste folk? hur såg historiken ut? Om du då int ehar kvar datan vilka de läst så vet du ju inte sådan information. Någon kanske aldrig läste första nyheten men bara den updaterade, vad ställer ni er till det? räcker det att man läser senaste versionen? eller måste man ha läst båda?
Man kanske vill veta när en användare läste nyheten. Det får man ju inte veta om man inte sparar ner det i databasen.
Så det gäller att försöka identifiera kraven. Kanske fråga någon, vill vi veta när en nyhet var läst? Eller vill vi bara veta Att man läst? vill man veta något annat? Kan en nyhet ha annan funktionalitet? Kanek de vill ha en nyhet som har ett formulär med frågor som skall besvaras och på så vis vill veta när dessa besvarades? m.m. m.m.
Om kraven är så enkla att du inte bryr dig om när etc. Så kanske det är bäst att lägga upp alla olästa plus id:n i ett svep och plocka bort dem som markeras som lästa.
Men vet du att mer info kan behövas, eller att det kommer komma viss funktionalitet som kräver att man vill ha sparat någon data vid läst så bör man istället spara ner vilka man läst.
Jag utgår oftast från att man troligen vill ha fler funktionliteter.
En annan lösning för att minimera datan är ju om ID är en int som uppdateras och man måste läsa nyehterna i en kronologisk ordning så behöver du ju typ bara spara ner ID man senadt läste för användaren och alla IDn som mindre än detta värde är redan lästa.
if(id > lastRead) då han man inte läst den.
if(id < lastRead) då vet du att dessa är lästa.
Då gäller det ju att man inte kan läsa 2an före 1an...
mvh Johan