Bygga en databasdriven applikation - vad tänka på?

Jag är självlärd (nåja, google har lärt mig ) och har gjort några mindre databasdrivna applikationer på jobbet. Jag har byggt programmen både i VBA och VB.NET och lagt upp en databas med olika tabeller i SQL server 2008 Express.

Nu står jag inför att ev bygga lite mer avancerade saker i ASP.NET: en sajt för att ta emot och behandla jobbansökningar. Det är ganska stora volymer vi pratar om och den ska kunna ta emot dokument, man ska kunna "rejta" personer osv.

Vi använder idag en inköpt webbapplikation för detta men den lever inte riktigt upp till våra behov.

I de applikationer jag byggt har jag bekymrat mig så värst mycket för driftssäkerhet mm, eftersom det dels körs inom lokala nätverket och dels är små volymer och enkla tabeller.

Kan jag bara fortsätta som jag gjort hittills eller vad är det jag missar ang säkerhet och drift som jag behöver ta hänsyn till? Någon skillnad måste det väl ändå vara mellan en applikation byggd av heltidsanställda programmerare och en applikation byggd av en hobbyprogrammerare!?

/Cederbusch

Saker SQL ar det forsta jag kommer att tanka pa.

http://msdn.microsoft.com/en-gb/libr...=sql.105).aspx

Tack. Jo lite koll har jag på de bitarna. Det jag egentligen undrar är om jag företar mig att pula ihop en sajt och en databas och sen börjar ansökningarna komma in och inom 1 dygn så har databasen kraschat eller allt buggar ihop helt enkelt för att jag inte haft tillräcklig förståelse för någon mekanism eller sätt att sätta upp sina databaser....

Luddig fråga, jag inser det, men hoppas ngn förstår min fundering.

Mina fem öre efter femton år i branchen:

Jag skulle bygga lagerhanterat i SQL:en om all data och logik ska ligga där.

Tabeller: Innehåller rådata.

Triggrar: Kontrollerar data, varken mer eller mindre. Ingen bearbetning av data i triggrar.

Procedurer: Två typer av procedurer behövs. Din applikation pratar bara med affärslogik-procedurerna. De i sin tur pratar med de dataskyfflande procedurerna som pratar med tabellerna.

Bygg procedurer som är mer åt det generella hållet och klarar av att tabeller byggs ut med fler kolumner.

De bör också skyffla data i stora mängder. Tex i ditt fall så kanske man har två dataskyfflande procedurer för att lista jobbansökarna. En procedur som bara listar grunddatat för alla ansökare och en procedur som listar all personinformation på en ansökare. Dvs inte en procedur för att bara visa en persons email eller liknande. Blir överjävligt att underhålla över tid även om det verkar smidigare för stunden.

Affärslagerprocedurerna tar hand om beräkningar, konverteringar, filtreringar och liknande. Detta för att få koll på var detta händer. Lägger man det i de dataskyfflande procedurerna blir det rörigt efter ett tag.

Namngivning:
Tänk på namngivning av alla databasobjekt. Finns en massa olika filosofier, men det viktigaste är för mig att man är konsekvent och transparent. Som ett exempel, man lagrar persondata i tabellen "person". Man hämtar data därifrån med procedurerna "spGet_person_list" och "spGet_person_detail", lagrar data med proceduren "spSave_person" och raderar med "spDelete_person". (man ska inte döpa procedurer till sp_<nånting> för då kostar det mer prestanda för databasmotorn (den letar bland systemprocedurerna först, där proceduren inte finns för att sedan hitta den bland de användarskapade procedurerna).

Transaktionshantering:
Transaktionshantera inte enskilda procedurer, utan transaktionshantera ett helt flöde, så man kan backa tillbaka till en vettig startpunkt om det går fel. Try/catch i affärslager-procedurerna är mycket trevliga och kompletteras gärna med, för användaren, förklarande felmeddelanden.

Bygg kod som håller över tid. Dvs enkelhet framför superduperspeciallösningar. Få orkar kommentera sin kod (och uppdatera kommentarerna när koden uppdateras), så det är smart att bygga lösningar som enkelt går att förstå genom att läsa koden. För all kod kommer behöva uppdateras, sett över tid och speciallösningar kan sabotera allt vad tidsplanering heter. Kanske du kommer ihåg alla dina speciallösningar åratal efter du skrev dom, men om någon annan ska ta över koden är det en mardröm.

Finns mycket mer att säga om databaseriandet, men nu är det fredag och det är dags att gå från jobbet :-)