---

Jeg skal have oprettet ca. 100 tabeller med forskellige navne (samme
feltnavne).

Hvordan gøres dette lettest?

Jeg forestiller mig, at det kan gøres ved hjælp af et array
(tabel(navn1,navn2,navn3...)), men jeg kan ikke få det til at fungere.

---

"Steen H. Pedersen" <steen.harley@pedersen.tdcadsl.dk> writes:

> Jeg skal have oprettet ca. 100 tabeller med forskellige navne (samme
> feltnavne).
>
> Hvordan gøres dette lettest?

Du laver et script i dit yndlingssprog til at generere et SQL script,
som du så kan køre på din DB. I Python eksempelvis:

f = open('filnavn.sql', 'w')
for tabelnr in range(100):
f.write('CREATE TABLE tabel%s (col1 INT, col2 VARCHAR(10), ...)\n' % tabelnr)

Jeg kan ikke forestille mig, hvorfor i alverden du vil have så mange
ens tabeller, men det må du jo om.

Martin

---

"Martin Christensen" <martin.sand.christensen@gmail.com> skrev i en
meddelelse news:87psai7dld.fsf@fangorn.rev.stofanet.dk...
> "Steen H. Pedersen" <steen.harley@pedersen.tdcadsl.dk> writes:
>
>> Jeg skal have oprettet ca. 100 tabeller med forskellige navne (samme
>> feltnavne).
>>
>> Hvordan gøres dette lettest?
>
> Du laver et script i dit yndlingssprog til at generere et SQL script,
> som du så kan køre på din DB. I Python eksempelvis:
>
> f = open('filnavn.sql', 'w')
> for tabelnr in range(100):
> f.write('CREATE TABLE tabel%s (col1 INT, col2 VARCHAR(10), ...)\n' %
> tabelnr)
>
> Jeg kan ikke forestille mig, hvorfor i alverden du vil have så mange
> ens tabeller, men det må du jo om.
>
> Martin

Jeg har ca. 4000 virksomheder (registreret i samme tabel, med SEnr som
index), som alle følger en eller flere, af de ca. 100, aftaler og
overenskomster, som relaterer sig til de forskellige personalegrupper.
For at kunne "styre" hvilke aftaler som er gældende for hvilke virksomheder,
forestiller jeg mig at der skal oprettes en tabel for hver aftale (med SEnr
på virksomheder denne aftale gælder for).
Der er måske en bedre løsning - så er jeg da helt åben for det (og taksom
samtidig) ??!

Steen

---

Steen H. Pedersen skrev:

> Jeg har ca. 4000 virksomheder (registreret i samme tabel, med
> SEnr som index), som alle følger en eller flere, af de ca.
> 100, aftaler og overenskomster, som relaterer sig til de
> forskellige personalegrupper.

Det lyder rimeligt nok. Er aftalerne registreret i forvejen? Hvis
ja, er det så i én tabel?


> For at kunne "styre" hvilke aftaler som er gældende for hvilke
> virksomheder, forestiller jeg mig at der skal oprettes en
> tabel for hver aftale (med SEnr på virksomheder denne aftale
> gælder for).

Det er en rigtig dårlig ide. En aftale er en entitet der hører
hjemme i én tabel. Hvis du ikke allerede har en aftaletabel, så lav
en nu. Den skal indeholde stamoplysningerne om aftalen - men ikke
listen over omfattede virksomheder.

Relationen mellem aftaler og virksomheder er af typen "mange til
mange" - dvs. at 1 virksomhed kan følge flere aftaler og 1 aftale
kan dække flere virksomheder. Når man skal modellere det i en
database, opretter man en ny tabel der som udgangspunkt kun
indeholder primærnøglerne fra de to tabeller i relationen (altså fx
SE-nr og aftaleNr). Hver post i samlingstabellen knytter præcis 1
virksomhed med 1 aftale. Hvis det er relevant, kan man gemme
oplysninger der vedrører relationen i samlingstabellen - det kan fx
være dato for tilknytningen af virksomheden til den pågældende
aftale.


> Der er måske en bedre løsning - så er jeg da helt åben for det
> (og taksom samtidig) ??!

Jeg vil anbefale dig at låne eller købe en bog om databasedesign.
Jeg har selv Databasehåndbogen af Joakim Dalby. Det er en gammel
sag, men han forklarer de grundlæggende principper om opbygning og
normalisering af data ganske godt.
--
Bolig søges. Andel eller leje i Emdrup, Nordvest, Nørrebro, Søborg
eller Brønshøj, max 6000 pr. måned.
Kontakt pr. mail - nospam(at)gyros.dk
Jens Gyldenkærne Clausen

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns989CB26E591BEjcdmfdk@gyrosmod.dtext.news.tele.dk...
> Steen H. Pedersen skrev:
>
>> Jeg har ca. 4000 virksomheder (registreret i samme tabel, med
>> SEnr som index), som alle følger en eller flere, af de ca.
>> 100, aftaler og overenskomster, som relaterer sig til de
>> forskellige personalegrupper.
>
> Det lyder rimeligt nok. Er aftalerne registreret i forvejen? Hvis
> ja, er det så i én tabel?


Ja - tabellen Aftaler har felterne Aftalenr, Navn, Indhold (lidt mere
kompleks i virkeligheden)


>> For at kunne "styre" hvilke aftaler som er gældende for hvilke
>> virksomheder, forestiller jeg mig at der skal oprettes en
>> tabel for hver aftale (med SEnr på virksomheder denne aftale
>> gælder for).
>
> Det er en rigtig dårlig ide. En aftale er en entitet der hører
> hjemme i én tabel. Hvis du ikke allerede har en aftaletabel, så lav
> en nu. Den skal indeholde stamoplysningerne om aftalen - men ikke
> listen over omfattede virksomheder.
>
> Relationen mellem aftaler og virksomheder er af typen "mange til
> mange" - dvs. at 1 virksomhed kan følge flere aftaler og 1 aftale
> kan dække flere virksomheder. Når man skal modellere det i en
> database, opretter man en ny tabel der som udgangspunkt kun
> indeholder primærnøglerne fra de to tabeller i relationen (altså fx
> SE-nr og aftaleNr). Hver post i samlingstabellen knytter præcis 1
> virksomhed med 1 aftale. Hvis det er relevant, kan man gemme
> oplysninger der vedrører relationen i samlingstabellen - det kan fx
> være dato for tilknytningen af virksomheden til den pågældende
> aftale.
>

Lige præcis dét der er meningen, og derfor havde jeg forestillet mig en
tabel med aftalenummeret som tabelnavn og Lokalkode, SEnr, felt3... som
indhold
(feltet Lokalkode henviser til tabel med adressen på den specifikke afdeling
af/i virksomheden) - Jeg skal lige tilføje, at jeg nu har fået øjnene op
for, at det skal være Lokalkoden (og ikke SEnr), som er primary key - og tak
for det.

Jeg beklager hvis jeg har stillet spørgsmålet lidt for simpelt, men hvis
løsningen er at lave tabel for hver aftale (med tilsluttede virksomheder
afdelinger), er spørgsmålet det samme:

Hvordan vil en CREATE TABLE se ud hvis den skulle oprette en række af
"ens" tabeller ud fra en given liste med tabellernes navne?

Under alle omstændigheder: Tak for svaret - som du kan se, er der rettet en
ikke uvæsentlig fejl i mit første design.

---

Steen H. Pedersen wrote:

> Hvordan vil en CREATE TABLE se ud hvis den skulle oprette en række
> af "ens" tabeller ud fra en given liste med tabellernes navne?
>
Det gør man ikke da man ikke vil have en jordisk chance for at lave en
søgning i alle aftaler
Men ellers så har Martin skitseret en metode

- Peter

--
Hi! I'm a .signature *virus*!
Copy me into your ~/.signature to help me spread!

---

Steen H. Pedersen skrev:

> Lige præcis dét der er meningen, og derfor havde jeg
> forestillet mig en tabel med aftalenummeret som tabelnavn og
> Lokalkode, SEnr, felt3... som indhold

- og det er så stadig en dårlig ide.

Tabelnavne skal ikke henvise til enkelte elementer (som en aftale),
men til grupper af elementer. Du har heller ingen mulighed for at
fortælle databasen at der er sammenhæng mellem værdien a423 i
aftaletabellen og indholdet i tabellen med navnet a423.

Du skal i stedet bruge én tabel til at koble aftaler og
virksomheder sammen - aftalenummeret bliver så et felt på samme
måde som SE-nr, lokalkode eller hvad du nu bruger som primærnøgle i
virksomhedstabellen. Der skal *kun* være et id-felt fra
virksomhedstabellen - et af principperne bag godt databasedesign er
at man ikke gemmer samme oplysning flere gange. Hvis der er mere
end to felter - id-felterne fra hhv. aftale- og virksomhedstabellen
- i din samlingstabel, skal det være felter der gemmer oplysninger
der relaterer sig direkte til sammenkædningen af de to poster.


> Jeg beklager hvis jeg har stillet spørgsmålet lidt for
> simpelt, men hvis løsningen er at lave tabel for hver aftale

Det er det ikke. Hvis du står med en løsningsmodel der kræver at du
opretter en ikke-fastlagt antal tabeller (typisk en for hver post i
en eksisterende tabel), er det *stor* sandsynlighed for at det er
en dårlig model der bør skrottes omgående.

Jeg vil gentage min opfordring fra før om at låne eller købe en bog
om databasedesign. Det kan spare dig for mange fejltagelser.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jeg takker mangen gange for de mange svar, og uden at vide hvad det var der
udløste det gav svaret sig selv - tror jeg
(ingen tvil om at det var de mange "så tænk dig dog om")

Jeg forsøger mig med løsningen 3 tabeller
SE
med Virksomhedens navn osv.

Aftale
med aftalernes indhold m.v.

Lokalkode
med Lokalkoden som primary key
SEnr
Aftalenr

Det ikke alene at jeg fik løst mit egentlige problem (skal bare angive 2
kriterier i søgningen - jokode og lokalkode), men også, at jeg ved at angive
lokalkoden og/eller jobkoden kan fange samtlige eller et bredere udsnit.

Hvis overskrifterne i morgen lyder på at en mand på Skibbyegnen har knust
muren til rådhuset med sin pandeskal - så ved i hvem.
Nogen gange kan man (jeg) ikke se skoven for bare træer.

Tusind tak - det kunne jeg have stirret mig blind på længe.

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> writes:

> Jeg vil gentage min opfordring fra før om at låne eller købe en bog
> om databasedesign. Det kan spare dig for mange fejltagelser.

'Me too' er godt nok et dårligt bidrag til en diskussion, men jeg vil
dog alligevel lægge min vægt bag Jens' opfordring. Det er på ingen
måde en slet skjult 'RTFM, n00b!!!!!11', men derimod en erkendelse af,
at godt databasedesign ikke altid er indlysende for begyndere, og at
man sparer sig for mange kvaler ved at læse lidt på lektien før man
går i gang i stedet for at begå samtlige begynderfejl, for derefter at
smide det hele ud og lave det rigtigt bagefter. Man kommer altså
rigtigt langt ved lige at tilegne sig lidt grundviden først.

Martin

---

Jens Gyldenkærne Clausen skrev:
>
> Det er det ikke. Hvis du står med en løsningsmodel der kræver at du
> opretter en ikke-fastlagt antal tabeller (typisk en for hver post i
> en eksisterende tabel), er det *stor* sandsynlighed for at det er
> en dårlig model der bør skrottes omgående.
>
Man kan sammeligne det med at man ville gemme et dokument på hver sin
computer (uden netværksadgang)
Det burde give et billede på den indre nethinde der fortalte een at
det måske ikke var så smart alligevel at lave en tabel for hver
aftale :)

Løsningen er måske lavet fordi de forskellige aftaler stiller
forskellige krav til antal og type af felter i tabellen - men det burde
kunnne løses på en mere smidig måde

- Peter