Ska databasutvecklaren släppa hörnflaggan?

Vi har haft en hel del intressanta diskussioner på jobbet senaste tiden där allt bottnar kring användandet av nästa generation av ADO.NET (EDM) och även LINQ.

Med dessa båda tekniker så kan man exempelvis enkelt skapa en objektstruktur baserad på en relationsdatabas och få stöd för CRUD-operationerna utan att skriva en enda rad kod.

Sett i perspektiv av produktivitet så är detta enormt, all tid som tidigare lades ner på att skriva lagrade procedurer och dataaccessmetoder är som bortblåst och man kan istället fokusera på att använda informationen i sin applikation.

Ett problem som dock uppstår är att tidigare så kunde man i en projektgrupp ha en distinkt skiljelinje mellan applikationsutvecklare och databasutvecklare i form av lagrade procedurer. På detta vis kunde en databasutvecklare göra vad han ville i en databas så länge som den lagrade procedurens parametrar och resultat aldrig ändrade sig. Denne kunde också genomföra mängder av datavalideringar om så önskades.

Om man nu vill nyttja produktivitetsvinsten som man kan erhålla med exempelvis LINQ så fungerar inte detta längre, dvs. en databasutvecklare kan inte längre ändra ett kolumnnamn utan att det slår på något sätt för applikationsutvecklaren, må så vara att det i vissa fall enbart är att ändra i en konfigurationsfil. Det finns ett beroende som inte tidigare fanns där…

Frågan är därmed om det inte är dags för databasutvecklaren att släppa hörnflaggan och komma in i matchen. Att våga bryta ny mark och kanske ansvara för dataaccesslagret skrivet i exempelvis .NET också? I så fall kan man fortsätta göra de förändringar och valideringar man alltid gjort men hela utvecklingsteamet får en produktivitetshöjning.

OK, nu säger några av er som läst på kring EDM:er och LINQ att man kan ju använda lagrade procedurer ändå och då uppstår inte detta problem. Men då undrar jag, vill man inte nyttja tekniken fullt ut?

Comments

• Anonymous
  March 06, 2007
  Det är intressant hur databasutvecklarna alltid får ta smällen, när det egentligen är ett processproblem. Databasutvecklarna behöver definitivt förändras ja, men de måste samtidigt släppas in av utvecklarna och resten av projektteamet. En person (eller flera i en grupp) som sitter i sitt hörn och arbetar på sin del för sig själva är aldrig rätt. Vad som behövs är att utvecklare och databasfolk tillsammans (med testare och andra) bemannar ett team som gemensamt arbetar med alla uppgifter i projektet. På databasrelaterade uppgifter tar förstås databasfolket täten, men de arbetar tillsammans med resten för att alla ska få en bra baskompetens i datahantering. Samtidigt så tar utvecklarna täten i andra uppgifter, men databasfolket behöver definitivt lära sig en del av denna kompetens, t ex för att precis som du säger komma lite längre ut från databasen. Jag ska faktiskt hålla en presentation på fredag på SQL Server Open World i Danmark just om hur databasfolk kan delta i agila projekt och dra nytta av tekniker som t ex testning och refactoring. Ska bli intressant att se vad det blir för reaktioner.

• Anonymous
  March 06, 2007
  I ett litet projekt där beställaren inte förväntar sig en skalbar applikation så är det väl jättebra om man som utvecklare kan använda sig av någon typ av LINQ och därmed snabba upp utvecklingsprocessen. Däremot ser jag det inte möjligt i ett större projekt där man har stora krav på många samtidiga användare och flera hundra/tusen transaktioner per sekund mot databasen. Om man använder SQL-Server 2000 och migrerar till SQL-Server 2005 som lägger ner mer CPU per varje query-plan som skapas och man som utvecklare inte känner till detta och använder sig av ad-hoc-queries istället för parameteriserade frågor eller lagrade procedurer så har man redan där ett stort problem eftersom CPU-lasten kommer öka markant. Detta bara genom att byta databasserver när man som utvecklare troligtvis förväntade sig det motsatta resultatet. Ovanstående var bara ett exempel på många problem som finns att lösa när man bygger en skalbar databaslösning. Andra frågor kan vara: Vilken join skall användas (hash, loop osv?), skall vi göra union istället för att använda OR i vår join? Vilka kolumner hämtas (kan vi skapa ett covering index)? Detta är frågor som jag tycker skall ligga på databasutvecklarnas bord och utvecklarna borde koncentrera sig på att bygga skalbara och lätthanterade applikationer.

• Anonymous
  March 07, 2007
  Känner ni inte igen den här diskussionen. Den är gammal. Det är alltid samma skäl. Anledningen till att peta i detaljerna är alltid att det krävs för riktigt bra prestanda(tidigare har det varit assembler o.dyl) och skälet för att låta bli har varit högre abstraktionsnivå, ökad produktivitet och flexibilitet. I verkligheten händer det visst att man behöver optimera för prestanda, men trenden är alltid densamma. Abstraktionsnivån höjs hela tiden. Överallt. Och det är självklart bra. Vad skall databaskillarna göra då? I kommentarerna står olika saker, att arbeta med samma uppgifter som alla andra i teamet(god tanke), att ansvara för databasaccesslagret i .NET(inte troligt). Problemet med båda är att det är alldeles för annorlunda kunskaper som krävs, personen blir en nybörjare och tappar status. Därför kommer det inte att bli så. Däremot finns det frågor som rör informationens struktur, att definitionen på begreppen är identiska i samtliga fall, att hitta synonymer(att registreringsnummer och fordonsid är samma sak)och homonymer(att begreppet Kund egentligen är flera väldigt olika begrepp beroende på vad det skall användas till). Det som då händer är att databaskillen också går uppåt i abstraktionsnivå. Han tappar inte alls status. Han kan få högre lön för han bidrar mycket mer till att skapa värde för sin organisation. Informationsarkitektur är ett eftersatt område som borde stärkas! Hoppas att det blir så, det vore jättebra för branschen. Läs mer på min blogg: Datateknikelit.blogsome.com

• Anonymous
  March 13, 2007
  Chris: Håller helt med. Jag skulle gärna höra hur det gick på konferensen.

• Anonymous
  March 13, 2007
  Patrik: Du har rätt i sak. Men vad är det som hindrar databasutvecklaren från att ta ett större ansvar och även ansvara för dataaccesslagret? När man använder LINQ så finns ju möjligheten att skriva sina egna lagrade procedurer där man kan trimma det som behövs. Vidare kan man fundera över hur många projekt som verkligen har så mycket transaktioner som du beskriver ovan. Väldigt många system har många användare, men transaktionerna är få och i de flesta fall väldigt korta vilket gör att de servers som driftar applikationerna ligger på ett par procent i CPU-användning. Är det verkligen relevant i det läget att trimma allt i minsta detalj? Jag anser inte det, svarstider i en applikation ska vara snabba, men på millisekundnivå så spelar det ingen roll. Då är det istället viktigare att utvecklings- och förvaltningskostnader är låga. Och det kan garanterat uppnås med användningen av exempelvis LINQ.

• Anonymous
  March 13, 2007
  André: Jag håller inte med gällande statusfrågan. Vad är det för fel att bredda sig? Vad är skillnaden på att skriva CLR-procedurer i SQL 2005 och .NET-kod i dataaccesslagret? Utvecklingsverktygen gör oss produktivare vilket medför att vi kan fokusera än mer på verksamhetsfrågor. Men precis som du skriver så ökar abstraktionsnivån och det möjliggör ju breddning på ett helt annat sätt anser jag. Gällande informationsarkitektur så är det viktigt, men själva modelleringen ska ligga högre upp. Alla kan inte vara kockar...

• Anonymous
  March 14, 2007
  In my current project, we have requirements on logging and auditing of changes in the SQL Server tables.