07. maj 2006 - 19:51Der er
17 kommentarer og 1 løsning
Logge alle ændringer i CMS
Hejsa E
Jeg har noget portal hvor der er en del data. Jeg vil gerne have hjælp fra andre, men jeg er lidt øm over mine data og jeg vil gerne have at man gør tingene på min måde, så jeg vil lave et logningssystem så det er nemt at køre en eller flere ændringer tilbage.
Jeg havde forestillet mig noget i stil med at logge alle data som de er nu og så logge alle ændringer på feltniveau derefter. langt de fleste data kommer fra forudindtastede data, så brugeren bare skal gemme en værdi fra en dropdovn, der så indeholder en talværdi der repræsenterer en tekst. Der er enkelte faste tekstværdier og en del enums. Der er to varchars af maks 255 karakterer og et tekstfelt. Jeg regner ikke med at gemme tekstværdien da det vil fylde for meget i loggen, men jeg er dog lydhør overfor gode ideer for at gemme ændringer her også.
Jeg havde tænkt på noget i stil med en tabel med en varchar(255) til tekster, en enum til disse og en int til alle tal. På feltet på redigeringssiden vil jeg så sætte en variabel (1, 2, 3) der fortæller om dennes værdi skal gemmes på hhv. en af ovenstående. Derudover skal der selvfølgelig gemmes noget om hvem der har ændret og dato osv.
Har du nogen erfaring med dette, så vil jeg meget gerne høre din mening om dette, da jeg er i tvivl om det kommer til at fylde for meget og gør det hele langsomt osv. og alt det jeg ikke lige har tænkt igennem. På forhånd tak.
Loggen skal også være tilgængelig for brugerne, men kun i webformat, så der vil være en del trafik til den fil. (bare lige for at være helt sikker, så går jeg ud fra at en flat file er en alm. textfil ??)
Jeg følger dig fint, men hvad med en løsning hvor man f.eks. kun gemmer de nyeste data i en tabel og lægger gamle data i en xml fil. f.eks. at jeg kun gemmer de ændringer som ikke er godkendt af mig i en tabel og resten i xml.
OK, så langt så godt. Så skal det bare ned i databasen det hele...
Jeg står så nu med to muligheder, som jeg ser det. 1. jeg fortsætter med en logtabel som først beskrevet. 2. jeg kører med et versionsnummer som du foreslår.
Begge er tiltalende, men for mig er den største forskel at jeg med den ene gemmer i loggen for hver enkelt rettelse i hvert felt, mens den anden lægger op til at der rettes på en hel side. Jeg har normaliseret rimeligt godt, så det er ikke en stor bunke data der skal gemmes, selvom det evt. kun er et enkelt felt der er opdateret. Din metode løser også problemet med tekstfeltet, som der umiddelbart ikke er plads til at gemme i min metode.
Jeg kan dog ikke lige umiddelbart gennemskue om det er så smart at joine flere tabeller, når der både skal joines på ID og holdes styr på et versionsnummer. Hvordan klarer man sådan en ?
... ORDER BY tabel1.version DESC,tabel2.version DESC,tabel3.version DESC LIMIT 1
eller
... WHERE tabel1.version = (SELECT MAX(version) FROM tabel1) AND tabel2.version = (SELECT MAX(version) FROM tabel2) AND tabel3.version = (SELECT MAX(version) FROM tabel3) ...
jeg er lidt skeptisk overfor de aenkelte aendringer
jeg tror at det er lidt svaert at faa et samlet overblik over et antal rettelser
rul tilbage er faktisk ikke helt simpelt
men hvis plads er afgoerende og det mest er "show only" loggen skal bruges til saa kan den da bruges
NB: hvis du bruger min model saa er en seperat tabel med 1:1 paa det store tekst felt nok en god ide (for at undgaa at faa kopieret 20 KB tekst fordi et tal rettes)
Umiddelbart synes jeg godt om ideen med at der gemmes så snart der er blur på et felt. Dette kan også give et hint om hvordan brugerne bruger systemet, da der vil blive gemt en masse "mellemregninger" om man vil før brugeren er tilfreds med det samlede resultat. Jeg ved ikke om du kan følge mig...
Jeg har tænkt mig en logtabel der indeholder alt der kan identificere hvilket felt der er rettet i hvilken tabel, noget i stil med. tabel - felt - feltID - felttype - enumfeltvaerdi - charfeltvaerdi - talfeltvaerdi - brugerid - dato
Derudover skal jeg under alle omstændigheder have noget feltvalidering og sideopbygning lavet automatisk, så det bliver nemt at udvide med flere data osv.
Din løsning forekommer mig dog som den nemmeste lige nu, men på lang sigt...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
