---

Jeg har et tre tabeller (hér reduceret til need-to-know), hvor
begivenheder i tabellen 'begivenhed' tilknyttes medarbejdere fra
tabellen 'ansatte' via tabellen 'xba'.

Det giver mulighed for at lave en én-til-mange-relation, hvor mange
medarbejdere kan knyttes til én begivenhed.

Medarbejderne er opdelt i kategorier (jobfunktion) og der kan forekomme
begivenheder, hvor alle medarbejdere i én kategori skal med. Umiddelbart
kan det nemt gøres ved at oprette en relationspost i 'xba' for hver
medarbejde i kategorien, men i forhold til brugerfladen vil det være
langt mere overskueligt at kunne vælge 'alle' for hver kategori.

Spørgsmålet er bare, hvordan (eller om) det kan tænkes ind i dette
tabel-layout og i givet fald hvordan?

Jeg bruger MySQL, hvis det skulle gøre nogen forskel.)

På forhånd tak,

Kim


TABLE `begivenhed`
`id` int(11) auto_increment,
`dato` date,
...

TABLE `ansatte` (
`id` int(11) auto_increment,
`kategori` int(11),
`navn` varchar(250),
...

TABLE `xba` (
`begivenhedid` int(11),
`ansatteid` int(11),
UNIQUE KEY `unikxbr` (`begivenhedid`,`ressourceid`)

---

Kim Bach Petersen skrev:
> Jeg har et tre tabeller (hér reduceret til need-to-know), hvor
> begivenheder i tabellen 'begivenhed' tilknyttes medarbejdere fra
> tabellen 'ansatte' via tabellen 'xba'.
> Det giver mulighed for at lave en én-til-mange-relation, hvor mange
> medarbejdere kan knyttes til én begivenhed.

Strengt taget: mange-til-mange.

> Medarbejderne er opdelt i kategorier (jobfunktion) og der kan forekomme
> begivenheder, hvor alle medarbejdere i én kategori skal med. Umiddelbart
> kan det nemt gøres ved at oprette en relationspost i 'xba' for hver
> medarbejde i kategorien, men i forhold til brugerfladen vil det være
> langt mere overskueligt at kunne vælge 'alle' for hver kategori.
> Spørgsmålet er bare, hvordan (eller om) det kan tænkes ind i dette
> tabel-layout og i givet fald hvordan?

Hvis du vil have et fornuftigt design, skal du indsætte en række for
hver medarbejder, hvis alle vælges. Ellers får du problemer med at
skrive queries. Hvad der sker i databasen behøver ikke at afspejle sig i
brugergrænsefladen, så her kan du godt have en pseudo-medarbejder ved
navn "alle", eller en knap, der vælger alle.

/Lars

---

Lars Kongshøj skrev:

> Hvis du vil have et fornuftigt design, skal du indsætte en række for
> hver medarbejder, hvis alle vælges. Ellers får du problemer med at
> skrive queries. Hvad der sker i databasen behøver ikke at afspejle sig i
> brugergrænsefladen, så her kan du godt have en pseudo-medarbejder ved
> navn "alle", eller en knap, der vælger alle.

Det er sådan set også sådan jeg gør nu - altså indsætter én række for
hver medarbejder i kategorien - netop af hensyn til queries og nej, det
er ikke et problem at gøre det, men ...

Mere præcist handler det nok om den anden anden vej: Om jeg på en
elegant kan afgøre om alle i en kategori er tilknyttet en begivnhed?

Kim

---

Lars Kongshøj <lars_kongshoj@hotmail.com> wrote:

> Kim Bach Petersen skrev:
> > Jeg har et tre tabeller (hér reduceret til need-to-know), hvor
> > begivenheder i tabellen 'begivenhed' tilknyttes medarbejdere fra
> > tabellen 'ansatte' via tabellen 'xba'.
> > Det giver mulighed for at lave en én-til-mange-relation, hvor mange
> > medarbejdere kan knyttes til én begivenhed.
>
> Strengt taget: mange-til-mange.

Jep, og jeg vil råde Kim til først at sætte sig ind i E/R diagrammer.
Det hjælper unægtelig på overblikket at have en grafisk fremstilling.

Personligt lærte jeg det gennem følgende bog:

<http://www.pearson.ch/HigherEducation/Addison-Wesley/1471/9780321189561
/Introduction-to-Database-Systems.aspx>

- selv om det nu da vistnok var 1. udgave...

En dansk side:

<http://users.skivehs.dk/ob/database_05f/public_html/data02.html>

Wikipedia:

<http://en.wikipedia.org/wiki/Entity-relationship_model>

hvor det bl.a. ses at der findes flere »konkurrerende« systemer.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe est

---

Kim Bach Petersen skrev
>
> Mere præcist handler det nok om den anden anden vej: Om jeg på en
> elegant kan afgøre om alle i en kategori er tilknyttet en begivnhed?
>
Ved at binde kategorien op på begivenheden i stedet for
"medarbejderen"?
Spørgsmålet er så om det er det du vil?

Dvs kommer der senere ændringer (tilføjelse/sletninger) i kategorien
vil man automatisk blive tilknyttet/fjernet fra begivenheden uanset om
begivenheden er historisk eller ej ...

Jeg har tidligere lavet en ekstra valgmulighed i grænsefladen
(kursuskalender), hvis den bliver valgt laves en masseopdatering så
alle "enheder" i en "kategori" bliver tilknyttet en "hændelse"

- Peter

---

Peter Lykkegaard skrev:

>> Mere præcist handler det nok om den anden anden vej: Om jeg på en
>> elegant kan afgøre om alle i en kategori er tilknyttet en begivnhed?
>>
> Ved at binde kategorien op på begivenheden i stedet for
> "medarbejderen"?
> Spørgsmålet er så om det er det du vil?

Det var jo egentlig en oplagt tanke!

> Dvs kommer der senere ændringer (tilføjelse/sletninger) i kategorien
> vil man automatisk blive tilknyttet/fjernet fra begivenheden uanset om
> begivenheden er historisk eller ej ...

Det vil jeg kun se som et absolut plus.

Lige for at være sikker: Betyder det, at jeg så skal lave en ekstra
relationstabel, der krydser kategorier og begivenheder? Eller er det
enklere at tilføje en ekstra kolonne til den, jeg allerede har?

TABLE `xbk` (
`begivenhedid` int(11),
`kategoriid` int(11),
UNIQUE KEY `unikxbk` (`begivenhedid`,`kategoriid`)

TABLE `xba` (
`begivenhedid` int(11),
`ansatteid` int(11),
`kategoriid` int(11),
UNIQUE KEY `unikxbr` (`begivenhedid`,`ressourceid`,`kategoriid`)



Kim

---

Kim Bach Petersen wr
> TABLE `xbk` (
> `begivenhedid` int(11),
> `kategoriid` int(11),
> UNIQUE KEY `unikxbk` (`begivenhedid`,`kategoriid`)
>
> TABLE `xba` (
> `begivenhedid` int(11),
> `ansatteid` int(11),
> `kategoriid` int(11),
> UNIQUE KEY `unikxbr` (`begivenhedid`,`ressourceid`,`kategoriid`)

Bare lige et godt råd...
Kald dine tabeller noget signende, også noget som du kan forstå om 3 år
- eller personen efter dig kan forstå.

Tænk hvis du lige pludselig har 10 tabeller der hedder fx.
xca xck xba xbk.
(Eller ihvertfald beskriv hvad tabellen gør i kommentar feltet!)

PS
Har selv haft samme opfattelse at kalde det noget kort og rimelig
præcist, men 1 år efter, og mange nye tabeller kommet til, så var det
næsten umuligt at huske og finde rundt i.

---

Martin skrev:
> Kald dine tabeller noget signende, også noget som du kan forstå om 3 år
> - eller personen efter dig kan forstå.
> Tænk hvis du lige pludselig har 10 tabeller der hedder fx.
> xca xck xba xbk.
> (Eller ihvertfald beskriv hvad tabellen gør i kommentar feltet!)

En løsning kan være at supplere det sigende tabelnavn med et
standardalias, som man så bruger i alle dml-sætninger.

/Lars

---

Lars Kongshøj <lars_kongshoj@hotmail.com> wrote:

> Martin skrev:
> > Kald dine tabeller noget signende, også noget som du kan forstå om 3 år
> > - eller personen efter dig kan forstå.
> > Tænk hvis du lige pludselig har 10 tabeller der hedder fx.
> > xca xck xba xbk.
> > (Eller ihvertfald beskriv hvad tabellen gør i kommentar feltet!)
>
> En løsning kan være at supplere det sigende tabelnavn med et
> standardalias, som man så bruger i alle dml-sætninger.

Ah, kode skal være læsbar - voldsomme forkortelser nedsætter
læsbarheden.

--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe est

---

Per Rønne skrev:
> Lars Kongshøj <lars_kongshoj@hotmail.com> wrote:
>
>> Martin skrev:
>>> Kald dine tabeller noget signende, også noget som du kan forstå om 3 år
>>> - eller personen efter dig kan forstå.
>>> Tænk hvis du lige pludselig har 10 tabeller der hedder fx.
>>> xca xck xba xbk.
>>> (Eller ihvertfald beskriv hvad tabellen gør i kommentar feltet!)
>> En løsning kan være at supplere det sigende tabelnavn med et
>> standardalias, som man så bruger i alle dml-sætninger.
>
> Ah, kode skal være læsbar - voldsomme forkortelser nedsætter
> læsbarheden.

Forstår ikke hvad du mener. Alle bruger aliaser i DML-sætninger, men det
er smartere at bruge en standard-forkortelse for hver tabel i stedet for
a, b, c som visse bruger.

/Lars

---

Lars Kongshøj <lars_kongshoj@hotmail.com> wrote:

> Per Rønne skrev:
> > Lars Kongshøj <lars_kongshoj@hotmail.com> wrote:
> >
> >> Martin skrev:
> >>> Kald dine tabeller noget signende, også noget som du kan forstå om 3 år
> >>> - eller personen efter dig kan forstå.
> >>> Tænk hvis du lige pludselig har 10 tabeller der hedder fx.
> >>> xca xck xba xbk.
> >>> (Eller ihvertfald beskriv hvad tabellen gør i kommentar feltet!)
> >> En løsning kan være at supplere det sigende tabelnavn med et
> >> standardalias, som man så bruger i alle dml-sætninger.
> >
> > Ah, kode skal være læsbar - voldsomme forkortelser nedsætter
> > læsbarheden.
>
> Forstår ikke hvad du mener. Alle bruger aliaser i DML-sætninger, men det
> er smartere at bruge en standard-forkortelse for hver tabel i stedet for
> a, b, c som visse bruger.

Jeg kan finde på at bruge dem i eksempelvis SQL*Plus, det interaktive,
linieorienterede program til Oracle.

Aldrig i permanent kode, som jeg [eller andre] risikerer at skulle rette
i måske år efter.

Jeg er dog klar over at det ikke er alle der skriver 10-finger blindt,
og altså gerne vil spare lidt indtastning. Til gengæld kan de så påregne
megen ekstratid ved rettelser.

At bruge umulige forkortelser kunne tidligere være en nødvendighed, da
man arbejdede med identifikatorer der højst kunne være 6-8 tegn lange,
når vi taler om den betydningsbærende del. Det er så afgjort ikke
længere nødvendigt.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe est

---

Kim Bach Petersen skrev:

> Lige for at være sikker: Betyder det, at jeg så skal lave en ekstra
> relationstabel, der krydser kategorier og begivenheder? Eller er det
> enklere at tilføje en ekstra kolonne til den, jeg allerede har?

> TABLE `xba` (
> `begivenhedid` int(11),
> `ansatteid` int(11),
> `kategoriid` int(11),
> UNIQUE KEY `unikxbr` (`begivenhedid`,`ressourceid`,`kategoriid`)

Nevermind, jeg legede lidt med ovenstående og det virker let og elegant
efter hensigten, så tak for inspirationen!

Kim

---

---

Per Rønne skrev

> > > Ah, kode skal være læsbar - voldsomme forkortelser nedsætter
> > > læsbarheden.
>
> > Forstår ikke hvad du mener. Alle bruger aliaser i DML-sætninger, men det
> > er smartere at bruge en standard-forkortelse for hver tabel i stedet for
> > a, b, c som visse bruger.
>
> Jeg kan finde på at bruge dem i eksempelvis SQL*Plus, det interaktive,
> linieorienterede program til Oracle.
>
> Aldrig i permanent kode, som jeg [eller andre] risikerer at skulle rette
> i måske år efter.
>
Jeg kan ikke se noget problem at bruge et standard alias i en DML
sætning?

eg
Select c.name from tbCustomer c

Eller foretrækker du
Select tbCustomer.name from tbCustomer?

Det bliver vanskeligt at læse i meget komplekse statements der
involverer mange forskellige tabeller

Det bruges også rask væk i namespaces (xml etc)
eg
<x xmlns:edi=''>http://ecommerce.example.org/schema'>
<!-- the "edi" prefix is bound to http://ecommerce.example.org/schema
for the "x" element and contents -->
</x>
http://www.w3.org/TR/REC-xml-names/

Eller som midlertidige variabler i loops - eg C#
eg

foreach (Customer c in _customers)
{
Console.WriteLine(c.Name);
}

- Peter

---

Peter Lykkegaard <plykkegaard@gmail.com> wrote:

> Jeg kan ikke se noget problem at bruge et standard alias i en DML
> sætning?
>
> eg
> Select c.name from tbCustomer c

I dette tilfælde er er naturligvis ingen problemer, men at bruge aliaser
for tabeller gennem views er for meget.

Som et »create view c as (select * from customers);«

Det er noget sådant jeg tænker på.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe est

---

Per Rønne skrev:
> Peter Lykkegaard <plykkegaard@gmail.com> wrote:
>> Jeg kan ikke se noget problem at bruge et standard alias i en DML
>> sætning?
>> eg
>> Select c.name from tbCustomer c
> I dette tilfælde er er naturligvis ingen problemer, men at bruge aliaser
> for tabeller gennem views er for meget.
> Som et »create view c as (select * from customers);«
> Det er noget sådant jeg tænker på.

Nu skrev jeg jo alias og ikke view. Du har således skiftet mening siden
i morges?

Det er langt mere læsbart at skrive

from customer c, street s, account a, ...

end bevidstløst at skrive ligegyldige aliaser som

from customer a, street b, account c, ...

Sidste nævnte måde bruger en del programmører bevidstløst, herunder så
vidt jeg husker forfatteren til den bog du anbefalede.

/Lars

---

Lars Kongshøj <lars_kongshoj@hotmail.com> wrote:

> Per Rønne skrev:
> > Peter Lykkegaard <plykkegaard@gmail.com> wrote:
> >> Jeg kan ikke se noget problem at bruge et standard alias i en DML
> >> sætning?
> >> eg
> >> Select c.name from tbCustomer c
> > I dette tilfælde er er naturligvis ingen problemer, men at bruge aliaser
> > for tabeller gennem views er for meget.
> > Som et »create view c as (select * from customers);«
> > Det er noget sådant jeg tænker på.
>
> Nu skrev jeg jo alias og ikke view. Du har således skiftet mening siden
> i morges?

Nej. Men 'alias' bruges i mange it-sammenhænge, som i UNIX shells.

> Det er langt mere læsbart at skrive
>
> from customer c, street s, account a, ...

Selvfølgelig.

> end bevidstløst at skrive ligegyldige aliaser som
>
> from customer a, street b, account c, ...
>
> Sidste nævnte måde bruger en del programmører bevidstløst, herunder så
> vidt jeg husker forfatteren til den bog du anbefalede.

Det er mange år siden jeg havde den som grundbog i databaser.

--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe est

---

Per Rønne skrev:
>> Nu skrev jeg jo alias og ikke view. Du har således skiftet mening siden
>> i morges?
> Nej. Men 'alias' bruges i mange it-sammenhænge, som i UNIX shells.

Nå. Og hvad kommer det sagen ved? Vi snakkede om brugen i DML-sætninger,
og der er betydningen veldefineret.

/Lars

---

Per Rønne skrev
>
> Det er noget sådant jeg tænker på.

Nok bedre med noget ala ...
"create view vwCustomers as (select * from tblCustomers)"

- Peter :0)