---

Vi skal bringe et produktkatalog online (ca. 8000 emner i 10 kategorier) som
en del af en større website revision. Til formålet har vi lejet en windows
server og udviklingen skal foregå på asp.net frameworket. Vi blev tilbudt en
MS SQL server licens, men desværre er der ikke plads i budgettet lige nu.
Mit spm. er derfor: hvad er det bedste performance alternativ?

Databasen er en ældre db3 og er i princippet parat til web - men er det
smartere at dele load'et i fx. 10 Access databaser, eller burde vi hellere
overveje MySQL? Eller XML? Vi har i gns. 600 unikke besøgende pr. dag (med
et peak på 1000-1100) der pt. henter statiske html filer ned. Det meste
trafik på serveren udgøres af billeder (vi sælger antikviteter og
samlerobjekter).

Gode ideer vil være meget velkomne,
Niels (Bruxelles).

---

Niels Meyer wrote:
> Databasen er en ældre db3 og er i princippet parat til web - men er
> det smartere at dele load'et i fx. 10 Access databaser, eller burde
> vi hellere overveje MySQL? Eller XML?

At spredde loadet over flere Access databaser vil være besværligt i forhold
til udbyttet.

Access har nogle begrænsninger først og fremmest i forbindelse med
indsættelse af data(kan jeres brugere det?) og når vi snakker 8000 emner
begynder access også at køre noget langsomt især ved stort load.

Jeg vil anbefale jer en mySQL, den er hurtig og frem for alt er den jo også
billig. Så må man leve med at man ikke kan bruge subselects. Og .NET og
mySQL kører også fint sammen, du skal blot have installeret et ODBC
namespace fra microsoft.

Afhængig af hvor tit data ændres kunne XML være en ide. Så vil jeg anbefale
at have en XML fil pr. kategori og så bruge .NETs caching features som gør
at man kan cache afhængigt af ændringer i en fil.

--
Jakob Andersen

---

1000 tak, Jacob, for det hurtige svar!

Nej, brugeren kan kun forespørge (men der skal være en opret/edit profil
side hvor brugerne kan angive præferencer - og det kan vel godt være en
lille Access database?)

I mellemtiden har jeg fundet en native mySQL provider til .NET
(http://www.einfodesigns.com/) - måske var det en ide...

Jeg købte 4 bøger om XML (den bedste var klart Wahlins 'xml for asp.net
developers), men det virker som om, at det bliver et kæmpe
programmeringsopgave (XSLT, XPath, Xlink etc). Men måske kunne man afvikle
en Webservice som en del af søge interfacet...

Opdateringsfrekvensen er relativt sjælden - hovedsagligt 6 gange om året i
forbindelse med trykningen af kataloget og der vil ikke være forbindelse til
databasen på intranettet (security). Men jævnligt bliver der trukket noget
ud (i html) til særlige sider på sitet i forbindelse med tilbud og lign.

Jeg har defineret XML strukturen - men endnu ikke XSLT'en - og kørt noget ud
fra db3'en som et forsøg.

Niels


"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:afckdb$abr$1@sunsite.dk...

> Niels Meyer wrote:
> > Databasen er en ældre db3 og er i princippet parat til web - men er
> > det smartere at dele load'et i fx. 10 Access databaser, eller burde
> > vi hellere overveje MySQL? Eller XML?
>
> At spredde loadet over flere Access databaser vil være besværligt i
forhold
> til udbyttet.
>
> Access har nogle begrænsninger først og fremmest i forbindelse med
> indsættelse af data(kan jeres brugere det?) og når vi snakker 8000 emner
> begynder access også at køre noget langsomt især ved stort load.
>
> Jeg vil anbefale jer en mySQL, den er hurtig og frem for alt er den jo
også
> billig. Så må man leve med at man ikke kan bruge subselects. Og .NET og
> mySQL kører også fint sammen, du skal blot have installeret et ODBC
> namespace fra microsoft.
>
> Afhængig af hvor tit data ændres kunne XML være en ide. Så vil jeg
anbefale
> at have en XML fil pr. kategori og så bruge .NETs caching features som gør
> at man kan cache afhængigt af ændringer i en fil.
>
> --
> Jakob Andersen
>
>

---

Niels Meyer wrote:
> I mellemtiden har jeg fundet en native mySQL provider til .NET
> (http://www.einfodesigns.com/) - måske var det en ide...

Der findes et namespace til tilgåelse af mySQL via ODBC som kan hentes fra
microsofts hjemmeside:
<http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/668/
msdncompositedoc.xml>

> Jeg købte 4 bøger om XML (den bedste var klart Wahlins 'xml for
> asp.net developers), men det virker som om, at det bliver et kæmpe
> programmeringsopgave (XSLT, XPath, Xlink etc). Men måske kunne man
> afvikle en Webservice som en del af søge interfacet...

Det løser jo ikke problematikken med opbevaring af data, og er kun aktuelt
hvis resultatet skal bruges eksternt.

> Jeg har defineret XML strukturen - men endnu ikke XSLT'en - og kørt
> noget ud fra db3'en som et forsøg.

Du behøves jo ikke bruge XSLT for at tilgå dine XML data, du kan blot nøjes
med at bruge noget simpelt XPath og så bruge DataSets til at smide dine data
i nogle datagrids.

PS: Kan jeg få dig til at tage et kig på:
<http://www.usenet.dk/netikette/citatteknik.html>

--
Jakob Andersen

---

Igen tak for kommentarerne :) - og for den nyttige side med citat-teknikken!

/Niels

---

"Niels Meyer" <zenondk@hotmail.com> wrote in message
news:gplS8.19860$dT3.884769@news.chello.be...
> Igen tak for kommentarerne :) - og for den nyttige side med
citat-teknikken!
>
> /Niels
>
Jeg synes stadig du skal overveje Access... Så længe der stort set kun er
tale om forespørgsler, så performer den OK. Jeg har ikke den store erfaring
med mySQL, så jeg kan desværre ikke lave en samligning. Men... Jeg ved at
Access er hurtig at gå til, og man lynhurtigt kan få lavet noget der virker.
Naturligvis har man ikke de avancerede funktioner, og skalerbarheden som i
en "rigtig" database, men Access bliver *ofte* undervurderet...

---

"Tumlehund" <patriot@sol.dk> wrote in message
news:3d1acc13$0$10685$4d4eb98e@read.news.dk.uu.net...

> Jeg synes stadig du skal overveje Access... Så længe der stort set kun er
> tale om forespørgsler, så performer den OK. Jeg har ikke den store
erfaring
> med mySQL, så jeg kan desværre ikke lave en samligning. Men... Jeg ved at
> Access er hurtig at gå til, og man lynhurtigt kan få lavet noget der
virker.
> Naturligvis har man ikke de avancerede funktioner, og skalerbarheden som i
> en "rigtig" database, men Access bliver *ofte* undervurderet...
>
Måske har du ret - det er jo også et spørgsmål om udviklingsomkostninger...
Jeg ved ikke ret meget om mySQL, men på den anden side så ved ASP.NET ret
meget om XML (har jeg efterhånden erfaret..) og på en måde vil det være
fascinerende at skrue det hele sammen på den måde. Men hvis det bliver
Access, hvordan ville du så strukturer data - en connection for hver
produktkategori?
Thanx, Niels

---

"Niels Meyer" <zenondk@hotmail.com> wrote in message
news:xvIS8.20036$dT3.906398@news.chello.be...
> Måske har du ret - det er jo også et spørgsmål om
udviklingsomkostninger...
> Jeg ved ikke ret meget om mySQL, men på den anden side så ved ASP.NET ret
> meget om XML (har jeg efterhånden erfaret..) og på en måde vil det være
> fascinerende at skrue det hele sammen på den måde. Men hvis det bliver
> Access, hvordan ville du så strukturer data - en connection for hver
> produktkategori?
> Thanx, Niels
>
Jeg kom i tanke om, at I har planer om at opgradere til SQL Server på et
tidspunkt? I så fald vil *tro* at overgangen vil være nemmere hvis du bruger
Access, da der er en del tools i SQL Server til importere fra Access. Jeg er
ikke klar over hvor let det er med MySQL, anyone? Men jeg ved at det er
forholdsvis smertefrit med Access.

Jeg forstår ikke rigtig hvad du mener med en "connection" for hver
produktkategori? Mener du en relation? For at lave designet må jeg have lidt
flere oplysninger om de data der skal ligge i DB'en... Det ville nok være
smart at lave en tabel med kategorier og så relatere den til en anden tabel
med produkter. Det er nemmest at lave hvis du skriver alle oplysninger ned,
som skal i databasen, og forsøger at gruppere de oplysninger i logiske
enheder. F.eks.:

KATEGORI
kID (PK)
Katgorinavn
[osv.]

PRODUKT
pID (PK)
kID (FK)
Produktnavn
Beskrivelse
Billede
Pris
DatoOprettet
[osv.]

....men som sagt der skal flere oplysninger på bordet for at lave et
ordentligt design.

Jeg synes helt sikkert du skal vælge Access, hvis du kender den i forvejen.
Hvis du har planer om at skifte basen til SQL Server senere, så er der ikke
nogen grund til at begynde at lære et nyt DB system, som du alligevel
skrotter senere (med mindre du har tid og lyst til at lære noget
selvfølgelig...).

---

"Tumlehund" <patriot@sol.dk> wrote

> Jeg kom i tanke om, at I har planer om at opgradere til SQL Server på et
> tidspunkt?...

Ja, det taler også for en Access løsning til at begynde med...

> ...men som sagt der skal flere oplysninger på bordet for at lave et
> ordentligt design.

Jeg vender lige tilbage lidt senere med basisdesignet - og det er pænt at
dig hvis du vil chekke for konsistens :)

Niels

---

"Tumlehund" <patriot@sol.dk> wrote in message
news:3d1c3888$0$17379$4d4eb98e@read.news.dk.uu.net...
> >
> Jeg kom i tanke om, at I har planer om at opgradere til SQL Server på et
> tidspunkt? I så fald vil *tro* at overgangen vil være nemmere hvis du
bruger
> Access, da der er en del tools i SQL Server til importere fra Access. Jeg
er
> ikke klar over hvor let det er med MySQL, anyone? Men jeg ved at det er
> forholdsvis smertefrit med Access.
>
Det er både godt og skidt at Access har de upgrade tools til MSSQL
Imho så er det stort set samme arbejde man skal igennem om "opgraderer" fra
mySQL eller fra Access
Når man opgraderer fra Access så bliver mange af felterne til "forkerte"
datatyper
Feltnavne/attributter brugt i Access er måske ubrugelige i MSSQL pga
reserverede navne
Den måde referentiel integritet bliver gennemtvunget på MSSQL i forbindelse
med en upgrade er heller ikke for smart
Mange SQL statements man hardcoder i sine asp sider, kan med fordel
omskrives til stored procedures osv
Der nogle fordele ved at bruge Access så afgjort ja, men imho bør man se
bort fra "nem" opgradering
Btw så kører rigtig mange websites rigtigt godt sammen med med mySQL, med de
begrænsninger der nu engang med dette produkt

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> wrote

> Det er både godt og skidt at Access har de upgrade tools til MSSQL
> Imho så er det stort set samme arbejde man skal igennem om "opgraderer"
fra
> mySQL eller fra Access

Tak for kommentarerne. Jeg tror nok vi vælger at skrive XML ud fra db3'en og
så importere det til Access. Ifølge programmøren (der arbejder free-lance
for firmaet) vil det blive en dyr affære (og vi er også presset tidsmæssigt)
hvis han skal konvertere den gamle dos baserede (oprindeligt fra 1987)
database til Access 2000/2002. Det er derimod ret nemt at at konvertere
records til XML.
Når vi senere opgraderer (hvis det bliver nødvendigt) til msSQL er det så
ikke lettere at arbejde med en velformet XML db? /Niels

---

>Jeg har ikke den store erfaring
> med mySQL, så jeg kan desværre ikke lave en samligning.

MySQL er hurtigere en Access, men som altid kommer det an på så meget
omkring de konkrete forhold. Jeg er forholdsvis ny i forhold til MySQL, men
kan kun sige, at det er let at gå til.

Når du bruger ASP.NET er cache-mulighederne absolut værd at se på, da de
betyder at databasekaldene kan begrænses rigtig meget og dermed aflaste
databasen (måske endda helt ned til 6 kald om året svarende til Jeres
opdatering?!). Det skulle fx også være muligt at cache flere udager af den
samme side kaldt med forskellige parametre. Access bør derfor ikke udelukkes
af den grund alene.

Angående dataorganisering er jeg ikke helt sikker på, jeg har forstået
situationen. For mig lyder det blot som en enkelt tabel med 8000 poster og
herunder en opslagskolonne med kategorien?

Kim

---

Kim Bach Petersen wrote:
> Angående dataorganisering er jeg ikke helt sikker på, jeg har forstået
> situationen. For mig lyder det blot som en enkelt tabel med 8000
> poster og herunder en opslagskolonne med kategorien?

En fornuftig opbygning ville nok være at have kategorierne i en seperat
tabel og referere vha. en fremmednøgle fra produkttabellen for at have en
relationel model.

--
Jakob Andersen