Tietokantakehityksen haasteet ja mahdollisuudet - tietokannan erilaiset roolit Ahti Haukilehto FC Sovelto Oyj
Voidaanko tietokannasta edes puhua omana käsitteenään? Tietokantoja ja niiden rooli tietojärjestelmässä on erilainen TietokantaAPI a on erilaisia Tietokannan kehittämismenetelmiä on useita Mieti, mikä sopii kulloinkin kyseessä olevaan tilanteeseen. 2
Tietokannan eri rooli OLTP <-> OLAP Sovelluksen olioiden nukkumapaikka <-> järjestelmien integrointipiste Vain dataa <-> paikka kirjoittaa sovelluslogiikkaa/liiketoimintasäännöt Maksuton lisäosa sovellusalustassa <-> järjestelmän arvokkain palvelu Sovelluksen mukana eturintamassa <-> sisäverkon suojissa, harvojen saavutettavissa Sovelluskohtainen ratkaisu <-> yrityksen keskeinen standardi Referenssidataa <-> vain yhden sovelluksen dataa Huolella suunniteltu <-> Agile 3
Kuvat: Steve Swartz ja Clemens Vasters, Microsoft (Tech Ed 2006)
Kannan käsittelytavat Direct eli Suora käsittely (kanta on käyttävän prosessin vieressä vs. etäkäsittely) Intermediated-käsittely Tapahtumahallinta ACID 2 ph commit Kompensointi Datan jakaminen cache Federointi (konsolidointi) Kannan monistaminen Read Only Read/Write Snapshot (raportointi) 11
blah blah blah blah
Resurssien (datan) käsittely Suora käsittely (dumb access) Sovellus käsittelee resurssia suoraan (passthrough gateway) Viestijonot, tietokannat, palvelut, laitteisto Fiksu käsittely Dataa käsitellään oman layerin kautta Oikein fiksu käsittely Annetaan muiden käsitellä dataa fiksulla tavalla
Datan luonne Esimerkiksi sovellus käsittelee 200 taulua Montaako niistä päivitetään esim. joka minuutti? Entä joka tunti? Tai vain kerran vuorokaudessa, kuukaudessa? tai ei koskaan Peukalosääntö: Vain 10% tauluista on kuumia
Layout Basics: Adding some color to data Updating Northwind PK Territories TerritoryID PK Region RegionID EmployeeTerritories PK,FK1 PK,FK2 EmployeeID TerritoryID PK,FK1,I2,I1 PK,FK2,I4,I3 Order Details OrderID ProductID UnitPrice Quantity Discount FK1 TerritoryDescription RegionID PK FK1,I1,I2 FK2,I4,I3 I5 I6 FK3,I7 I8 Orders OrderID CustomerID EmployeeID OrderDate RequiredDate ShippedDate ShipVia Freight ShipName ShipAddress ShipCity ShipRegion ShipPostalCode ShipCountry RegionDescription PK I2 I1 I4 I3 Customers CustomerID CompanyName ContactName ContactTitle Address City Region PostalCode Country Phone Fax PK I1 I2 FK1 Employees EmployeeID LastName FirstName Title TitleOfCourtesy BirthDate HireDate Address City Region PostalCode Country HomePhone Extension Photo Notes ReportsTo PhotoPath PK I3 FK2,I5,I4 FK1,I2,I1 Products ProductID ProductName SupplierID CategoryID QuantityPerUnit UnitPrice UnitsInStock UnitsOnOrder ReorderLevel Discontinued PK I1 I2 PK Suppliers SupplierID CompanyName ContactName ContactTitle Address City Region PostalCode Country Phone Fax HomePage Categories CategoryID PK Shippers ShipperID CompanyName Phone Static Near Static Dynamic Hot I1 CategoryName Description Picture almost never hardly ever time to time pretty often Lähde: TechEd2003, Clements Vasters
Datan fiksu käsittely Staattinen data Pidä data paikallisessa cachessä (local copy). Ei ACIDhuolia. Voidaan denormalisoida Lähes staattinen data Pidä cachessä (local copy). Ajoittain tsekkaa päivitykset. Dynaaminen data Tee päivitykset dataan (local copy). Cachää huolellisesti. Käytä optimistista lukitusta. Kuuma data Insert on sinun ystäväsi ei update. Kuten myös transaktiot. Aina ACID.
APIt MS tarvinnut useita iterointikierroksia (kuten muutkin) DAO, RDO, ADO, ADO.NET Nyt vakiintunut ADO.NETiin Mutta - vain nimi,.net fx 3.5 tuo DLINQ:n, joka on täysin uusi tapa käsitellä tietokantaa (ja tämän jälkeen Entity Framework) Kantariippumaton käsittely joko ODBC ja käyttäen ODBC SQL-kieltä Sovelluskohtainen sovitettu DA-komponentti Muista, SQL Server 2005+ on sovelluspalvelin 21
Johtopäätöksiä Kaikki tietokannat tai data ei ole samankaltaista Datan luonne vaikuttaa resurssien käyttöön Kaiken datan käsittely samalla tavoin ei ole hyvä ajatus Datan cachäys on fiksua Datan käsittelyn eristäminen palveluksi on erittäin fiksua DataAccess voidaa jakaa pienimpiin osiin patterneihin Tietoarkkitehtuuri on (lähes) tärkein osa sovellusarkkitehtuuria, myös suorituskyvyn kannalta