Dumme database-udtræk tvang Cowis skandale-test i knæ

Mit gæt:

1) Ingen DBA har været konsulteret
2) En programmør uden særlige database forudsætninger har designet databasen
3) Databasen er designet indefra Visual Studio (VS)
4) Ukritisk brug af ADO.NET
5) Ukritisk anvendelse af automatisk kode genereret af VS.
6) Ukritisk anvendelse af ORM framework

Med andre ord: Persistenslag og integration af samme er designet af en RAD jockey med et GUI IDE. Den optimale kombination for katastrofe!

Manglende indexering i databasen. Det er det første man tjekker. Den har sikkert stået og fyret hele tabelskanninger af. Amatører.

Det er et godt bud. Dårlig databaseperformance er ALTID applikationsudviklernes skyld, det er aldrig DBA'en der har dummet sig!

Dårlig databaseperformance er ALTID applikationsudviklernes skyld, det er aldrig DBA'en der har dummet sig!

NOT! :-)

Dårlig databaseperformance er ALTID applikationsudviklernes skyld, det er aldrig DBA'en der har dummet sig!

Så sandt som det er sagt :-)

Jo, DBA'er dummer sig ogsaa, men i 95% (et gaet) af tilfaelde med daarlig performance saa er det altsaa en ukyndig programmoer.
Husk venligst at god SQL i MS SQL verdenen ikke noedvendigvis virker i Oracle verdenen.
Saa -Spot on Michael Rasmussen

Nej, der er nok sket det samme som der altid sker i en webapplikation...

Programmøren har da kaldt API'et til at beregne næste spg, og det har da bare hentet dataen fra db...

Ingen har lige gidet at tænke over at man da selvfølgelig cacher ting, så man ikke behøver besøge db hver eneste gang for disse info...

Eller også er der sket det, som oftest sker: systemet er designet med databasen som fokus. Database som center of the world, er nu engang en forkert måde at angribe systemdesign på.

Derudover har en SQL DBA som jeg (og Oracle DBA'ere), en masser værktøjer til at finde manglende indekser, indekser som ikke bliver brugt osv.

Derudover er der gode GUI værktøjer på markedet, som viser hvad databasen venter på, dvs. det som man i Oracle og SQL Server kalder waits.

Som DBA går meget af min tid med at holde øje med og løse performance problemer i såvel købe som egen udviklede applikationer. De fleste af disse problemer handler om indeksering, brug af for store datatyper og manglende optimering af koden til database engine.

Disse problemer kommer fra udviklerne...MEN deres problemer kommer fra et forkert fokus i styringen af og aftestning. De fleste projekter har fokus på features og deadlines, ikke afgrænsning, performance og drift.

Derfor sidder DBA'en typisk sidst i forløbet og skal lege Peter Schmeichel ;) Når jeg skal gøre det, bruger jeg værktøjer, DMV'ere på SQL Servere og kan typisk afslører problemer på en dags tid, uden at glo i log filer.

Det undrer mig at COWI har brugt så lang tid på at finde en løsning. For værktøjerne og scripts ligger frit tilgængelige og kan købes fra dag til dag.

/Kenn

Derfor sidder DBA'en typisk sidst i forløbet og skal lege Peter Schmeichel ;)

Så må i jo finde en mere tidsvarende måde at producere software på, hvor du er en del af det team som producere, og ikke bare et sidste vedhæng, ligesom test mm.

Iøvrigt er rigtig mange systemudviklere ansat fordi de har gode kompetencer på områderne C# & Java, og ikke fordi de nødvendigvis er gode til SQL. Sjovt nok sætter ledelsen dem til at skrive queries, og brokker sig så når det går galt. Udnyt nu kompetencer rigtigt i jeres teams optimalt.

I øvrigt benyttes de relationelle databaser alt for ofte hvor der intet behov er, og hvor data på ingen måde er relationelle. Hvorfor? Fordi det er det eneste folk (også DBA'er) kan finde ud af. Jeg kunne godt tænke mig at høre fra nogle DBA'er som adspurgt kan fortæller hvornår jeg skal bruge BigTable/CouchDB/HBase m.fl., Oracle/MSSQL/MySQL/Sybase/BD2..., eller f.eks. OODB?
Dem er der bare ikke ret mange af, og derfor designes persistensdelen af mange systemer ikke optimalt, da der simpelthen ikke er persistenskompetencer til rådighed, kun RDBMS eksperter.

Det er et godt bud. Dårlig databaseperformance er ALTID applikationsudviklernes skyld, det er aldrig DBA'en der har dummet sig!

Det er både i applikationsudviklerens og DBA'ens interesse at levere en god løsning.

Vi kan alle lave fejl, men så snart der går blame-game i den, slukker man enhver form for forbedringskultur, folk murer sig inde i deres eget professionelle område og ta'r teflondragten på.

Til sidst vælter alle løsninger fordi ingen vil påtage sig opgaver der involverer "de andre", ingen vil kommunikere med "de andre", og man kan ikke identificere fejl, fordi folk skjuler dem for ikke at tabe "the blame-game".

Taberen er så hele IT-afdelingen, måske hele virksomheden. Eller sågar kunden.

Der er så få ting der skal til:
Identificér fejlen.
Ret den.
Lav tiltag der forhindrer gentagelser (involverer oftest samarbejde, dokumentation og kommunikation).

Helt enig. Jeg behøvede vel ikke <sarcasm> tags på ovenstående :-)?

Helt enig. Jeg behøvede vel ikke <sarcasm> tags på ovenstående :-)?

Nej, nej :-)

Bare vi er enige om at din sarkasme skulle levere budskabet om at det ikke er en løsning at tildele skyld(?)

@Nikolaj

Jeg tror meget af det her handler om ganske almindelige menneskelige problemer, som jeg i mine 15 år i IT branchen, aldrig har set løst med nogen software udviklingsmodel.

Det handler ganske enkelt om at jo mere folk bliver presset på deadlines, jo mere får de folk skyklapper på. Så bliver fokus at blive færdig, så chefen ikke bliver sur. På den måde ryge kvalitet og overblik ud af vinduet. Det er jo så ikke udviklerens skyld, men i lige så høj grad eller mere, dem der ligger presset.

Der er vel en grund til at selv NASA klumrer i det, når cheferne presser teknikerne med deadlines.

@Martin

Du har helt ret med "blame-gamet" og det er igen tegn på dårlig ledelse, hvis man presser først på tiden og derefter presser for at finde en syndebuk. Det er heldigvis ikke en kultur jeg har på min nuværende arbejdsplads, men jeg har været i sådanne virksomhedskulturer tidligere.

Jeg opfandt tidligere et begreb jeg kaldte en CMA email (Cover My Ass). Den skrev jeg når jeg så et problem i udviklingen, som typisk en projektleder eller leder, ikke syntes der var tid til at rette.

Jeg har desværre skulle fiske dise frem flere gange, når fejlen betød større nedbrud.

Jeg er lige lidt nysgerrig..

• Hvor mange skoler benytter systemet? Har de hver sine specialiserede tests som lærerne opretter?
• Hvor mange fag?
• Hvor mange klassetrin?
• Hvor mange spørgsmål per test?
• Hvor mange muligheder per spørgsmål?

Lidt estimering: 1500 skoler * 7 klassetrin * 5 fag * 100 spørgsmål/test * 10 svarmuligheder/spørgsmål = ~52.5 mio. tupler. Hvis pkt. 1 bortfalder, er det sølle 35000 tupler.

Mvh,

Jeg tror meget af det her handler om ganske almindelige menneskelige problemer, som jeg i mine 15 år i IT branchen, aldrig har set løst med nogen software udviklingsmodel. Det handler ganske enkelt om at jo mere folk bliver presset på deadlines, jo mere får de folk skyklapper på. Så bliver fokus at blive færdig, så chefen ikke bliver sur. På den måde ryge kvalitet og overblik ud af vinduet. Det er jo så ikke udviklerens skyld, men i lige så høj grad eller mere, dem der ligger presset.

Kvalitet er i den grad afhængig af (ikke en model) men en ordentlig proces. Det har alle andre end størstedelen af softwarebranchen lært - sagde nogen Lean/TPS/Scrum/XP.

Der er vel en grund til at selv NASA klumrer i det, når cheferne presser teknikerne med deadlines.

Dette er vel ren spekulation fra din side, så det kan ikke bruges til noget.

Jeg opfandt tidligere et begreb jeg kaldte en CMA email (Cover My Ass). Den skrev jeg når jeg så et problem i udviklingen, som typisk en projektleder eller leder, ikke syntes der var tid til at rette.

U my brotha'!!!!

Jeg har en email-folder der hedder CMA, hvor jeg gemmmer sendte mails der er rare at hive op af skuffen, hvis der skulle falde brænde ned.

Har dog aldrig haft brug for at vifte med CMA-mails...

Jeg har været ud for lignende i ADO.NET, hvor man bruger LINQ til at lave pseudo SQL til alt muligt, bl.a. som erstatning for SQL adgang til en database.

Dette fungere normalt fint og performance tabet er minimalt ved normalt brug, men når forsøger man at lave dynamisk søgning (svarende til dynamisk opbygget SQL) så er performance tabet enormt. Løsningen er ikke at bruge LINQ til avancerede forespørgsel, specielt dynamiske statements. LINQ giver typesikkerhed og ensartet adgang til forskellige resurser (lister, XML, dB ...)

Tre alternativer:
- Brug SQL stored procedures (logik flyttes ind i dB, dvs. ikke forretningslaget)
- Brug andet mere simpler dB SQL framework (vi bruge http://openhms.sourceforge.net/sqlbuilder/) med mere kontrol, og typisk mister man typesikkerhed.
- Brug SQL selv :-)

PS. søger man på Bing på "sql builder query .net" finder man ikke SQLBuilder, men via Google finder man den med det samme ...

Kvalitet er i den grad afhængig af (ikke en model) men en ordentlig proces. Det har alle andre end størstedelen af softwarebranchen lært - sagde nogen Lean/TPS/Scrum/XP.

Kald det model eller proces...når folk bliver presset, så plejer man at ryge tilbage i menneskelige reaktioner. At tro at disse kan håndteres af en model eller proces er naivt.

Der er en grund til at folk som får meget pres i deres arbejde, øver sig meget i at automatisk at reagerer på en god måde, eksempelvis soldater, politi osv.

Dette er vel ren spekulation fra din side, så det kan ikke bruges til noget.

Læs lidt om Challenger ulykken. Dette skyldtes en fejl i hjælpe raketterne, som havde gummi O-ringe, der ikke fungerede godt i kuldegrader. Teknikerne oplyste ledelsen om dette, som grundet politisk og finansielt pres, valgte at ignorere det.

Det er noget jeg har sat mange gange i mine år i IT branchen. Heldigvis kostede det ikke liv, som Challenger ulykken gjorde.

/Kenn

Rigtig god historie :-) Man halverede kravene til de O ringe tre gange, hver gang man opdagede at de ikke kunne leve op til kravene!!! Man skulle jo nødig forsinke en rumfærge på grund af en O ring!
Og den bedste krølle på historien:
Der var fire kvalificerede leverandører af tanken. De tre lå tæt på afyringsrampen, og kunne lave den i et stykke! Dvs helt uden O ringe. Den fjerde lå i Utah. Så skulle den skæres over i to for at kunne transporteres. Utah ville kun stemme for budgettet hvis Utah leverandøren fik opgaven. Smukt ikke sandt :-)
Vi har brug for et begreb der hedder "Cost of politics" så gode ingeniørmæssige løsninger ikke bliver kompromitteret unødigt.

Kald det model eller proces...når folk bliver presset, så plejer man at ryge tilbage i menneskelige reaktioner. At tro at disse kan håndteres af en model eller proces er naivt.

Fordi du ikke tror på det, eller har prøvet det, betyder det så at det ikke findes? Nej vel. Det er en enøjet og gammeldags tankegang, at tro på at tingene ikke kan forbedres, alting kan altid forbedres.
Det eneste vi kan ændre er måden vi gør ting på, men først når vi ved hvordan vi i dag gør.
Se på Toyota, det handler her om proces, og det handler om at kvalitet er noget man bygger ind i tingene, ikke noget man forsøger at lappe på bagefter. Man kan ikke teste kvalitet ind i et system bagefter, ligegyldigt hvilke scripts eller lignende der så er til rådighed.

Læs lidt om Challenger ulykken. Dette skyldtes en fejl i hjælpe raketterne, som havde gummi O-ringe, der ikke fungerede godt i kuldegrader. Teknikerne oplyste ledelsen om dette, som grundet politisk og finansielt pres, valgte at ignorere det.

Nå men det var rart at vide, at Challenger ulykken også skete på grund af en mangelende eller fejlende proces, og ikke på grund af nogle udvikleres inkompetence, eller manglende kvalitetssikring eller lignende.

&#8730;

Jeg har ligesom dig også set det i mange år i IT branchen, men jeg har til gengæld, modsat dig, også set det modsatte. Altså hvordan ordentlige processer kan reducere mængden af store bommerter. Hvis du ikke tror på det, og mener det er naivt, så er det synd for dig. For jeg kan fortælle dig det virker.

Een ting har du ret i, det er ikke hensigtsmæssigt at presse mennesker, slet ikke ud over deres grænse, og slet ikke i for lang tid.
Problemet du overser er, at det i mange tilfælde ikke er nødvendigt at presse folk i softwarebranchen. Det handler om at tilrettelægge arbejdet så det ikke er nødvendigt. Desværre er det blevet standard at bruge forældede metoder og processer der bygger på at vi presser folk i slutningen.
Det betyder ikke det er rigtigt, det betyder heller ikke, at det er naivt at tro at der er en anden måde at gøre det på.

@Stig

Det er et problem i nogle databaser f.eks. MySQL, men ikke i andre. Hvis de bruger Oracle er det ikke et issue.

Hvis flere "banale" selects kan give anledning til locking i MySQL, så er det da endnu en årsag til ikke at bruge MySQL...

Kun hvis isolation level er repeatable-read eller serializable bør "select for update" kunne låse for andre selects.

Og så er der vel ikke tale om "banale selects" - eller der er valgt en uheldig standard-instilling på ORM'en...

@Jesper
Korrekt!

Jeg har ligesom dig også set det i mange år i IT branchen, men jeg har til gengæld, modsat dig, også set det modsatte. Altså hvordan ordentlige processer kan reducere mængden af store bommerter. Hvis du ikke tror på det, og mener det er naivt, så er det synd for dig. For jeg kan fortælle dig det virker.

Nu er jeg som DBA og tidligere database konsulent jo miljøskadet. Jeg ser jo sjældent på det når det virker ;)

Jeg har ikke sagt at ordentlige processer eller former ikke virker. Men de virker ikke alene. De virker ikke uden at de mennesker som agerer i dem, agerer med hensyntagen og forståelse for at det svageste og stærkeste element i det er mennesker.

Jeg har også oplevet gode projekter (bare sjældent)...og den fællesnævner der var i gode processer er gensidig respekt for forskelligheder, fælles mål og fokus på kvalitet. Så har projekterne været succesfulde med og uden et stort framework.

Jeg synes tit det menneskelige aspekt glemmes i IT verden...ligegyldigt hvad fungerer vi mennesker ikke som maskiner, men som kreative og udførende elementer, som kan styrke eller ødelægge en god proces, alt efter om der er plads til mennesket.

Een ting har du ret i, det er ikke hensigtsmæssigt at presse mennesker, slet ikke ud over deres grænse, og slet ikke i for lang tid.

Ja...både ud over deres menneskelige og faglige grænser.

Problemet du overser er, at det i mange tilfælde ikke er nødvendigt at presse folk i softwarebranchen. Det handler om at tilrettelægge arbejdet så det ikke er nødvendigt. Desværre er det blevet standard at bruge forældede metoder og processer der bygger på at vi presser folk i slutningen.

Jeg tror ikke lige du kan bedømme hvad jeg overser eller ej, udfra nogle få debatindlæg. Jeg kan godt lide processer. Men processerne skal hjælpe de mennesker der er en del af dem, ikke stå i stedet for god menneskelig opførsel og respekt.

Hvis alle deltagere i et projekt arbejder ud fra deres egne styrker og svagheder, gensidig respekt og forståelse osv. Så fungerer alt meget bedre...så er processen med til at strømline og give fælles identifikation.

Uden det bliver enhver proces bare til en ny måde at dunke hinanden i hovedet med...lidt som du gør i denne tråd ;)

/Kenn

@Stig og Klaus

Det er et problem i nogle databaser f.eks. MySQL, men ikke i andre. Hvis de bruger Oracle er det ikke et issue.

Men det er vel næppe relevant i denne sag, da belastningen alt andet lige er ret lille.

Herudover, så kan man af kildekoden til html siderne i testen se at det er noget ASP halløj, så databasen er sikkert noget MS noget (ville ikke undre mig hvis det viser sig at være Access).

Endnu engang kan det kun ærgre mig at alt dette skal foregå bag lukkede døre - der er immervæk smidt 125 millioner af samfundets (vores!) penge efter dette projekt, så det mindste samfundet kunne forlange var et minimum af aktindsigt, også så at man [b]måske[/b] kunne undgå at lave samme fadæse en gang til i fremtiden.

Desværre har de sidste mange it (og tog) skandaler ikke just vist at man vil lære af sine fejl, og at det åbenbart er et mål at det skal være kompliceret, og dermed dyrt (så vennerne kan få ordren).

/Christian

Jeg har ikke sagt at ordentlige processer eller former ikke virker. Men de virker ikke alene. De virker ikke uden at de mennesker som agerer i dem, agerer med hensyntagen og forståelse for at det svageste og stærkeste element i det er mennesker.

Jeg ved ikke hvorfor du tror jeg siger de virker alene.
Men jeg mener det er fundamentet for at at opnå noget af bare en nogenlunde god kvalitet at processen er i orden. Processer handler om at være bevidste om hvad vi laver.

Jeg har også oplevet gode projekter (bare sjældent)...og den fællesnævner der var i gode processer er gensidig respekt for forskelligheder, fælles mål og fokus på kvalitet. Så har projekterne været succesfulde med og uden et stort framework.

Nu er der ikke nogen der snakker store rammeværker, slet ikke mig. Jeg er modstander at proces for processens skyld, men vi er nødt til at sikre at vi ror samme vej, og det er det en veldefineret proces skal sikre.

Jeg synes tit det menneskelige aspekt glemmes i IT verden...ligegyldigt hvad fungerer vi mennesker ikke som maskiner, men som kreative og udførende elementer, som kan styrke eller ødelægge en god proces

Enig, men det er både dit og mit ansvar at ødelæggende individer ikke får lov at sabotere projektet.

, alt efter om der er plads til mennesket.

?

Jeg tror ikke lige du kan bedømme hvad jeg overser eller ej, udfra nogle få debatindlæg.

Nej det kan jeg ikke, det er rigtigt. Dog taler du om at presse mennesker som om det er en nødvendighed i IT, fordi det sker hele tiden (eller sådan opfatter jeg din tekst), og det mener jeg ikke det er.

Jeg kan godt lide processer. Men processerne skal hjælpe de mennesker der er en del af dem, ikke stå i stedet for god menneskelig opførsel og respekt.

Det er der vist heller ingen der har sagt.

Hvis alle deltagere i et projekt arbejder ud fra deres egne styrker og svagheder, gensidig respekt og forståelse osv. Så fungerer alt meget bedre...så er processen med til at strømline og give fælles identifikation. Uden det bliver enhver proces bare til en ny måde at dunke hinanden i hovedet med...lidt som du gør i denne tråd ;)

Føler du dig da dunket i hovedet i denne tråd? Kan du så ikke henvise til hvor jeg dunker dig i hovedet.
Jeg tror på (det er iøvrigt veldokumenteret i flere proces-beskrivelser og metode-apparater), at en god, sund, vedvarende optimeret og veldefineret proces er grundlaget for at skabe noget af en tilfredsstillende kvalitet til et nærmere bestemt tidspunkt.

Hvis du kigger på det jeg henviste dig til, Lean, TPS, Scrum, XP osv. er det alle processer der har mennesket i centrum - så kunne du også lære noget nyt :-).

Kaizen!

Herudover, så kan man af kildekoden til html siderne i testen se at det er noget ASP halløj, så databasen er sikkert noget MS noget (ville ikke undre mig hvis det viser sig at være Access).

Nej jeg håber ikke det er Access...

Desværre har de sidste mange it (og tog) skandaler ikke just vist at man vil lære af sine fejl, og at det åbenbart er et mål at det skal være kompliceret, og dermed dyrt (så vennerne kan få ordren).

Hvis man ikke har en proces kan man jo ikke vide hvor det går galt.

Men det er jo så lykkeligt for dem som hele tiden bliver lige overraskede hver gang de får det samme result med samme input - var der nogen der sagde K02.

Jeg opfandt tidligere et begreb jeg kaldte en CMA email (Cover My Ass). Den skrev jeg når jeg så et problem i udviklingen, som typisk en projektleder eller leder, ikke syntes der var tid til at rette.

Bør en sådan være projektleder?

Hvis en fejl ikke skal rettes, medfører det at:
1. Konsekvenserne heraf skal analysres og dokumenteres.
2. Dele af test skal ekskluderes, da testing ikke giver fornuft, hvis resultatet er belagt med fejl. I stedet, skal det pågældende noteres til at ikke fungere, da det er konstrueret til at fejle.
3. De dele, der er berurt af fejl, er det oftest bedst at fjerne fra produktet, hvis produktet skal fremstå som et fungerende produkt, og ikke kun som første gratis frie demo.

I mange tilfælde, er det dyere, at ikke rette en fejl i tide - end at lade den blive. Dertil kommer udgifterne til analyse, dokumentation, og senere analyse og bortforklaringer, hvis det viser sig, at fejlen førte mere med, end det i første omgang blev vurderet.

Hvis en projektleder ikke mener det er tid til at rette en fejl, vil det ofte være umuligt for programmørerne at aflevere et godt resultat. Dette er dårligt for teamet, og kan medføre stress og frustration. Programmørernes lyst, til at arbejde effektiv mindskes, og reelt tager projektet ofre længere tid i den sidste ende.

Programmørerne ønsker at opnå et ordentligt resultat, men må ikke få muligheden, for at opnå det. Dette er ikke en behagelig situation at sætte en person i.

Ligesom for regnskaber, er det ofte noget galt, når at man får ordre på at ikke rette fejlene. I den sidste ende, skyldes det aldrigt den tid det tager at fjerne fejlene - men derimod prisen, ved at rette dem. I nogle tilfælde, kan retningen af fejl, være et problem, for et "godt" regnskab.

@Claus & Jesper:

Det er et problem i nogle databaser f.eks. MySQL, men ikke i andre. Hvis de bruger Oracle er det ikke et issue. Hvis flere "banale" selects kan give anledning til locking i MySQL, så er det da endnu en årsag til ikke at bruge MySQL...

Det er heller ikke korrekt, såfremt man blot vælger at bruge den rigtige storage-engine (InnoDB).

• Carsten

...såfremt man blot vælger at bruge den rigtige storage-engine (InnoDB)

Kender ikke meget til MySQL, men det svar har jeg hørt før.

Men jeg ved nok til at jeg selv ville vælge en rigtig RDBMS hvis jeg har muligheden (læs evt: http://blog.udby.com/archives/2)...

God lørdag :-)

Nu kan MySQL løbe røven af bukserne på en hel del andre baser til nogle formål + den er så meget billigere.

Og så er den en rigtig RDBMS....

HSQLDB (http://hsqldb.org/) "in-memory" er garanteret hurtigere, og egner sig derfor glimrende til at køre unit-tests på ifm. continous-integration build.

Og den låser med garanti ikke :-)

Men derfor kunne jeg ikke drømme om at anbefale at bruge den til noget mere seriøst...

Hvis din basse ikke løber hurtigt nok, er løsningen næppe at skifte til MySQL...