---

Hej,

Jeg administrerer et site, som bl.a. indeholder en artikeldatabase.
Databasen er i MS Access 2000, men den er nu ved at blive lidt stor
(ca. 10 MB).
Så jeg overvejer, om det er tiden at konvertere til MS SQL, som vores
webhotel (Wannafind) tilbyder til 50 kr. ekstra pr. måned (for 50 MB).

Jeg har aldrig arbejdet med MS SQL før, så der er selvfølgelig en
læreproces involveret. Men bortset fra det:

Har databasens *størrelse* nogen særlig betydning for, om Access kan
"do the job"?
Eller handler det mest om *trafik-mængden* (som ikke er voldsomt stor
på sitet)?

Og hvis størrelsen har en betydning: Er 10 MB et problem?
Jeg har ikke opdaget - eller hørt om - at der skulle være problemer
endnu, men hellere forebygge end helbrede ...

Desuden: Når Wannafind tilbyder en MS SQL database på 50 MB, svarer
det så i grove træk til en MS Access database af samme størrelse?

Til sidst: Til dette formål (en artikeldatabase, hvor der ikke er
nogen bruger-tilføjelses-muligheder eller lign.), er det en stor
behagelighed, at man lige kan downloade databasen og så opdatere,
rette fejl etc. lokalt på sin PC.
Men det er vel ikke en mulighed med MS SQL?

Hvis jeg har forstået det rigtigt, så foregår al administration og
opdatering online. Så det er lidt mere besværligt at "eksperimentere"?


Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen skrev:

> Jeg administrerer et site, som bl.a. indeholder en
> artikeldatabase. Databasen er i MS Access 2000, men den er nu
> ved at blive lidt stor (ca. 10 MB).

Kan du mærke det på tilgangstiden til siderne?


> Har databasens *størrelse* nogen særlig betydning for, om
> Access kan "do the job"?
> Eller handler det mest om *trafik-mængden* (som ikke er
> voldsomt stor på sitet)?

Så vidt jeg ved er det primært på trafik-mængden - og i særdeleshed
mængden af samtidige handlingsforespørgsler (indsæt/opdater/slet) -
at MSSQL giver Access baghjul.


> Desuden: Når Wannafind tilbyder en MS SQL database på 50 MB,
> svarer det så i grove træk til en MS Access database af samme
> størrelse?

Det afhænger af om de/du bruger SIMPLE eller FULL som recovery
model - samt lidt af deres backup-politik. MSSQL-databaser består
typisk af to filer - en databasefil (.mdf) og en log-fil (.ldf).
Hvis man bruger FULL, kan man via log-filen lave restore til et
vilkårligt tidspunkt i loggens historie. Derfor er det med denne
indstilling vigtigt at lave backup af log-filen, ellers vil den
vokse uhæmmet. I SIMPLE mode kan man kun lave restore til en fuld
backup - dvs. typisk en gang i døgnet.


> Til sidst: Til dette formål (en artikeldatabase, hvor der ikke
> er nogen bruger-tilføjelses-muligheder eller lign.), er det en
> stor behagelighed, at man lige kan downloade databasen og så
> opdatere, rette fejl etc. lokalt på sin PC.
> Men det er vel ikke en mulighed med MS SQL?

Du kan muligvis få direkte adgang til basen via de værktøjer der
følger med MSSQL; men det er som du er inde på "online" adgang.
Hvis man vil eksperimentere, kan man lave en backup og hente den
hjem - hvis man ikke kan klare sig med at oprette en midlertidig
tabel til at lege med online.
--
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

---

On Wed, 10 May 2006 22:37:00 +0200, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote:

>Jørn Andersen skrev:
>
>> Jeg administrerer et site, som bl.a. indeholder en
>> artikeldatabase. Databasen er i MS Access 2000, men den er nu
>> ved at blive lidt stor (ca. 10 MB).
>
>Kan du mærke det på tilgangstiden til siderne?

Nej.

>> Har databasens *størrelse* nogen særlig betydning for, om
>> Access kan "do the job"?
>> Eller handler det mest om *trafik-mængden* (som ikke er
>> voldsomt stor på sitet)?
>
>Så vidt jeg ved er det primært på trafik-mængden - og i særdeleshed
>mængden af samtidige handlingsforespørgsler (indsæt/opdater/slet) -
>at MSSQL giver Access baghjul.

Den slags er der kun nogen af, når der indlægges nye artikler. Og
eftersom det sker med copy-paste fra original-kilder vil de aldrig
være samtidige. Ellers er der kun SELECT-forespørgsler.

Tak for dine gode svar.
Den foreløbige konklusion er, at det ikke endnu er umagen og pengene
værd at opgradere.

Et side-spørgsmål, når jeg nu er i gang:
Den nævnte database er opbygget, så selve databasen indeholder såvel
artiklernes forfatter(e), overskrifter, brødtekst osv.
HTML-formatteringen sker så primært gennem at køre output gennem nogle
Replace-filter-funktioner.

Jeg har en anden løsning som er opbygget, så selve databasen ikke
indeholder artiklernes brødtekst, men kun forf., overskrift osv., men
så i stedet links til en (HTML-formatteret) include-fil.

Den sidste giver en væsentligt mindre database, og giver noget mere
fleksibilitet mht. sidernes udseende, men er omvendt lidt vanskeligere
at administrere, da der skal laves lidt mere manuel HTML-formattering.

Hvilken løsning ville du/I foretrække?
Eller er det bare umuligt at give et generelt svar på?

Jeg var på et tidspunkt ved at lege med en XML-løsning, hvor
artiklerne skulle gemmes i XML-format fra Word-filer og derfra
konverteres til HTML-filer med ASP.

Men da jeg ikke er særligt dus med XML, lykkedes det mig aldrig at få
den til at levere et validt HTML-output - og så gik projektet i stå
for mig.

Det skulle vel ellers være den principielt "rigtige" metode at bruge
XML som lager-format - ?

Jeg ville gerne ende med at have mulighed for at kunne generere
forskellige formater (HTML, Word, PDF m.v.) fra samme kilde, altså
uden at skulle være nødt til at gemme artiklerne i hvert af disse
formater.

Nogen ideer til en løsning, der virker i praksis?
Artiklerne kan indeholde billeder/grafik, men ellers hovedsageligt
tekst.

Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen skrev:

> Et side-spørgsmål, når jeg nu er i gang:
> Den nævnte database er opbygget, så selve databasen indeholder
> såvel artiklernes forfatter(e), overskrifter, brødtekst osv.
> HTML-formatteringen sker så primært gennem at køre output
> gennem nogle Replace-filter-funktioner.


Fordele ved denne model:
- Man har brødteksten nært knyttet til artiklen. Der er derfor ikke
den store risiko for at en brødtekst "forsvinder" fordi
includefilen er blevet slettet eller ændret uden at databasen er
opdateret - eller omvendt. Det er også enkelt at flytte databasen,
eller hente den hjem og arbejde med.

Hvis du på et tidspunkt skifter til MSSQL, kan du benytte
fuldtekstindeksering til at lave gode søgemuligheder i brødteksten.
Dog vil Google eller lignende ofte kunne lave en helt
tilfredsstillende søgning hvis siden blot kan nås fra nettet.


> Jeg har en anden løsning som er opbygget, så selve databasen
> ikke indeholder artiklernes brødtekst, men kun forf.,
> overskrift osv., men så i stedet links til en
> (HTML-formatteret) include-fil.

Med ovenstående model kan man, som du selv er inde på, formatere
koden friere end med databasedelen. Det kan også hjælpe med at
begrænse databasens størrelse, men til gengæld bliver
vedligeholdelsen af data mindre logisk når man har dele der ligger
uden for basen.


> Hvilken løsning ville du/I foretrække?

Jeg vil nok primært foretrække modellen med teksterne i databasen.
Hvis det er store artikler, vil jeg dog anbefale at lægge
brødteksterne i deres egen tabel, så man kan arbejde med resten af
felterne uden at skulle trækkes med det tunge læs fra brødteksten.

Det kunne være en opbygning a la:

ARTIKLER
   artikelID
   forfatterID
   overskrift
   oprettet
   sidst_redigeret
   ...

ARTIKELTEKSTER
   artikelID
   tekst


> Det skulle vel ellers være den principielt "rigtige" metode at
> bruge XML som lager-format - ?

Tjo - jeg ved nu ikke om XML skulle være mere "rigtigt" end en
databaseformat - det er bare mere portabelt.
--
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

---

On Thu, 11 May 2006 12:35:03 +0200, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote:

>Jørn Andersen skrev:
>> Databasen indeholder også brødtekst osv.
<snip>

>Fordele ved denne model:

Ulempen er så også, at man er nødt til at vælge mellem at lave
formattering i selve database-feltet eller også have meget rigide krav
til præsentationen.
I den anvendte model (som jeg ikke selv har lavet) er der fx muligt
for at knytte max. ét billede til hver artikel, og hvor placeringen er
givet på forhånd (her: øverst til venstre under overskriften).

<snip en masse fornuftigt>

>> En anden løsning med links til en (HTML-formatteret) include-fil.

>til gengæld bliver vedligeholdelsen af data mindre logisk
>når man har dele der ligger uden for basen.

Exactly.

<snip>
>Hvis det er store artikler, vil jeg dog anbefale at lægge
>brødteksterne i deres egen tabel, så man kan arbejde med resten af
>felterne uden at skulle trækkes med det tunge læs fra brødteksten.

God idé til når der snart alligevel skal revideres.

<snip>
>> Det skulle vel ellers være den principielt "rigtige" metode at
>> bruge XML som lager-format - ?
>
>Tjo - jeg ved nu ikke om XML skulle være mere "rigtigt" end en
>databaseformat - det er bare mere portabelt.

Ja, og det er nok sagens kerne. Jeg er hidtil veget tilbage fra (det
er den slags man kan tillade sig, når det er noget, man ikke får penge
for :) at udbygge med Word- og PDF-mulighed, fordi der alligevel ikke
er så meget at hente, fordi strukturen alligevel er så "stiv" som den
er nu - specielt med hensyn til indsættelse af billeder eller bare
moderat speciel formattering.

Er løsningen at udvikle nogle simple (og veldefinerede)
formatteringskoder, som så har hver sin omsætning til hhv. HTML, Word
og PDF?
Eller hvad gør "de professionelle"?

Det er her jeg synes, at XML-formatet i princippet "ser ideelt ud",
fordi det jo giver en struktur, som simpel tekst i et Memo-felt ikke
har.

Mvh. Jørn

--
Jørn Andersen,
Brønshøj