Tõde eelkõige, või miks süsteemi tuleb projekteerida, lähtudes andmebaasi struktuurist

Tere, Habr!

Me jätkame teema uurimist Java ja Spring, sealhulgas andmebaaside tasemel. Täna soovitame lugeda, miks suuremate rakenduste kavandamisel peaks andmebaasi struktuur, mitte Java-kood olema otsustav, kuidas seda tehakse ja millised erandid selle reegli osas on.

Selles üsna hilinenud artiklis selgitan, miks arvan, et peaaegu kõigis juhtudel peaks rakenduse andmemudel olema kavandatud 'andmebaasist lähtuvalt', mitte 'Java võimalustest lähtuvalt' (või muust kliendikeelest, millega töötate). Kui valite teise lähenemise, astute pika valu ja kannatuste teele, kui teie projekt hakkab kasvama.

Artikkel on kirjutatud inspiratsiooniks ühele küsimusele, mille esitas Stack Overflow'is.

Huvitavad arutelud reddit'i osades /r/java ja /r/programming.

Koodi genereerimine

Ma olin hämmingus, et on nii väike kasutajate kiht, kes, tutvudes jOOQ'ga, kurdavad selle üle, et jOOQ puhul toetutakse tõsiselt koodi genereerimisele. Keegi ei takista teil kasutada jOOQ'd nii, nagu soovite, ja ei sundi teid koodi genereerimist kasutama. Kuid vaike seadistuse (nagu on kirjeldatud juhendis) puhul töötab jOOQ nii: alustate (pärandatud) andmebaasi skeemist, viite läbi selle tagasiprojekteerimise jOOQ koodi generaatori abil, et luua klasside kogum, mis esindab teie tabeleid, ja seejärel kirjutate tüübisoodsad päringud nende tabelite jaoks:

	for (Record2 record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Tüüpide teave on tuletatud
//   genereeritud koodist, millele viidatakse allolevas
//   SELECT tingimuses

       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ genereeritud nimed
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

Kood genereeritakse kas käsitsi väljaspool koostamist või käsitsi iga koostamise ajal. Näiteks selline regeneratsioon võib toimuda kohe pärast Flyway andmebaasi migratsiooni, mida saab samuti teostada käsitsi või automaatselt.

Allikakoodi genereerimine

Tugipool, kuidas koodi genereerimist – käsitsi ja automaatsete meetoditega – seostatakse erinevate filosoofiate, eeliste ja puudustega, mida ma ei kavatse selles artiklis üksikasjalikult arutada. Kuid üldiselt on genereeritud koodi tuum selles, et see võimaldab Java-s tõlgendada seda „tõde”, mida me võtame iseenesestmõistetavaks, kas meie süsteemi raames või väljaspool seda. Teatud mõttes teevad sama ka kompilaatorid, genereerides baitkoodi, masinkoodi või mõne muu koodi vormi lähtedokumentide põhjal – saame meie „tõe” esituse teises keeles, sõltumata konkreetsest põhjusest.

On palju selliseid koodigeneraatoreid. Näiteks, XJC saab genereerida Java koodi XSD või WSDL failide põhjal.Põhimõte on alati sama:

• On mingi tõde (sisemine või väline) – näiteks spetsifikatsioon, andmemudel jne.
• Me vajame kohaliku esitluse loomist selles tõdes meie programmeerimiskeeles.

Pealegi on sellise esitluse genereerimine peaaegu alati mõistlik – et vältida liigset kordust.

Tüüpide pakkujad ja annotatsioonide töötlemine

Märkus: veel üks, kaasaegsem ja spetsiifilisem lähenemine koodi genereerimiseks jOOQ jaoks, on seotud tüüpide pakkujate kasutamisega, nagu need on rakendatud F#-is.Sel juhul genereerib koodi kompilaator, tegelikult kompileerimise etapis. Sellise koodi lähtefailid ei eksisteeri põhimõtteliselt. Java-s on sarnaseid, kuigi mitte nii elegantseid tööriistu – need on annotatsiooniprotsessorid, näiteks, Lombok..

Teatud mõttes toimub siin sama, mis esimesel juhul, välja arvatud:

• Te ei näe genereeritud koodi (võib-olla tundub see kellelegi vähem hirmutav?)
• Te peate tagama, et tüübid oleksid kergesti kättesaadavad, see tähendab, et „tõde” peab alati olema kätte saadav. See on lihtne Lomboki puhul, mis annotatsiooniga „tõde” tähistab. Veidi keerulisem on andmemudelitega, mille töö sõltub pidevalt kättesaadavast elavast ühendusest.

Mis on probleem koodi genereerimisel?

Lisaks keerulisele küsimusele selle kohta, kuidas koodi genereerimist kõige paremini alustada - käsitsi või automaatselt, tuleb mainida ka, et on inimesi, kes arvavad, et koodi genereerimine pole üldse vajalik. Selle seisukoha põhjenduseks tuuakse kõige sagedamini välja, et siis on keeruline seadistada kogumisüsteemi. Jah, see on tõepoolest keeruline. Tekkivad lisainfrastruktuuri kulud. Kui alustate teatud tootega (olgu see jOOQ, JAXB või Hibernate jne), siis kulub arenduskeskkonna seadistamisele aega, mida tahaksite pigem kasutada API tutvumiseks, et hiljem sellest väärtust välja tuua.

Kui kulu, mis on seotud generaatori ülesehitusega, on liiga suur, siis tõepoolest on API-s koodi generaatori kasutatavus halvasti tehtud (ja hiljem selgub, et ka kasutaja seadistamine on keeruline). Kasutamise mugavus peaks olema iga sellise API kõrgeim prioriteet. Kuid see on vaid üks argument koodi genereerimise vastu. Muus osas on täiesti mõistlik kirjutada kohalik esitus sisemisest või välsest tõest käsitsi.

Paljud ütlevad, et neil pole aega sellega tegeleda. Neil on tähtajad oma Super-Toote osas. Kord hiljem tegeleme kogumisüsteemidega, jõuab küll. Ma vastan neile:

Originaal, Alan O’Rourk, Audience Stack

Kuid Hibernate / JPA-s on nii lihtne kirjutada koodi "Java" jaoks.

Tõepoolest. Hibernate'i ja selle kasutajate jaoks on see samal ajal õnn ja needus. Hibernate'i puhul saab lihtsalt kirjutada paar üksust, näiteks nii:

	@Entity
class Book {
  @Id
  int id;
  String title;
}

Ja peaaegu kõik on valmis. Nüüd on Hibernate'i ülesanne genereerida keerulised "detailid", kuidas see üksus täpselt määratakse teie SQL "dialekti" DDL-s:

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

... ja hakkame rakendust käivitama. Tõeliselt suurepärane võimalus, et kiiresti tööle asuda ja erinevaid asju katsetada.

Kuid lubage, et ma eksisin.

• Kas Hibernate tõeliselt rakendab selle nimetatud primaarvõtme määratlemist?
• Kas Hibernate loob indeksi TITLE-s? - ma tean kindlalt, et me vajame seda.
• Ja kas Hibernate teeb selle võtmest identifitseeriva Identity Specificationi?

Ilmselt mitte. Kui arendate oma projekti nullist, on alati mugav lihtsalt vana andmebaas kõrvaldada ja luua uus, kui olete vajalikud annotatsioonid lisanud. Nii näeb lõpuks välja olend Book:

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

Väga hea. Genereeri uuesti. Taaskord, sel juhul on alguses väga lihtne.

Aga hiljem tuleb selle eest tasuda.

Varem või hiljem peate minema tootmisse. Just siis lakkab see mudel töötamast. Sest:

Tootmises ei saa te enam vajadusel vana andmebaasi kõrvaldada ja kõike puhtalt lehelt alustada. Teie andmebaas muutub pärandiks.

Edaspidi peate kirjutama DDL migratsiooniskripte, näiteks Flyway abil.. Aga mis siis juhtub teie olenditega? Saate kas kohandada neid käsitsi (ja suurendada oma töömahtu kahekordseks) või küsida Hibernate'ilt, et ta genereeriks need uuesti teie jaoks (kui suured on võimalused, et sellisel viisil genereeritud vastab teie ootustele?) Igatahes jääte kaotajaks.

Nii et niipea, kui lähete tootmisse, vajate kiireid patše. Ja neid tuleb tootmisse viia väga kiiresti. Kuna te pole valmistunud ega organiseerinud sujuvat tootmisprotsessi oma migratsioonide jaoks, peate kõik tormiliselt patšeerima. Ja siis ei jõua te kõike õigesti teha. Ja süüdistate Hibernate'i, kuna alati on süüdi keegi muu, mitte teie...

Selle asemel oleks algusest peale saanud teha kõik hoopis teisiti. Näiteks panna jalgrattale ümmargused rattad.

Esialgu andmebaas.

Tõeline „tõde” teie andmebaasi skeemis ja „suveräänsus” selle üle peitub andmebaasis endas. Skeem määratletakse ainult andmebaasis ja mitte kusagil mujal, ja igal kliendil on sellele skeemile oma koopia, seega on täiesti mõistlik nõuda skeemi ja selle terviklikkuse järgimist otse andmebaasis – seal, kus teave salvestatakse.
See on vana ja isegi kulunud tarkus. Esialgsed ja unikaalsed võtmed – need on head. Välistingimustes võtmed – head. Piirangute kontroll – hea. Kinnitus – on hea.

Kuid see pole veel kõik. Näiteks kasutades Oracle'i, soovite tõenäoliselt näidata:

• Millises tabeliruumi teie tabel asub
• Milline on selle PCTFREE väärtus
• Kui suur on teie järjestuse vahemälu (ID taga)

Võib-olla pole see kõik väikestes süsteemides oluline, kuid ei pea ootama „suurte andmete” valdkonda sisenemist — võib hakata varakult kasutama andmete salvestamise pakkuja poolt pakutud optimeerimist, nagu ülal mainitud. Ükski ORM, mida olen näinud (sealhulgas jOOQ), ei paku juurdepääsu kogu DDL valikute komplektile, mida võiksite oma andmebaasis kasutada. ORM-id pakuvad mõningaid tööriistu, mis aitavad DDL-i kirjutada.

Aga lõpuks, hästi kavandatud skeem on käsitsi kirjutatud DDL. Iga genereeritud DDL on lihtsalt selle lähedane jäljend.

Kuidas on kliendimudeliga?

Nagu eelnevalt mainitud, vajate kliendil oma andmebaasi skeemi koopia, kliendi vaade. Üksikasjad on kindlasti paar korda mainitud, see kliendi vaade peab olema sünkroonitud tegeliku mudeliga. Kuidas seda kõige paremini saavutada? Koodi generaatori abil.

Kõik andmebaasid pakuvad oma metaandmeid SQL-i kaudu. Siin on, kuidas oma andmebaasist kõiki tabeleid erinevates SQL-i dialektides saada:

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables

-- DB2
SELECT tabschema, tabname
FROM syscat.tables

-- Oracle
SELECT owner, table_name
FROM all_tables

-- SQLite
SELECT name
FROM sqlite_master

-- Teradata
SELECT databasename, tablename
FROM dbc.tables

Need päringud (või sarnased, sõltuvalt sellest, kas tuleb arvesse võtta ka vaateid, materialiseeritud vaateid, tabeli väärtusi funktsioone) täidetakse samuti kutsumisega DatabaseMetaData.getTables() JDBC-st või meta-mooduli jOOQ abil.

Selliste päringute tulemustest on suhteliselt lihtne genereerida mis tahes kliendi vaade teie andmebaasi mudelile, sõltumata sellest, millist tehnoloogiat kasutate.

• Kui kasutate JDBC-d või Springi, siis saate luua stringide konstantide kogumi
• Kui kasutate JPA-d, siis võite generiseerida ise ühikut
• Kui kasutate jOOQ-i, siis saate genereerida jOOQ-i meta-mudeli

Sõltuvalt sellest, kui palju võimalusi teie kliendi API pakub (nt jOOQ või JPA), võib genereeritud meta-mudel olla tõeliselt rikka ja täielik. Võtame näiteks vaikimisi liitmise võimaluse, mis ilmus jOOQ versioonis 3.11, mis tugineb genereeritud metaandmetele väliste võtmete suhete kohta, mis kehtivad teie tabelite vahel.

Nüüd toob iga andmebaasi suurenemine automaatselt kaasa kliendikoodi uuendamise. Kujutage ette, näiteks:

ALTER TABLE book RENAME COLUMN title TO book_title;

Kas tõesti soovite seda tööd kaks korda teha? Absoluutselt mitte. Lihtsalt salvestame DDL, töötleme seda teie ehitusprotsessis ja saame uuendatud entiteedi:

@Entity
@Table(name = "book", indexes = {
 
  // Kas olete sellele mõelnud?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

Või uuendatud jOOQ klass. Enamik DDL muudatusi kajastuvad ka semantikas, mitte ainult süntaksis. Seetõttu võib olla mugav vaadata kompileeritud koodis, milline kood saab (või võib) teie andmebaasi suurenemise tõttu mõjutatud.

Ainult üks tõde

Ükskõik, millist tehnoloogiat kasutate, on alati olemas üks mudel, mis on mingi alamsüsteemi ainus tõeallikas - või vähemalt peaksime seda püüdma teha ja vältima sellist ettevõtte segadust, kus "tõde" on korraga igal pool ja mitte kuskil. Kõik võiks olla palju lihtsam. Kui vahetate lihtsalt XML-faile mõne muu süsteemiga, siis kasutage lihtsalt XSD-d. Vaadake jOOQ meta-mudelit INFORMATION_SCHEMA XML-vormis:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD on hästi arusaadav
• XSD märgib XML-i sisu väga hästi ja võimaldab valideerimist kõigis kliendikeeltes
• XSD-l on hea versioonihaldus ja arenenud tagasiühilduvus
• XSD-d saab Java koodiks tõlkida kasutades XJC-d

Viimane punkt on oluline. Suheldes välist süsteemiga XML-sõnumite kaudu, tahame olla kindlad sõnumite kehtivuses. Seda on väga lihtne saavutada JAXB, XJC ja XSD abil. Oleks täielik hullumeelsus loota, et „Java-esimene“ lähenamine, kus loome oma sõnumid Java objektide kujul, saaks mingil viisil mõistetavalt XML-iks muuta ja edastada teise süsteemi tarbimiseks. Sellega genereeritud XML oleks väga halva kvaliteediga, dokumenteerimata ning seda oleks keeruline arendada. Kui sellise liidese puhul oleks kvaliteedi teenuse taseme (SLA) leping, oleksime selle kohe rikkunud.

Ausalt öeldes juhtub see pidevalt JSON API-dega, kuid see on juba teine lugu, järgmine kord räägin veel...

Andmebaasid: see on sama asi

Andmebaasidega töötades mõistate, et need kõik on põhimõtteliselt sarnased. Andmebaas haldab oma andmeid ja peab juhtima skeemi. Skeemi muudatused tuleb viia ellu otse DDL-is, et uuendada ühte tõe allikat.

Kui allika uuendamine on toimunud, peavad kõik kliendid samuti oma mudelid uuendama. Mõned kliendid võivad olla kirjutatud Java keeles, kasutades jOOQ-d ja Hibernate'i või JDBC-d (või kõiki neid korraga). Teised kliendid võivad olla kirjutatud Perl'is (soovime neile just head õnne), kolmandad - C#-s. See ei ole oluline. Peamine mudel asub andmebaasis. ORM-i abil genereeritud mudelid on tavaliselt halvasti kvaliteetsed, halvasti dokumenteeritud ja neid on raske arendada.

Seetõttu ärge tehke vigu. Alustage õigesti. Töödelge andmebaasist lähtuvalt. Looge selline juurutusprotsess, mida saab automatiseerida. Lisage koodigeneraatorid, et mugavalt kopeerida oma andmebaasi mudelit ja edastada seda klientidele. Ja lõpetage koodigeneraatorite muretsemine. Need on head. Nende abil saate produktiivsemaks. Peate vaid alguses natuke aega nende seadistamiseks kulutama – ja siis ootavad teid aastaid suurenenud tootlikkust, millest kujuneb teie projekti lugu.

Ärge tänage veel, hiljem.

Selgitus

Selguse huvides: see artikkel ei propageeri mingil moel, et teie andmebaasi mudel peaks kogu süsteemi painutama (st, teemaala, äri loogika jne). Selles artiklis räägin ma sellest, et kliendi kood, mis suhtleb andmebaasiga, peaks toimima andmebaasi mudelilt lähtuvalt, et mitte kopeerida andmebaasi mudelit "esimese klassi" staatusesse. Selline loogika asub tavaliselt teabe juurdepääsu tasemel teie kliendis.

Kaksitasandilistes arhitektuurides, mis on siiani mõnes kohas säilinud, võib selline süsteemi mudel olla ainus võimalus. Siiski, enamikus süsteemides tundub andmete juurdepääsu tase olevat „alamsüsteem”, mis kapseldab endas andmebaasi mudelit.

Erandid

Igal reeglil on erandeid ja olen juba öelnud, et andmebaasi esmajärjekorras ja lähtekoodi genereerimise lähenemine võib mõnikord olla sobimatu. Siin on paar sellist erandit (ilmselt on ka teisi):

• Kui skeem ei ole teada ja seda tuleb avada. Näiteks, kui olete tööriista pakkuja, mis aitab kasutajatel navigeerida mistahes skeemis. Uff. Siin ei saa küll ilma koodi genereerimiseta hakkama. Kuid siiski - andmebaas tuleb kõigepealt.
• Kui skeem peab jooksvalt genereerima mingi ülesande lahendamiseks. See näide tundub olevat natuke keeruline versioon mustrist entity attribute value, st teil ei ole tõeliselt määratletud skeemi. Sel juhul ei saa tihti isegi kindel olla, et teile sobib RDBMS.

Erandid on olemuselt erandlikud. Enamiku RDBMS-iga seotud juhtumite puhul on skeem ette teada, see asub RDBMS-is ja on ainus "tõde"; kõik kliendid peavad selle põhjal endale omandama koopiad, mis saadud sellest. Ideaalis tuleks kasutada koodigeneraatorit.

Allikas: habr.com