/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Besvær med design
Fra : Anders Hellerup Mads~


Dato : 08-08-03 16:57

Hej,

Jeg har lidt vanskeligheder med et databasedesign, og selv om jeg har
fundet en løsning som nok kan bruges, er jeg ikke helt tilfreds og vil
gerne høre et par andre meninger:

Et produkt er af en bestemt type (f.eks. batterioplader), og til hver
type hører et antal test (højspændingstests, belastningstest osv.).
Hvert produkt har også en modeltype, som er en slags undergruppe af
typen (f.eks. oplader til AA batterier). Jeg skal kunne registere
produktmodeller, typer, test og testresultater for hvert enkelt produkt.

Hvordan gør jeg det uden at undgå et væld af mange-til-mange relationer.
Det bliver jo tæt på et helvede at SELECT'e noget som helst ud af
databasen, for slet ikke at tale om at få hevet et opdaterbart dataset
ud. Er der nogen der har et anstændigt forslag til løsning af problemet?

Hilsen Anders


 
 
Troels Arvin (08-08-2003)
Kommentar
Fra : Troels Arvin


Dato : 08-08-03 20:32

On Fri, 08 Aug 2003 17:56:41 +0200, Anders Hellerup Madsen wrote:

> Et produkt er af en bestemt type (f.eks. batterioplader)
Men kan vel kun være af én type?

> type hører et antal test (højspændingstests, belastningstest osv.)
En produkttype kan have tilknyttet fra ingen til adskillige tests?

> Hvert produkt har også en modeltype, som er en slags undergruppe af
> typen (f.eks. oplader til AA batterier)
Kan et produkt være del af flere forskellige modeltyper?

> Hvordan gør jeg det uden at undgå et væld af mange-til-mange relationer.
Det er nok svært at undgå.

> Det bliver jo tæt på et helvede at SELECT'e noget som helst ud af
> databasen
Hvis dit databasesystem understøtter natural joins kan du (hvis du indøver
en passende navnesystematik for kolonner, der er primærnøgler) få nogle
relativt overskuelige og læselige select-udtryk, selvom talrige tabeller
er involveret.

Måske nogle views også kan gøre det mere overskueligt; dog kan man
desværre ikke regne med at kunne foretage updates i views.

> for slet ikke at tale om at få hevet et opdaterbart dataset
> ud.
?

--
Greetings from Troels Arvin, Copenhagen, Denmark


Kristian Damm Jensen (10-08-2003)
Kommentar
Fra : Kristian Damm Jensen


Dato : 10-08-03 21:59

Anders Hellerup Madsen wrote:
> Hej,
>
> Jeg har lidt vanskeligheder med et databasedesign, og selv om jeg har
> fundet en løsning som nok kan bruges, er jeg ikke helt tilfreds og vil
> gerne høre et par andre meninger:
>
> Et produkt er af en bestemt type (f.eks. batterioplader), og til hver
> type hører et antal test (højspændingstests, belastningstest osv.).
> Hvert produkt har også en modeltype, som er en slags undergruppe af
> typen (f.eks. oplader til AA batterier). Jeg skal kunne registere
> produktmodeller, typer, test og testresultater for hvert enkelt produkt.
>
> Hvordan gør jeg det uden at undgå et væld af mange-til-mange relationer.
> Det bliver jo tæt på et helvede at SELECT'e noget som helst ud af
> databasen, for slet ikke at tale om at få hevet et opdaterbart dataset
> ud. Er der nogen der har et anstændigt forslag til løsning af problemet?

Som du beskriver det her, er det (så vidt jeg kan se) enkelt (jeg får
kun to mange-til-mange relationer, begge hænger på Test). Men jeg har
sikker gjort nogle antagelser, der ikke holder i virkeligheden.

Her er mit bud, fortæl mig så, hvilke data, der gør at dette ikke er
godt nok.

Produkt
=======
produkt_id   -- primærnøgle
model_id   -- fremmednøgle
type_id      -- fremmednøgle


Model
=====
model_id   -- primærnøgle

Type
====
type_id      -- primærnøgle

Test
====
test_id      -- primærnøgle

Test_Resultat
=============
produkt_id   -- fremmednøgle, samt 1. del af primærnøgle
test_id      -- fremmednøgle, samt 2. del af primærnøgle

Testes_med
==========
model_id   -- fremmednøgle, samt 1. del af primærnøgle
test_id      -- fremmednøgle, samt 2. del af primærnøgle

--
Kristian Damm Jensen | If you can't take the trouble to
damm (at) ofir (dot) dk | make your posting readable, I
| can't take the trouble to read it.


Anders Hellerup Mads~ (12-08-2003)
Kommentar
Fra : Anders Hellerup Mads~


Dato : 12-08-03 17:18

Kristian Damm Jensen wrote:

[Snip, et udmærket bud]

> Her er mit bud, fortæl mig så, hvilke data, der gør at dette ikke er
> godt nok.

Hej, og undskyld jeg ikke har fået svaret overdrevet hurtigt.

Det er faktisk ret meget den samme løsning jeg selv er nået frem til, og
jeg har mere eller mindre besluttet at det er sådan det skal blive. Jeg
kan godt se jeg måske ikke har beskrevet problemet helt præcist, for det
besværlige ligger hovedsageligt i at en enhed både har en produkttype,
samt tilhører en bestemt udgave af denne type (en produktmodel).

Der kan høre test til både produkttypen og produktmodellen, og for at
gøre det hele endnu mere besværligt så har en enhed ikke fået bestemt
sin produktmodel når den første gang bliver indsat i databasen. Og
produktmodellen kan i nogen tilfælde skifte efter den er blevet angivet.

Ovenstående gør løsningen med en test_resultattabel lidt besværlig fordi
den skal fyldes ud i flere etaper: Først når der vælges produkttype,
senere når der vælges produktmodel, og måske skal der slettes og
tilføjes lidt mere hvis modellen skiftes.

Men jeg har som sagt mere eller mindre lagt mig fast på en løsning der
meget ligner den du har foreslået, og så håndterer jeg de lidt mere
spegede ting ved at kode mig ud af dem.

Tak for hjælpen,
Hilsen Anders



Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste