|
|
 | Database opbygning
Fra : Steen Sommer Anderse~ |
Dato : 10-04-04 13:11 |
|
Hej Experter
Kort fortalt har jeg kastet mig ud i en FOR stor opgave men pyt. Jeg har
erfaring med VBA og LIDT (for lidt?) erfaring med ACCESS.
Nu er jeg gået i gang med at opbygge en database (Firebird 1,5) og vba
VB.Net vil jeg (hvis jeg kan finde ud af det) lave et program der checker
diverse medinske præparaters udskillelse i leverens enzymsystem (Cytokrom
P450 - forkortet CYP450). (Jeg har lavet et tilsvarende program med EXCEL og
VBA men ønsker at gøre det Office uafhængig).
For at komme ordentlig i gang ville jeg gerne om en af eksperterne vil
checke den database-opbygning jeg har lavet:
Database: Ny.fdb
Primær key (PK)
Medicin
Navn (PK)
Generisk_navn
Terapeutisk_Gruppe
Virkning
CYP450
CYP_ID (PK)
Terapeutiske grupper
Gruppe_ID (PK)
Gruppe_Navn
Virkemåde
Virkning_ID (PK)
Virkning
MEDCYP
CYP_ID
MEDICINNAVN
vh Steen
| |
 Nikolaj Hansen (10-04-2004)
| Kommentar
Fra : Nikolaj Hansen |
Dato : 10-04-04 13:22 |
|
(hvis jeg kan finde ud af det) lave et program der checker
> diverse medinske præparaters udskillelse i leverens enzymsystem (Cytokrom
> P450 - forkortet CYP450).
Lyder godt nok temmelig langhåret 
>
> Database: Ny.fdb
>
> Primær key (PK)
>
>
>
> Medicin
>
> Navn (PK)
>
> Generisk_navn
>
> Terapeutisk_Gruppe
>
> Virkning
Brug aldrig et navn til primary key. Hvad vil der ske, hvis et af
præperaterne skifter navn, men stadig er samme produkt? Jeg anbefaler altid
at bruge nøgler uden funktionel betydining, dvs. et id som du har brugt i de
nedenstående tabeller.
| |
Troels Arvin (10-04-2004)
| Kommentar
Fra : Troels Arvin |
Dato : 10-04-04 13:41 |
|
On Sat, 10 Apr 2004 14:22:00 +0200, Nikolaj Hansen wrote:
> Brug aldrig et navn til primary key. Hvad vil der ske, hvis et af
> præperaterne skifter navn, men stadig er samme produkt?
Hvad er det store problem i det?
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
 Ukendt (10-04-2004)
| Kommentar
Fra : Ukendt |
Dato : 10-04-04 14:24 |
|
On Sat, 10 Apr 2004 14:41:08 +0200, Troels Arvin <troels@arvin.dk>
wrote:
>On Sat, 10 Apr 2004 14:22:00 +0200, Nikolaj Hansen wrote:
>
>> Brug aldrig et navn til primary key. Hvad vil der ske, hvis et af
>> præperaterne skifter navn, men stadig er samme produkt?
>
>Hvad er det store problem i det?
Fordi alle de steder hvor du bruger navnet som reference, da skal det
naturligvis også ændres. Det er ikke praktisk. Hvis du istedet bruger
et ligegyldigt tal som reference, så kan du i ro og mag ændre navnet
uden, at skulle bekymre dig om alle de steder, hvor der referes til
navnet via tal-værdien.
Om det er et stort problem, det er naturligvis op til den enkelte at
vurdere. Men man kommer ikke udenom, at en ligegyldig værdi som
reference er meget mere vedligeholdelsesvenligt.
Mvh, Claus
--
I never apologize! I'm sorry, but that's the way I am.
- Homer Simpson
| |
Troels Arvin (10-04-2004)
| Kommentar
Fra : Troels Arvin |
Dato : 10-04-04 16:04 |
|
On Sat, 10 Apr 2004 15:23:37 +0200, wrote:
>>> Brug aldrig et navn til primary key. Hvad vil der ske, hvis et af
>>> præperaterne skifter navn, men stadig er samme produkt?
>>
>>Hvad er det store problem i det?
>
> Fordi alle de steder hvor du bruger navnet som reference, da skal det
> naturligvis også ændres.
Det har SQL faciliteter til at håndtere automatisk (ON UPDATE CASCADE).
Diskussionen for eller imod såkaldte surrogatnøgler er gammel, og jeg er
ikke afklaret. -Men jeg synes det er en fejl at anbefale generel brug af
surrogatnøgler: Hvis der til en relation findes en god (evt. kombineret),
naturligt given primærnøgle, synes jeg absolut man skal overveje at
benytte den.
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Henrik Stidsen (10-04-2004)
| Kommentar
Fra : Henrik Stidsen |
Dato : 10-04-04 21:24 |
|
Troels Arvin <troels@arvin.dk> wrote in
news:pan.2004.04.10.15.03.38.788699@arvin.dk
> Det har SQL faciliteter til at håndtere automatisk (ON UPDATE
> CASCADE).
Understøtter Access funktion ?
--
..: Henrik Stidsen - http://hs235.dk/blog/ ::...
'Veni, Vidi, Velcro' - I came, I saw, I stuck around.
| |
Lars Hoffmann (11-04-2004)
| Kommentar
Fra : Lars Hoffmann |
Dato : 11-04-04 10:08 |
|
Henrik Stidsen escribió / skrev
>> Det har SQL faciliteter til at håndtere automatisk (ON UPDATE
>> CASCADE).
>
> Understøtter Access funktion ?
ja. Når du tegner relationen markerer du at den skal updatere i
kaskade.
--
Publica fotos de tu Cine en Casa en
http://www.intercambiodvd.com/CineEnCasa
| |
Stig Johansen (11-04-2004)
| Kommentar
Fra : Stig Johansen |
Dato : 11-04-04 06:39 |
|
Troels Arvin wrote:
> Diskussionen for eller imod såkaldte surrogatnøgler er gammel, og jeg er
> ikke afklaret. -Men jeg synes det er en fejl at anbefale generel brug af
> surrogatnøgler:
Enig, og man bliver nok heller aldrig afklaret.
Et lille eksempel fra det virkelige liv.
For et par år siden, skulle jeg lave noget integration til en kunde.
Det 'ny' system, var noget MS SQLServer baseret noget.
I databasen, havde man valgt en id på brugeroplysninger, der via denne var
hæftet på ordrehoveder osv.
*Impacten* er:
Man kan ikke genbruge id (personalenummer), da historiske oplysninger går
tabt.
Man kan heller ikke slette brugere(vikarer - medarbejdere, der har forladt
virsomheden osv.) så længe der ligger ordrer osv. med disse id'er
(contraint - problemet)
Det er lidt kort fortalt, men i kan nok forestiller jer, at kunden har de
samme problemer med udgåede varer, ændrede ekspeditions steder osv.
Jeg kan i sagens natur ikke fortælle om kunden i detaljer, men det var et
klassisk eksempel på 'at normalisere sig ihjel'. Hvis man ikke passer på,
risikere man at ende med:
- Performance 'helvede' - *mange* joins etc.
- Programmerings 'helvede' - *mange* inserts/udates/selects osv.
- Vedligeholdelses 'helvede' - *mange* forældede data, man *ikke* kan komme
af med
.......
--
Med venlig hilsen
Stig Johansen
| |
Steen Sommer Anderse~ (11-04-2004)
| Kommentar
Fra : Steen Sommer Anderse~ |
Dato : 11-04-04 07:50 |
|
Hej alle
Nu har i jo haft en lang og interessant diskussion om databaseopbygning (og
det er da befriende rart at tingene kan gøres på mere end en måde). Ikke for
at afspore jer men tør man spørge om der ellers er bemærkninger til den
database jeg har lavet ;0)
vh Steen
| |
Troels Arvin (11-04-2004)
| Kommentar
Fra : Troels Arvin |
Dato : 11-04-04 10:48 |
|
On Sun, 11 Apr 2004 07:39:06 +0200, Stig Johansen wrote:
> I databasen, havde man valgt en id på brugeroplysninger, der via denne var
> hæftet på ordrehoveder osv.
> *Impacten* er:
> Man kan ikke genbruge id (personalenummer), da historiske oplysninger går
> tabt.
Hvorfor skulle man have lyst til at genbruge ID'er?
> Man kan heller ikke slette brugere(vikarer - medarbejdere, der har forladt
> virsomheden osv.) så længe der ligger ordrer osv. med disse id'er
> (contraint - problemet)
Men det er vel meget godt? I modsat fald ville der være ordrer med
referencer, der 'blafrer i vinden'?
> Jeg kan i sagens natur ikke fortælle om kunden i detaljer, men det var et
> klassisk eksempel på 'at normalisere sig ihjel'. Hvis man ikke passer på,
> risikere man at ende med:
> - Performance 'helvede' - *mange* joins etc.
Er det noget, du kunne mærke i praksis?
> - Programmerings 'helvede' - *mange* inserts/udates/selects osv.
Det har du måske nok ret i. Uden natural join mulighed (der kan gøre
queries mindre omfangsrige, og mere læselige) og views, der kan
opdateres, bliver der noget mere kodning.
> - Vedligeholdelses 'helvede' - *mange* forældede data, man *ikke* kan komme
> af med
Hvis man virkelig gerne vil af med oplysninger, slipper man vel ikke for
at rydde ud i forældede ordrer osv.? - Og så er kaskade-effekten vel
blot en fordel.
(Det er svært at diskutere ovenstående på fornuftig vis, for du vil
forsåelig nok ikke udlevere kundens detail-setup; omvendt kan vi ikke se
det fra din, detaljerede synsvinkel.)
--
Greetings from Troels Arvin, Copenhagen, Denmark
| |
Stig Johansen (11-04-2004)
| Kommentar
Fra : Stig Johansen |
Dato : 11-04-04 21:33 |
|
Troels Arvin wrote:
> (Det er svært at diskutere ovenstående på fornuftig vis, for du vil
> forsåelig nok ikke udlevere kundens detail-setup; omvendt kan vi ikke se
> det fra din, detaljerede synsvinkel.)
Det har du ret i - jeg er efterhånden bundet af så mange tavshedserklæringer
rundt omkring, så det sikreste for mig er, at 'tale sløret'.
Men jeg kan nok godt afsløre, at denne kunde har 2 mainframes, og 27 windows
servere i DK.
Min opgave var, i dette tilfælde, at integrere et MSSQL baseret system,
leveret(dikteret) fra den globale IT-afdeling med de operationelle systemer
på mainframen.
Tag mit indlæg som et hint om at man(ikke dig) kan 'normalisere sig ihjel',
og lad os stoppe her inden vi bliver OT.
--
Med venlig hilsen
Stig Johansen
| |
Peter Lykkegaard (11-04-2004)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 11-04-04 17:14 |
|
Stig Johansen wrote:
> Enig, og man bliver nok heller aldrig afklaret.
> Et lille eksempel fra det virkelige liv.
> For et par år siden, skulle jeg lave noget integration til en kunde.
> Det 'ny' system, var noget MS SQLServer baseret noget.
> I databasen, havde man valgt en id på brugeroplysninger, der via
> denne var hæftet på ordrehoveder osv.
> *Impacten* er:
[lang liste]
Jeg går ud fra at man ikke ønskede at anvende historikken?
Det kan ellers være rart hvis der kommer reklamationer ind på
produkter/ordrer af ældre dato
Desuden så er der jo et issue i forhold til finansposter etc, hvor man
absolut ikke må ændre bogførte posteringer på "lowlevel" niveau
- Peter
| |
Steen Sommer Anderse~ (10-04-2004)
| Kommentar
Fra : Steen Sommer Anderse~ |
Dato : 10-04-04 13:44 |
|
> Lyder godt nok temmelig langhåret
Ja IKKE :0)
> Brug aldrig et navn til primary key. Hvad vil der ske, hvis et af
> præperaterne skifter navn, men stadig er samme produkt? Jeg anbefaler
altid
> at bruge nøgler uden funktionel betydining, dvs. et id som du har brugt i
de
> nedenstående tabeller.
Jeg kan godt se hvad du mener! Hvad med de manglende PK i enkelte tabeller?
vh Steen
| |
|
|