Artikelsystem - xml-fil(er) vs databas

Jag håller på och bygger ett artikelsystem som jag ska använda mig av på en kommande sajt. Har gjort ett system byggt på en xml-fil, men har nu kommit till ett antal frågeställningar.

Tanken är att artiklarna så klart kommer att växa i antal, och de kan säkerligen på ett år bli runt hundra artiklar. Man ska även kunna redigera och radera artiklarna.

Frågan är hur snabbt det går att välja en specifik artikel i xml-filen jämfört med att välja en specifik artikel ur en databas med samma struktur, och hur enkelt eller svårt det är att redigera och radera vald artikel ur xml-filen? (Jobba med dataset t.ex.?) Frågan är om man ska ha fyra, fem xml-filer för varje artikelkategori?

Alltså - ska man välja att basera ett artikelsystem på en eller flera xml-filer (helst en xml-fil) eller en databas?

Alla synpunkter och tips tas emot tacksamt. :)

Gällande att editera XML-filer så är det supersmidigt och väldigt enkelt. Så av den anledningen är XML ingen nackdel. Du kan dels använda ett Dataset, XML-document eller helt enkelt XML-serialiseringen av dina klasser.

Den enda riktiga fördelen med en databas är att den är snabbare om din sida har hög belastning. Men jag skulle tippa på att om du använder Cachen rätt och inte har mer än ett par 1000 besökare per dag så är det absolut inga problem.

Även då kan du vidare optimera kod genom att använda tex XmlTextReader som är ruskigt snabb!

fredrik skrev:

Men jag skulle tippa på att om du använder Cachen rätt och inte har mer än ett par 1000 besökare per dag så är det absolut inga problem.

Ett par tusen besökare per dag är det inte fråga om. :) Hur menar du med "använder cachen rätt"? Vad är det jag ska cacha i så fall om jag använder mig av xml-filsläsning med just XmlTextReader?

du kan också lägga ditt dataset i en Application["dittdataset"] och fylla det vid Application_Start så slipper du göra det vid varje postback, och så läser du hela tiden från ditt Application["dittdataset"], på det här sättet får du en applikation som är minst lika snabb som om du skulle använt en databas.. om inte snabbare eftersom allting ligger i minntet. Och skrivs bara till disk om man vill uppdatera eller lägga till en post i dataset:et. Detta passar bra om innehållet på sajten inte är så stort.. när du kommer upp i ett par tusen poster är det nog inte så applicerbart.

fredrik skrev:

Gällande att editera XML-filer så är det supersmidigt och väldigt enkelt. Så av den anledningen är XML ingen nackdel. Du kan dels använda ett Dataset, XML-document eller helt enkelt XML-serialiseringen av dina klasser.

Då är frågan - hur enkelt är det att redigera en specifik artikel i xml-filen? Man kan ju använda ett slags "filter" för att leta rätt på rätt artikel att redigera i xml-filen, men frågan är hur pass långsamt detta "filter" är i så fall - om det nu är långsamt över huvud taget..? Helst av allt vill man ju undvika att ladda en xml-fils data i ett dataset och sen från datasetet välja artikeln man vill redigera..

Helst av allt vill man ju undvika att ladda en xml-fils data i ett dataset och sen från datasetet välja artikeln man vill redigera..

Varför detta?. Att använda ett dataset är det enklaste att använda när man ska uppdatera,lägga till, söka i XML-filer.

Re: Artikelsystem - xml-fil(er) vs databas

m_soderlund skrev:

Alltså - ska man välja att basera ett artikelsystem på en eller flera xml-filer (helst en xml-fil) eller en databas?

Alla gurus jag diskuterat ämnet med (emission, @nders, lärarna osv) för något år sedan har slutat i att databasen vinner fighten. Enklare, snabbare och smidigare. Så jag sätter min peng på databas. :)

XML i all ära, men en databas är totalt övererlägsen XML-filerna i detta sammanhang.

Man kan som fredrik säger snabba upp sidan med att cache hela artiklar i cache-objektet inte applikations-objektet och först kolla om de finns i cachen och finns de inte där så hämtat man artiklen från XML-filerna och lägger i cachen. Det hjälper till med prestandan. Dock så stötter du på problem när du både vill skriva och läsa till samma fil, då det rör sig om en fil så sätter filsystemt begränsningarna och du kan inte både skriva och läsa från en fil samtidigt, så det betyder när du gör en updatering av filen så är den låst så ingen kan läsa ifrån den, nu gör man inte uppdateringar så ofta och de relativit snabbt men kan ändå orsaka problem.

Det finns inget negativt med att stoppa ner artiklarna i en databas endast vinster (förutom att du inte kan "läsa filen med notepad".

Enda fördelen som jag ser med att använda XML-filer istället för en databas skulle vara en fristående applikation som behöver skriva och läsa lokaldata. Då kan man spara ner lite information om en kund exempel och sedan läsa upp den senare utan att behöva ha en databas installerad på maskinen, fast då skulle man lika bra kunna ha en .mbd fil så har man fått en databas automatiskt eftersom windows alltid har med drivrutiner att läsa access-filer.

- M

Jag har fått uppfattningen att dataset är en smula prestandasänkande, om än inte lika mycket som en Datagrid t.ex. Vidare har jag också fått uppfattningen och är nästan medveten om att det går att tillämpa andra metoder där dataset inte används, för att få ut xml-data för exempelvis redigering.

Å andra sidan verkar det som att Dataset är lösningen för mig.

Man kan som fredrik säger snabba upp sidan med att cache hela artiklar i cache-objektet inte applikations-objektet och först kolla om de finns i cachen och finns de inte där så hämtat man artiklen från XML-filerna och lägger i cachen.

Varför tycker du att det är bättre att ha artiklarna spridda i flera filer och lägga dem i cachen istället för att ha 1 dataset och använda Application objektet?.

Dock så stötter du på problem när du både vill skriva och läsa till samma fil, då det rör sig om en fil så sätter filsystemt begränsningarna och du kan inte både skriva och läsa från en fil samtidigt, så det betyder när du gör en updatering av filen så är den låst så ingen kan läsa ifrån den, nu gör man inte uppdateringar så ofta och de relativit snabbt men kan ändå orsaka problem.

Det är just därför man inte ska använda cache objektet eftersom det finns ingen "lock" funktion på det. På Application objektet finns en Application.Lock() Application.Unlock() som förhindrar att flera personer skriver till dataset:et samtidigt.

Varför tycker du att det är bättre att ha artiklarna spridda i flera filer och lägga dem i cachen istället för att ha 1 dataset och använda Application objektet?.

Av den enkla anledningen att det inte finns någon som helst anledning att ladda in en artikel i minnet som aldrig efterfrågas. Alltså skall den först in i cachen när den efterfrågas.

Det är just därför man inte ska använda cache objektet eftersom det finns ingen "lock" funktion på det. På Application objektet finns en Application.Lock() Application.Unlock() som förhindrar att flera personer skriver till dataset:et samtidigt.

Helt ointressant i detta sammanhang då du knappast kommer att skriva till de artiklar som ligger i cachen, utan att du kommer skriva till den artikel som ligger på filen och sedan tar du bort respektive artikel från cachen (om den finns). Då finns det ingen som helst anledning att använda dig av någon "lock" funktion.

cachen bör användas som en read-only funktion, då det är flera besökare som har tillträde till den samtidigt, vill man ändra något som finns i cachen, så ändrar man det ursprungliga objektet/filen/databasraden och seda plockar man bort det inaktuella objektet/filen/databasraden från cachen och nästa gång som objektet/filen/databasraden efterfrågas så hämtas ny korrekt information.

- M

Av den enkla anledningen att det inte finns någon som helst anledning att ladda in en artikel i minnet som aldrig efterfrågas. Alltså skall den först in i cachen när den efterfrågas.

Men hur ska du då bära dig åt när en användare vill söka på artiklar?.
Då måste alla dessa xmlfiler scannas igenom eftersom alla ligger ju inte cachen.

Och ett annat exempel kan vara när du vill lista ingressen på de 4 senaste artiklarna och visa dessa i ett datagrid. Hur ska du hitta dem när dom "flyter omkring" som enskilda objekt i cachen och inte är bundna till något "övergripande objekt" som håller reda på dem och som du använder för att söka med, tex ett dataset som du kan query:a med, ska du då göra nån sorts for loop för att försöka hitta artiklarna antingen i cachen eller på disk?.

Du kommer ändå att behöva 1 "övergripande objekt" som kan hålla reda på artiklarna och detta "objekt" använder du för att söka med och du kan ju inte göra detta på disk i en xmlfil, utan den måste ligga i minnet annars går det för långsamt, och ska du ändå ha en sådan kan du lika gärna ha alltihopa i ett dataset för då har du det samlat på 1 ställe.

Helt ointressant i detta sammanhang då du knappast kommer att skriva till de artiklar som ligger i cachen, utan att du kommer skriva till den artikel som ligger på filen och sedan tar du bort respektive artikel från cachen (om den finns). Då finns det ingen som helst anledning att använda dig av någon "lock" funktion.

Hur förhindrar du att 2 användare skriver till samma xmfil samtidigt om du inte kan locka?.

Och ett annat exempel kan vara när du vill lista ingressen på de 4 senaste artiklarna och visa dessa i ett datagrid. Hur ska du hitta dem när dom "flyter omkring" som enskilda objekt i cachen och inte är bundna till något "övergripande objekt" som håller reda på dem och som du använder för att söka med, tex ett dataset som du kan query:a med, ska du då göra nån sorts for loop för att försöka hitta artiklarna antingen i cachen eller på disk?.

Om man har behovet att visa de 4 senaste artiklarnas ingress så hade jag skapat ett nytt XML-dokument, som hade innehållit just den informationen. Att ladda upp kanske 1000 artiklar i minnet för att visa ingressen på de 4 senaste är (ursäkta ordsrpåket) jävligt korkat ur skalbarahetssynpunkt (ur prestandasynpunkt är det dock bra :) ), även om ram minne är relativt billigt...

Du kommer ändå att behöva 1 "övergripande objekt" som kan hålla reda på artiklarna och detta "objekt" använder du för att söka med och du kan ju inte göra detta på disk i en xmlfil, utan den måste ligga i minnet annars går det för långsamt, och ska du ändå ha en sådan kan du lika gärna ha alltihopa i ett dataset för då har du det samlat på 1 ställe.

Det stämmer inte, det finns ett utmärkt redskap för att söka i filer som ligger på disk och det är indexserver, där kan du även få träffar med relevans.

Hur förhindrar du att 2 användare skriver till samma xmfil samtidigt om du inte kan locka?.

Det behöver jag inte för det gör Filsystemet till mig. Sedan är ju varje artikel sin egen xml-fil vilket gör att risken att 2 olika adminastratörer skall uppdatera samma xml-fil inte så stor. Om allt istället ligger i en fil, så kommer du få ett lås på filen även om det är olika artiklar som skall uppdateras.

I vilket fall som helst så är XML-filerna en dålig lösning till problemet och en databas är vägen att gå (man missar förstås möjligheten med Indexservern) då det ger större fördelar.

- M

Det stämmer inte, det finns ett utmärkt redskap för att söka i filer som ligger på disk och det är indexserver, där kan du även få träffar med relevans.

Om man har behovet att visa de 4 senaste artiklarnas ingress så hade jag skapat ett nytt XML-dokument, som hade innehållit just den informationen. Att ladda upp kanske 1000 artiklar i minnet för att visa ingressen på de 4 senaste är (ursäkta ordsrpåket) jävligt korkat ur skalbarahetssynpunkt (ur prestandasynpunkt är det dock bra ), även om ram minne är relativt billigt...

Enligt din metod så behöver man då följande:

1. Fixa upp en index server.
2. Ladda ner och installera ett XML filter för att index servern ska kunna söka i XML filer
3. Skapa en klass för att styra queryn mot index servern.
4. Skapa en klass för att läsa in xml dokument i objekt som du sedan kan ändra/lägga till artiklar med.
5. Skapa 1 xml fil per artikel, 1000 artiklar=1000 xmlfiler.
6. För att visa "dagens artiklar" måste du skapa ett xml dokument där du kopierat ingressen från de artiklarna du vill visa och länka dessa till artiklarna.
6.1. Och detta xml dokument måste du sedan sätta ihop till ett datatable som datagrid:et kan visa.
7. Varje gång någon ändrar en artikel måste du först:
7.1 Scanna igenom alla 1000 xmlfiler på disk med din index server (eftersom du inte har alla i minnet) för att hitta den du vill ändra.
7.2 Läsa in den med klassen du skapade för att ändra dokument, Ändra filen.
7.3 Skapa om xml dokumentet som visar de 4 senaste artiklarna eftersom ingressen på den artikel du ändrade ligger där.
8.1 Varje gång en användare söker efter efter ett ord i artiklarna måste du först kolla så att de ligger i cachen och om de inte gör det
låta index servern scanna igenom alla 1000 artiklarna på disk för att hitta det ordet i artikeln som användaren söker efter, eftersom du inte har dem i minnet, och slutligen lägg det i cachen.

Verkar vara ganska mycket att hålla reda på. Använder du 1 dataset och 1 tillhörande xmlfil har du allt gratis.

----

De flesta servrar idag har mycket minne, och minne kostar ingenting. Den stora flaskhalsen för en websida idag är när saker ska skrivas/hämtas från disk, och det gäller i synnerhet textfiler såsom xml, man måste verkligen minimera det då, och eftersom det är en tidning så kommer användarna ofelbart också att söka på äldre artiklar och jag kan inte se att det är någon bra ide att söka igenom 1000 xmlfiler på disk där varje artikel ligger i var sin xmlfil, det är en annan sak om det är en databas. Men eftersom minnet inte är ett problem längre är det ett mycket gott alternativ att lagra dem i minnet när det nu bara är högst 1000 artiklar. Ett Application minne delas ju av alla användare på sajten. Så får man ett verkligt högprestanda sajt på köpet.

Och ang. skalbarhet?. Skulle jag vilja byta ut xml filen mot en databas ändrar jag bara 2 rader kod:
DataSet1.ReadXml("filen.xml"); mot SqlDataAdapter.Fill(dataSet1.Tables[0]);
DataSet1.WriteXml("filen.xml"); mot SqlDataAdapter.Update(dataSet1.Tables[0]);