Vastus: Lähtumine objektidest.

• Andmebaasirakendus on realiseeritud mõnes objektorienteeritud programmeerimiskeeles.
• Sõnasta funktsionaalsed nõuded (kasutuslugude või kasutusjuhtudena).
• Koosta rikkalik valdkonnamudel, millest tekivad lõpuks objektorienteeritud programmi klassid (domain driven design).
• Andmebaas on abiteenus andmete hoidmiseks, töö andmetega (äriloogika) käib rakenduses.
• Andmebaasirakendus on ülesannete ning koodi hulga mõttes "paks" ja andmebaas "õhuke".
• Võimalik, et andmebaasi struktuur kirjeldatakse rakenduse loomise vahendis ja lastakse vahendil enesel andmebaasiobjektid luua.
• Andmebaas ja rakendus suhtlevad mõnda objekt-relatsioonvastenduse vahendit kasutades. Eesmärgiks on andmebaas ja selle keerukus rakenduse arendaja jaoks "ära peita".
• Andmestruktuurid (nt tabelid) tekivad klasside põhjal. Sellises andmebaasis on sageli liigset ja kontrollimatut andmete liiasust, sest tabelite ja klasside struktuuri leidmise parimad praktikad ei ole üks-ühele samad ning antud juhul lähtutakse tabelite leidmisel klassidest. Sellist lähenemist kutsutakse kood kõigepealt (code first) lähenemiseks.
• Andmebaasis on vähe või pole üldse kitsendusi (sest see on ju äriloogika ja see on realiseeritud rakenduses ja seda ei peaks dubleerima).
• Üldiselt on pööratud vähem tähelepanu andmebaasi disaini halbade lõhnade vältimisele, kui rakenduse koodi halbade lõhnade vältimisele.
  • Rakenduse lähtekood on kuningas ja andmebaas lihtsalt abivahend - auk - kuhu peaks saama andmeid kiiresti ära panna ja välja lugeda.
  • Kahetsusväärselt näib  rakenduste ja andmebaaside vahel olevat sageli lai mõtteline lõhe ning liigagi sageli juhtub, et spetsialist, kes on kursis ühe poolega ei tunne hästi teist.
• Andmebaas võib olla rakenduse-spetsiifiline, st seda kasutabki ainult see üks rakendus.
• Kui puudub "suur pilt" e ettekujutus süsteemi üldisest arhitektuurist (mille loomist mõned tänapäeva moodsad paindmetoodikatest arendusmetoodikad vajalikuks ei pea), siis on kerge tekkima andmete liiasus erinevate selliste andmebaaside vahel.
• Kui põhikriteeriumid andmebaasi headuse hindamisel on andmete lugemise/kirjutamise kiirus ja selleks vajaliku koodi lihtsus ning andmebaasi kasutabki ainult üks rakendus (st teiste arendajatega ei pea tööd kooskõlastama), siis siit võib kergesti tekkida tahtmine eksperimenteerida mõne uue "skeemitut" andmebaasi ning (vähemalt reklaami järgi) kiiret lugemist/kirjutamist pakkuva NoSQL süsteemiga.

Lähtumine andmetest.

• Andmebaasirakendus võib olla genereeritud andmebaasi põhjal. Kasutada võib Oracle APEX või pgApex sarnaseid vahendeid, mis pakuvad palju viisareid, visuaalseid komponente ning rakenduse loomist vähese programmeerimise vajadusega/programmeerimise vajaduseta.
• Leia põhilised andmeobjektid (põhiobjektid) ja nende elutsüklid.
• Koosta rikkalik kontseptuaalne andmemudel, millest lõpuks tekib andmestruktuuride (nt tabelite) kirjeldus.
• Funktsionaalsete nõuete kirjelduse saab tuletada elutsüklite kirjeldustest ja kontseptuaalsest andmemudelist.
• Süsteemi südamiku moodustavad andmed (andmebaas). Rakendused on nagu inimese riided, mida sageli (vastavalt moevoolude muutumisele) muudetakse. Andmebaasisüsteem on nagu virtuaalne operatsioonisüsteem.
• Andmebaasirakendus on ülesannete ning koodi hulga mõttes "õhuke" ja andmebaas "paks".
• Andmebaasis on jõustatud palju kitsendusi.
• Andmebaasi disaini halbu lõhnu üritatakse vältida nii palju kui võimalik, sest eksimused siin mõjutavad negatiivselt ka teisi süsteemi osi.
• Andmebaasis ei ole kontrollimatut andemete liiasust (vt andmestruktuuride täiendav normaliseerimine ja ortogonaalse disaini printsiibi rakendamine).
• Andmebaasis on avalik andmete liides, mis moodustub SQL-andmebaasi puhul tuletatud tabelitest ja rutiinidest ning mille kaudu serveeritakse kasutajatele just neid andmeid, mida neil on vaja ning just sellises vormis ja ulatuses nagu neile on vaja.
• Enamasti kasutavad sama andemabaasi erinevad andmebaasirakendused. Andmebaas on nende jaoks ühise tõe allikas.

Loomulikud on võimalikud ka pooltoonid selliste lähenemiste vahel, mis üritavad kombineerida parimat mõlemast.
Lähtumine objektidest on kindlasti väga populaarne ja ilmselt tänapäeval valdav. Aga see ei tähenda, et lähtumine andmetest poleks võimalik ja teatud olukordades igati sobiv.

Täpsemalt on see minu hinnangul sobiv olukorraks kus andmebaasirakenduse näol on tegemist CRUD rakendusega (andmete lugemise ja haldamise rakendusega), mis muuhulgas võimaldavad olemeid erinevate seisundite vahel liigutada.

Sellise süsteem äriloogika moodustub:

• reeglitest andmetele
  
  • SQL-andmebaasides saab kontrolli realiseerida deklaratiivsete kitsenduste ja trigeritega
• reeglitest andmete muutumisele (nt millised seisundimuudatused on lubatud)
  
  • SQL-andmebaasides saab kontrolli realiseerida trigeritega
• reeglitest sellele, kuidas kasutajale andmeid esitades tuleb need teatud viisil kokku panna
  
  • SQL-andmebaasides saab realiseerida vaadetena/hetktõmmistena/tabelifunktsioonidena kogu moodsa SQLi andmekäitluskeele võimsust ära kasutades
• andmemuudatuste tegemisest
  
  • SQL-andmebaasides saab realiseerida andmebaasiserverites talletatud rutiinides

Kõige selle jaoks on väga hea koht andmebaas. Andmekeskset lähenemist propageerib näiteks Helsingi Deklaratsioon (IT-versioon).