Vilken databas ska jag använda?

spango skrev:

När ni förespråkar Access, har ni då tänkt på saker som säkerhet, transaktioner, recovery, skalbarhet etc? Nej, tänkte väl det.

Hear, hear! (y)

Förslagsvis så behöver man ju inte skriva systemet så att det inte går att byta databas i ett senare skede.
Access / SQLLite kan användas till en början och sedan när problem med skalbarhet dyker upp så kan man då uppgradera till ett bättre alternativ.

OBS jag rekommenderar inte detta men det är en lösning om man absolut inte har något annat val. Men som sagt bygg det inte specifikt för Access eller SQLLite utan använd NHibernate eller interface om ni skall göra projektet utan någon O/R Mapper dvs.. IDbConnection, IDataReader osv.

Eclipse skrev:

Jag ville mest varna ev. efterkommande till den här tråden från att tro för mycket på Eclipse och gänget som påstår att Access är en helt OK databas för ett skarpt fleranvändarsystem.

Det är ord som får stå för dig. Det har jag aldrig påstått.

Eclipse skrev:

Om du inte öppnar databasen tjugo-elva gånger på varje sida, fungerar Access jättebra, även för större webbplatser.

Btw, vadan din hangup på IDG:s och Shortcuts laddningstider?

NHibernates stöd för Access är bara ~70%igt och stöd finns bara i den gamla versionen. Så det skippar jag. Jag bygger dock ett datalager där allt snack med databasen sköts så att jag enkelt kan byta ut Access i framtiden :) Kanske om man kunde få bättre sponsring på något annat webbhotell (binero? :))

Jag tänker inte ens gå in på vilken DB du skall använda, men jag står bakom Spango i det han säger här... :)

Eclipse skrev:

Om du inte öppnar databasen tjugo-elva gånger på varje sida, fungerar Access jättebra, även för större webbplatser.

Jag skulle bara vilja göra ett förtydligande här. Och det är att om du tänker ANROPA din databas tjugo-elva gånger så är det betydligt bättre att öppna databasen-göra anropet-stänga databasen tjugo-elva gånger än att öppna databasen-göra tjugo elva anrop- stänga databasen.

Sedan är det ju en desginfråga om man verkligen har designat sin applikation rätt om man måste göra tjugo-elva anrop på en sida, ibland måste man det, men väldigt, väldigt sällan... :)

- M

Gladh skrev:

om du tänker ANROPA din databas tjugo-elva gånger så är det betydligt bättre att öppna databasen-göra anropet-stänga databasen tjugo-elva gånger än att öppna databasen-göra tjugo elva anrop- stänga databasen.

Hm, whut? Menar du att overheaden att lämna tillbaks en anslutning till connection poolen och sedan hämta en ny är så liten att den är värd det för att inte hålla en databasanslutning (och har du siffror på't)? Jag skulle nästan ha varit bombis på att de få processorinstruktioner som hinner förflyta mellan två anrop i en normal webbsida skulle ätas upp av den ökade synkroniseringsoverheaden.

spango skrev:

Hm, whut? Menar du att overheaden att lämna tillbaks en anslutning till connection poolen och sedan hämta en ny är så liten att den är värd det för att inte hålla en databasanslutning...

Du fokuserar på prestande och jag på skalbarhet (speciellt mot "en-användars" databas som access, eller om man nu tänker använda filsystemet (typ xml-filer)). Givetviss så tar det mer kraft av processorn att lämna tillbaka en öppen koppling till poolen än vad det tar att ha kopplingen öppen hela tiden. Men då har du inte tänkt på 2 saker som kan sabotera din prestanda när du får last på sida.

1. Din kopplingspool har ett visst antal öppna anslutningar typ 5 som default och en processor maskin kan ha 25 trådar igång (default) det betyder att med din lösning så kan det bli så att du måste öppna 20 nya kopplingar mot databasen för att kunna hantera dessa 25 trådar, medans jag skulle kunna klara mig med de 5 i poolen. Och att öppna en koppling mot databasen jämfört med att använda en från poolen är en betydligt större prestandahit än de få processorcyklar det tar att lämna tillbaka kopplingen till poolen.

2. Inga problem säger du och ökar din pool till 25 öppna anslutningar och tror att livet är okej med det, problemet är bara att du oftas inte är själv om databasen och om din applikation börjar hålla en massa öppna kopplingar mot databasen som inte används så kommer din db kalla in dig för ett "pep-talk".

spango skrev:

(och har du siffror på't)? Jag skulle nästan ha varit bombis på att de få processorinstruktioner som hinner förflyta mellan två anrop i en normal webbsida skulle ätas upp av den ökade synkroniseringsoverheaden.

Nej det har jag inte, och som skrivit ovan så skulle siffrorna få dig att göra tvärtemot vad du borde. Problemet är just dessa "få" processor instruktioner som förflyter mellan dina 2 anrop och det är att DU inte har en anning om när de körs, så du kan tro att du har ju bara en processorrad extra mellan det att du öppnar och stänger din databas, men på just den raden så blev det ett trådskifte och din koppling till databasen (som inte längre används) ligger kvar öppen och blockerar!!!

Men ta inte mina ord för det, ut och sök på nätet det finns massor med information om ämnet, tror jag har skrivit ett par mer grundläggande inlägg om det här på forumet också.

- M

Gladh skrev:

Nej det har jag inte, och som skrivit ovan så skulle siffrorna få dig att göra tvärtemot vad du borde.

Nja, kan man inte få fram siffror som stödjer ens sak har man antingen fel, eller så mäter man fel. Är det som du beskriver bör man få bättre throughput på tungt belastade sidor.

Något jag ser som talar emot att det här verkligen skulle vara som du säger är att varje request lever längre, vilket i sin tur betyder mer context switching, vilket inte heller är speciellt bra ur skalbarhetssynpunkt.

Kan du dela med dig av några länkar, förresten? Att googla på "close database connection" ger inte speciellt matnyttiga resultat (förutom några som säger "öppna bara en gång" ;) ) och min google-fu känns vek idag.

http://articles.techrepublic.com.com/5100-10878_11-6107854.html skrev:

Only open connections when needed. That is, timing is everything, so open a connection just before you need it and not any sooner. Also, close that connection as soon as you are finished with it—don't wait for the garbage collector to do it.

http://www.velocityreviews.com/forums/t69644-openclose-database-connection-for-each-page.html skrev:

Instead, the recommended practice is to open and close your
Connections explicitly whenever you need to connect to the database. As long
as the Connections all use the same Connection String, they will be pooled,

http://stevenclark.com.au/2008/08/22/sql-tip-open-connection-query-close/ skrev:

A more seasoned approach to running queries is to open the door once, grab what you really need, and close it again as you leave.

http://www.guidanceshare.com/wiki/ADO.NET_2.0_Performance_Guidelines\_-\_Connections skrev:

Acquire connections late and release them early. Opening connections before they are needed reduces the number of connections that are available and increases resource pressure. Close connections quickly to ensure that they can be reused as soon as possible. Do not hold on to connections. Holding on to connections reduces the connections that are available to other code and increases resource pressure. The general pattern is to open and close connections on a per-method basis.

Nu skall jag kanske klargöra att om du tänkt dig följande senario så är är det inte mycket vinst med att öppna och stänga efter varje anrop.

db.open();
 db.execute(....);
 db.execute(....);
 db.execute(....);
 db.execute(....);
 db.execute(....);
 db.execute(....);
 db.execute(....);
 db.execute(....);
 db.execute(....);
db.Close();

Utan det skall appliceras på kod som ser ut så här.

db.Open();
 db.Execute(...);
 //-- Do code stuff...
 db.Execute(...);
 //-- Do code stuff...
 db.Execute(...);
 //-- Do code stuff...
 db.Execute(...);
 //-- Do code stuff...
 db.Execute(...);
 //-- Do code stuff...
 db.Execute(...);
 //-- Do code stuff...
db.close();

Då skall du istället använda dig av

db.open();
 db.Execute(...);
db.Close();

//-- do code stuff

db.open();
 db.Execute(...);
db.Close();

//-- do code stuff

db.open();
 db.Execute(...);
db.Close();

//-- do code stuff

db.open();
 db.Execute(...);
db.Close();

//-- do code stuff

db.open();
 db.Execute(...);
db.Close();

//-- do code stuff

db.open();
 db.Execute(...);
db.Close();

//-- do code stuff

- M

Ska sätta tänderna i artiklarna. Tack för tipset!