---

Jeg kunne godt tænke mig at lave et database program.
Om det skal tilgåes som program (Pascal, C andet ) eller PHP er ikke
fastlangt - og det er heller ikke det jeg ønsker hjælp til
Men selve valget af database er det jeg ønsker lidt hjælp til.
Jeg ønsker ikke at lægge op til hvad der er bedst over alt - men søger
derimod oplysninger om hvilken database der kan løse netop mit behov.

1) Det skal være en form for SQL - MySql kommer lige for.
2) Open Source + god udbredelse

Det store problem er logen.
Jeg ønsker en back/rollback log der kan bruges til noget - og ikke er større
end nødvendigt.
Jeg ønsker at logge alle ÆNDRINGER i databasen - med gamle data og nye data
for hver enkelt operation.
Jeg er temmelig ligeglad med at der bliver LÆST fra databasen.
Hvis jeg benytter logs i Mysql få jeg en mega stor log - der indeholder ALT
hvad der er sendt til MySql - inc alle SELECT.
Jeg får dog ikke gemt de gamle data i loggen - så hvis jeg finder en fejl -
skal jeg tilbage til en total backup for at finde de rigtige data.

Det ultimative er hvis der kan logges med bruger og tidspunkt.
Er der nogle af de kendte databaser der kan dette som standart ?

---

On Sat, 17 Apr 2004 13:08:23 +0200, Birger Mortensen wrote in
dk.edb.system.unix:

> Jeg kunne godt tænke mig at lave et database program.

Jeg synes, at dit indlæg er svært at tolke: Det er postet i
unix-gruppen, men handler om databaseteknologi (dk.edb.database ville
være oplagt). Du skriver, at du gerne vil skabe et program
(dk.edb.programmering ville være oplagt), men synes helst at ville tage
udgangspunkt i et eksisterende produkt.

Jeg vil forsøge at kommentere alligevel, og henviser yderligere
diskussion til dk.edb.database (XFUT sat dertil).

> Det ultimative er hvis der kan logges med bruger og tidspunkt. Er der
> nogle af de kendte databaser der kan dette som standart ?

Du kan i mange RDBMSer (MySQL er en af de få undtagelser) specificere
"triggers", og de kan bl.a. bruges til at skabe forskellige former for
logging - af alt lige fra ændringer i en enkelt tabelattribut til
replikering af hele tabeller og principielt hele databaser.

For nogen tid siden var såkaldte temporale databasesystemer meget hotte
inden for teoretiske såvel som industrielle kredse. Bl.a. var der på et
tidspunkt et forsøg på at få bygget temporale features ind i
SQL-standarden ("SQL/Temporal"). Siden er interessen kølnet betydeligt,
og ingen af de betydende spillere på DBMS-markedet har bygget mulighed
for temporale databaser ind i deres DBMSer.

I Danmark er det særligt i Aalborg, at man ved noget om temporale
databasesystemer (AUC synes i det hele taget at være Danmarks eneste
betydende center for forskning i relationelle databaseemner?), og du
finder hos dem http://www.cs.auc.dk/TimeCenter/software.htm som nævner en
række eksperimentelle og slutbruger-rettede stykker software, der i et
eller andet omfang tilbyder temporal databasefunktionalitet. Samme URL kan
danne udgangspunkt for yderligere søgen efter information om emnet.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Jeg var ikke bekendt med dk.edb.database fandtes - det er det rigtige sted
og jeg forsætter der takker


"Troels Arvin" <troels@arvin.dk> skrev i en meddelelse
news:pan.2004.04.17.11.40.28.167454@arvin.dk...
> On Sat, 17 Apr 2004 13:08:23 +0200, Birger Mortensen wrote in
> dk.edb.system.unix:
>
> > Jeg kunne godt tænke mig at lave et database program.
>
> Jeg synes, at dit indlæg er svært at tolke: Det er postet i
> unix-gruppen, men handler om databaseteknologi (dk.edb.database ville
> være oplagt). Du skriver, at du gerne vil skabe et program
> (dk.edb.programmering ville være oplagt), men synes helst at ville tage
> udgangspunkt i et eksisterende produkt.
>
> Jeg vil forsøge at kommentere alligevel, og henviser yderligere
> diskussion til dk.edb.database (XFUT sat dertil).
>
> > Det ultimative er hvis der kan logges med bruger og tidspunkt. Er der
> > nogle af de kendte databaser der kan dette som standart ?
>
> Du kan i mange RDBMSer (MySQL er en af de få undtagelser) specificere
> "triggers", og de kan bl.a. bruges til at skabe forskellige former for
> logging - af alt lige fra ændringer i en enkelt tabelattribut til
> replikering af hele tabeller og principielt hele databaser.
>
> For nogen tid siden var såkaldte temporale databasesystemer meget hotte
> inden for teoretiske såvel som industrielle kredse. Bl.a. var der på et
> tidspunkt et forsøg på at få bygget temporale features ind i
> SQL-standarden ("SQL/Temporal"). Siden er interessen kølnet betydeligt,
> og ingen af de betydende spillere på DBMS-markedet har bygget mulighed
> for temporale databaser ind i deres DBMSer.
>
> I Danmark er det særligt i Aalborg, at man ved noget om temporale
> databasesystemer (AUC synes i det hele taget at være Danmarks eneste
> betydende center for forskning i relationelle databaseemner?), og du
> finder hos dem http://www.cs.auc.dk/TimeCenter/software.htm som nævner en
> række eksperimentelle og slutbruger-rettede stykker software, der i et
> eller andet omfang tilbyder temporal databasefunktionalitet. Samme URL kan
> danne udgangspunkt for yderligere søgen efter information om emnet.
>
> --
> Greetings from Troels Arvin, Copenhagen, Denmark
>

---

Mit problem / ønske går på en standart Sql database der kan logge
"ordentligt" for mig.
Min tanke er at vedligeholdensen og brugen af databasen skal pakkes ind i et
program - det er ikke den del jeg ønsker hjælp til.
Jeg ønsker at data skal gemmes i standart format da det er langt det mest
fleksible - jeg tænker på muligheden for tilgå data fra andre medier
eksport, import m.v.
Det er jo fx ikke en helt store videnskab at tilgå data der er gemt i MySql
fra PHP.
Men ligeså snart at man begynder at tilgå data UDEN for "mit" miljø ryger
alle logfunktioner jeg måtte ha bygget i selve interfacet
Derfor ønsker jeg at selve loggingen af data skal ske på selve databasen.

Hvis jeg læser rigtigt på det link du opgav er der ikke tale om standart
databaser.

> Du kan i mange RDBMSer (MySQL er en af de få undtagelser) specificere
> "triggers", og de kan bl.a. bruges til at skabe forskellige former for
> logging - af alt lige fra ændringer i en enkelt tabelattribut til
> replikering af hele tabeller og principielt hele databaser.

Det var den slags jeg var efter - kender du til hvilken data base der evt
kunne være tale om ?

Da vi er flyttet gruppe gentager jeg lige mit ønske.

1) Det skal være en form for SQL - MySql kommer lige for.
2) Open Source + god udbredelse

Det store problem er logen.
Jeg ønsker en back/rollback log der kan bruges til noget - og ikke er større
end nødvendigt.
Jeg ønsker at logge alle ÆNDRINGER i databasen - med gamle data og nye data
for hver enkelt operation.
Jeg er temmelig ligeglad med at der bliver LÆST fra databasen.
Hvis jeg benytter logs i Mysql få jeg en mega stor log - der indeholder ALT
hvad der er sendt til MySql - inc alle SELECT.
Jeg får dog ikke gemt de gamle data i loggen - så hvis jeg finder en fejl -
skal jeg tilbage til en total backup for at finde de rigtige data.

Det ultimative er hvis der kan logges med bruger og tidspunkt.
Er der nogle af de kendte databaser der kan dette som standart ?

---

On Sat, 17 Apr 2004 15:20:51 +0200, Birger Mortensen wrote (subject was:
"Re: Bedste database for MIG - (Linux)"):

>> Du kan i mange RDBMSer (MySQL er en af de få undtagelser) specificere
>> "triggers", og de kan bl.a. bruges til at skabe forskellige former for
>> logging - af alt lige fra ændringer i en enkelt tabelattribut til
>> replikering af hele tabeller og principielt hele databaser.
>
> Det var den slags jeg var efter - kender du til hvilken data base der evt
> kunne være tale om ?

PostgreSQL, DB2, Oracle, MSSQL, Firebird, MaxDB, SQLite[1] og MimerSQL er
eksempler.



Note 1: SQLite er ikke et egentligt DBMS, en SQL-"motor", der kan
indbygges direkte i et program, såsom PHP: http://www.sqlite.org/

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin <troels@arvin.dk> wrote:

> On Sat, 17 Apr 2004 15:20:51 +0200, Birger Mortensen wrote (subject was:
> "Re: Bedste database for MIG - (Linux)"):
>
> >> Du kan i mange RDBMSer (MySQL er en af de få undtagelser) specificere
> >> "triggers", og de kan bl.a. bruges til at skabe forskellige former for
> >> logging - af alt lige fra ændringer i en enkelt tabelattribut til
> >> replikering af hele tabeller og principielt hele databaser.
> >
> > Det var den slags jeg var efter - kender du til hvilken data base der evt
> > kunne være tale om ?
>
> PostgreSQL, DB2, Oracle, MSSQL, Firebird, MaxDB, SQLite[1] og MimerSQL er
> eksempler.

PostgreSQL er gratis. Oracle kan downloades, hvis du lader dig
registrere som udvikler:

http://otn.oracle.com/software/index.html
--
Per Erik Rønne

---

Troels Arvin wrote:

> PostgreSQL, DB2, Oracle, MSSQL, Firebird, MaxDB, SQLite[1] og MimerSQL er
> eksempler.

Birger skrev også:
> Det store problem er logen.
> Jeg ønsker en back/rollback log der kan bruges til noget - og ikke er
større
> end nødvendigt.
> Jeg ønsker at logge alle ÆNDRINGER i databasen - med gamle data og nye
data
> for hver enkelt operation.

Det udelukker vel Firebird(?).
Så vidt jeg husker, kører den ikke med transaction logging.

--
Med venlig hilsen
Stig Johansen

---

On Sun, 18 Apr 2004 09:06:31 +0200, Stig Johansen wrote:

>> Jeg ønsker en back/rollback log der kan bruges til noget - og ikke er
>> større end nødvendigt.
>> Jeg ønsker at logge alle ÆNDRINGER i databasen - med gamle data og nye
>> data for hver enkelt operation.
>
> Det udelukker vel Firebird(?).
> Så vidt jeg husker, kører den ikke med transaction logging.

Firebird har transaktionsundersøttelse, så vidt jeg er orienteret:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_60_sqlref#RSf96788

Tænker du på mangel af et specifikt isolationsniveau? (Tilsyneladende
har den ikke SERIALIZED.)

- Eller tænker du point-in-time recovery? (Sådan læser jeg ikke Birgers
spørgsmål.)

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:

> - Eller tænker du point-in-time recovery? (Sådan læser jeg ikke
> Birgers spørgsmål.)

Som jeg læser spørgsmålet - så ønskes der en række tabeller hvor alle
ændringer over tid kan ses af en admin bruger
Dette kan løses ved at man indsætter data i en transaktionstabel og triggers
sørger så for at bringe data videre til "stam" tabeller
Lidt i stil med fx finansposteringer
Svjv så skal dette laves manuelt - dvs som en del implementeringen - og er
ikke en ting der undestøttes per default
Eller rettere understøtter rdbms triggers så kan man implementere en løsning
som beskrevet

- Peter

---

Kan være at jeg skal komme med et par ex. på hvordan jeg ønsker at bruge
det.

Hvis man kører en database over fx varelager - med flere brugere
En ny bruger misforstår et eller andet og lagerfører 1400 Kg æbler som
pærer.
I dette tilfælde ønsker at det i loggen fremgår at "update pærer was 200 new
1600 by Hans"
Eller noget lig.

I en normal log kan man se at lagerstatus er rettet men ikke hvor meget der
var på lager først - ej heller hvem det var der misforstod hvordan man
brugte programmet. Den oprindelige status er gået tabt.
Man kan naturligvis gå tilbage til en total backup - og så køre de
tranactioner der er logget indtil hvor fejlen opstod
Og så køre resten bagefter - udover det er et pokker arbejde - så udelukker
det muligheden for at finde synderen og få brugeren til at gøre det rigtigt
i fremtiden.

Et andet ex kunne være at en bruger i en database over priserne får rettet
udsalgspris til indkøbspris.

Tag så begge typer databaser og gør data tilgængelige via Web - dette skaber
et HAV af læsninger fra databasen og gør loggen vildt stor med mindre vi kan
udelukke den slags forspøresler.

Det er naturligvis ikke det store problem at lave den slags log's i selve
grænsefladen ( program - PHP whatever ).
Men det skal så laves i alle grænseflader der tilgår databasen. Hvis
databasen selv understøtter dette er man væsentlig mere sikker.

Nu er jeg ikke helt sikker på hvad du mener med "point-in-time recovery" men
som jeg forstår det er det IKKE det jeg ønsker - Jeg ønsker kunne fange EN
forkert operation og kunne rette den.

Birger


"Peter Lykkegaard" <polonline@hotmail.dk> skrev i en meddelelse
news:40824483$0$430$edfadb0f@dread14.news.tele.dk...
> Troels Arvin wrote:
>
> > - Eller tænker du point-in-time recovery? (Sådan læser jeg ikke
> > Birgers spørgsmål.)
>
> Som jeg læser spørgsmålet - så ønskes der en række tabeller hvor alle
> ændringer over tid kan ses af en admin bruger
> Dette kan løses ved at man indsætter data i en transaktionstabel og
triggers
> sørger så for at bringe data videre til "stam" tabeller
> Lidt i stil med fx finansposteringer
> Svjv så skal dette laves manuelt - dvs som en del implementeringen - og er
> ikke en ting der undestøttes per default
> Eller rettere understøtter rdbms triggers så kan man implementere en
løsning
> som beskrevet
>
> - Peter
>
>

---

On Sun, 18 Apr 2004 14:58:07 +0200, Birger Mortensen wrote:

> Jeg ønsker kunne
> fange EN forkert operation og kunne rette den.

[samt at kunne se, hvem der begik fejlen]

OK. Triggers er det bedste bud, synes jeg.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Birger Mortensen wrote:
>
> Hvis man kører en database over fx varelager - med flere brugere
> En ny bruger misforstår et eller andet og lagerfører 1400 Kg æbler som
> pærer.
> I dette tilfælde ønsker at det i loggen fremgår at "update pærer was
> 200 new 1600 by Hans"

Dette gør du ret enkelt ved at have lagerposteringer hvor alle bevægelser på
dit varelager vil fremgå
Nøgleordene er historik og sporbarhed
Alle ERP systemer har det

> Et andet ex kunne være at en bruger i en database over priserne får
> rettet udsalgspris til indkøbspris.
>
Det er det samme her
Du har brug for historikken på et eller andet niveau
Det nytter jo ikke at fakturaen fra sidste år pludselig præsenterer sig
anderledes fordi prisen er ændret

> Tag så begge typer databaser og gør data tilgængelige via Web - dette
> skaber et HAV af læsninger fra databasen og gør loggen vildt stor med
> mindre vi kan udelukke den slags forspøresler.

Det er derfor det skal laves på databaseniveau
>
> Det er naturligvis ikke det store problem at lave den slags log's i
> selve grænsefladen ( program - PHP whatever ).

Du får så et utal af forskellige logs som du ikke kan bruge til fornuftigt
Du mister sporbarheden samt muligheden for at køre analyser etc

> Men det skal så laves i alle grænseflader der tilgår databasen. Hvis
> databasen selv understøtter dette er man væsentlig mere sikker.
>
Der er ikke nogen databaser der "out of the box" der understøtter det du
gerne vil
Men i designet af en given database så er det ret ligetil at implementere

Forestil dig at din kvittering fra fx Føtex kun indehold en total?
Du vil jo gerne have posteringerne med så du kan se hvad totalen dækker over
Det er ikke anderledes i et givent databasesystem

- Peter

---

Jeg kan se, at det er mig , der har misforstået indlæggene.

Troels Arvin wrote:

> - Eller tænker du point-in-time recovery? (Sådan læser jeg ikke Birgers
> spørgsmål.)

Ja, det var netop det jeg tænkte på. Det jeg fokuserede på var sætningen:
'Jeg ønsker en back/rollback log der kan bruges til noget', sammen med
'...tilbage til en total backup...'.

Det fik mig til at tro, at Birger var på jagt efter en enterprise class
database, hvor netop recovery modellen er kritisk.

--
Med venlig hilsen
Stig Johansen

---

On Sat, 17 Apr 2004 13:08:23 +0200, Birger Mortensen wrote:

> 1) Det skal være en form for SQL - MySql kommer lige for.

Den vil jeg gerne fraråde. Dens SQL er for sub-standard og den
mangler meget af det, som voksne databaser kan - IMHO er det en
legetøjsdatabase. Læs evt. også http://sql-info.de/mysql/gotchas.html.

(Hvis nogen er på vej op af stolen nu, så spar jer for
anstrengelserne - jeg gider ikke religiøse diskusioner - jeg har
arbejdet med MySQL i adskillige år og de erfaringer jeg har gjort
mig er baggrunden for ovenstående. På forhånd tak!

> 2) Open Source + god udbredelse

Så handler det vel mest om PostgreSQL og InterBase.

I PostgreSQL kan du lade alle ændringer gå igennem stored
procedures, samtidigt med at du bruger transaktioner. Så kan du
selv logge hvad der skal logges.

Jeg ved ikke om den kan lave en logfil, som præcist gør det du
har brug for.

> Jeg får dog ikke gemt de gamle data i loggen - så hvis jeg finder en fejl -
> skal jeg tilbage til en total backup for at finde de rigtige data.

Hvorfor ikke eksportere relevante tabeller/data en gang i timen
istedet for? Hvis du vil logge alle ændringer, så sløver det også
INSERT/UPDATE performance gevaldigt ned.

Eller bare eksportere ændringerne - du kan sætte et felt på dine
tabeller, som vha. triggers automatisk registrerer et timestamp
for sidste opdatering.

Husk at der er ingen triggers i MySQL

--
Stig
(remove the 'no's to send me mail)