4D-arkkitehtuurin suunnittelu: täydellinen opas

4D-arkkitehtuurisuunnittelu on prosessi, jossa rakennetaan 4D-tietokanta (sen taulukot, kentät, suhteet, indeksit ja käyttöoikeustasot) niin, että sovellus pysyy nopeana, ylläpidettävänä ja turvallisena sen kasvaessa. Hyvin suunniteltuun 4D-skeemaan kuuluu tyypillisesti viisi keskeistä päätöstä: taulukoiden rakeisuus, suhdestrategia, ensisijaisen avaimen tyyppi, indeksin sijainti ja tiedon erottaminen käyttöliittymälogiikasta. Kun tämä tehdään oikein alusta alkaen, voit välttää kalliit migraatiot tulevaisuudessa.

Keskeiset opit

• 4D-arkkitehtuurin suunnittelussa erotetaan kolme osa-aluetta: tietomalli (taulukot, kentät, relaatiot), liiketoimintalogiikkakerros (metodit, luokat, triggerit) ja esityskerros (lomakkeet, luetteloruudut, dialogit).
• Relaatiotyypillä on enemmän merkitystä kuin taulukoiden määrällä: monesta-moneen-linkki tarvitsee liitostaulukon, kun taas yksi-moneen-linkki käyttää viiteavainkenttää ja relaatiota.
• Indeksit nopeuttavat lukemista, mutta hidastavat kirjoittamista — indeksoi viiteavaimet ja kaikki kyselyn WHERE-lauseessa käytetyt kentät, ei jokaista kenttää.
• 4D:n ORDA (Object Relational Data Access) -kerros muuttaa ajatteluasi skeemasta: hyvin nimetyistä taulukoista ja kentistä tulee luettavia tietoluokkien ja attribuuttien nimiä koodissa.
• Asiakas-palvelin- vs. yhden käyttäjän käyttöönotto on arkkitehtoninen päätös, ei jälkikäteen tehtävä käyttöönottoasia — se vaikuttaa lukitukseen, välimuistiin ja siihen, miten kirjoitat kyselyitä.
• Johdonmukaisesti ensimmäisestä päivästä lähtien sovelletut nimeämiskäytännöt säästävät enemmän refaktorointiaikaa kuin mikään muu yksittäinen tapa.

Mitä “4D-arkkitehtuuri” tarkoittaa tietokantakontekstissa

4D-arkkitehtuurin suunnittelulla tarkoitetaan 4D-alustalle (4th Dimension) rakennetun sovelluksen rakennesuunnittelua. 4D on relaatiotietokanta ja low-code-kehitysympäristö, jonka Laurent Ribardièren tiimi julkaisi alun perin vuonna 1984 ja jota nykyään ylläpitää 4D SAS. Toisin kuin puhdas SQL-tietokanta, 4D yhdistää tietomoottorin, ohjelmointikielen, lomakesuunnittelijan ja web/REST-palvelimen yhdeksi tuotteeksi – joten “arkkitehtuuri” kattaa tässä sekä skeeman että sen päällä olevat sovelluskerrokset.

Termi sekoitetaan joskus arkkitehtoniseen visualisointiin (4D BIM, aika neljäntenä ulottuvuutena rakennussuunnittelussa). Tämä opas käsittelee ohjelmiston merkitystä: kuinka 4D-tietokanta ja sen sovelluskerrokset rakennetaan. Jos etsit tietoa rakennussuunnittelusta, alla olevat käsitteet eivät päde.

4D-sovelluksen kolme kerrosta

4D-arkkitehtuurin suunnitteluprojektit hyötyvät selkeästä kerrosmallista. Vastuun jakaminen estää kasvavaa sovellusta muuttumasta lomakeskriptien sotkuksi.

Kerros 1 — Tietomalli

Tietomalli on joukko taulukoita, kenttiä, relaatioita ja indeksejä, jotka on tallennettu 4D-rakennetiedostoon. Tämä kerros ei saa sisältää käyttöliittymäkoodia eikä liiketoimintasääntöjä, jotka voisivat sijaita muualla. Kenttätyypit (teksti, kokonaisluku, reaaliluku, päivämäärä, aika, Boolean, blob, objekti, kuva) ja kenttien pituudet määritetään tässä, ja niiden muuttaminen myöhemmin live-tietokannassa vaatii huolellisuutta.

Kerros 2 — Liiketoimintalogiikka

Liiketoimintalogiikka sijaitsee projektimetodeissa, luokissa ja taulukon triggereissä. Nykyaikaisessa 4D:ssä luokat (jotka esiteltiin versiossa 4D v18 R3 ja laajennettiin sen jälkeen) mahdollistavat uudelleenkäytettävän ja testattavan koodin kirjoittamisen sen sijaan, että logiikka hajautettaisiin lomakemetodeihin. Taulukon triggeri käynnistyy luomisen, tallennuksen ja poistamisen yhteydessä – tämä on hyödyllistä auditointijäljille, mutta käyttöliittymää kutsuva triggeri rikkoutuu headless-palvelinkonteksteissa.

Aiheeseen liittyvä: Claris FileMaker Pro — Pitkäaikainen relaatiotietokanta-alusta tiimeille, jotka tarvitsevat mukautettuja sovelluksia työpöydälle, verkkoon ja mobiililaitteille yhdestä tiedostosta..

Kerros 3 — Esitys

Esitys kattaa lomakkeet, luetteloruudut, syöttödialogit ja kaikki web- tai REST-tulosteet. 4D-lomakkeet sitoutuvat suoraan kenttiin ja muuttujiin, mikä on kätevää, mutta rohkaisee sijoittamaan logiikkaa lomakkeeseen. Lomakemetodien pitäminen ohuina – kutsumalla luokkametodia ja näyttämällä tulos – on suurin yksittäinen ylläpidettävyysvoitto useimmissa 4D-projekteissa.

Tietomallin suunnittelu: taulukot, relaatiot ja avaimet

Tietomallinnuspäätökset 4D-arkkitehtuurin suunnittelussa noudattavat relaatioperiaatteita, joihin on lisätty 4D-spesifit mekaniikat.

Taulukoiden rakeisuuden valitseminen

Taulukon tulisi edustaa yhtä entiteettityyppiä. “Asiakas”-taulukon jakaminen “asiakas”- ja “asiakas_osoite”-taulukoihin on järkevää, kun asiakkaalla voi olla useita osoitteita; niiden yhdistäminen on järkevää, kun asiakasta kohden on täsmälleen yksi osoite eikä uudelleenkäyttöä. Liiallinen normalisointi moniksi pieniksi taulukoiksi lisää relaatioiden ja liitosten määrää, mikä heikentää suorituskykyä luettelonäkymissä.

Meidän valintamme: Airtable — Yksinkertainen laskentataulukkokäyttöliittymä, joka sijaitsee todellisen relaatiotietokannan päällä, jossa on automaatioita, näkymiä ja jaettavia käyttöliittymiä..

Relaatiotyypit

4D tukee rakenneeditorissa määriteltyjä automaattisia relaatioita ja koodissa luotuja manuaalisia relaatioita. Yleiset mallit:

Relaatio	4D-toteutus	Tyypillinen käyttö
Yksi-moneen	Viiteavainkenttä “monen” puolella plus relaatio	Lasku $\rightarrow$ Laskun rivit
Monesta-moneen	Liitostaulukko kahdella viiteavaimella	Tuotteet $\leftrightarrow$ Toimittajat
Yksi-yhteen	Jaettu ensisijainen avain tai yksilöllinen viiteavain	Käyttäjä $\rightarrow$ Käyttäjäprofiili
Itseviittaava	Viiteavain, joka osoittaa takaisin samaan taulukkoon	Työntekijä $\rightarrow$ Esimies

Ensisijaisen avaimen strategia

4D tarjoaa automaattisesti kasvavat longint-ensisijaiset avaimet ja UUID (teksti) -ensisijaiset avaimet. Longint-avaimet ovat kompakteja ja nopeasti indeksoitavia; UUID:t ovat maailmanlaajuisesti ainutlaatuisia, mikä on tärkeää yhdistettäessä tietoja useista sivustoista tai synkronoidessa ulkoisten järjestelmien kanssa. Yleinen kompromissi on longint-sisäinen avain sekä erillinen yksilöllinen “ulkoinen viite” -tekstikenttä.

Indeksointi ja kyselyiden suorituskyky

Indeksit ovat tehokkain suorituskyvyn säätökeino 4D-arkkitehtuurin suunnittelussa, mutta niitä on myös helpoin käyttää liikaa.

Mitä indeksoida

Indeksoi jokainen relaation viiteavaimena käytetty kenttä, jokainen kyselyn hakuehdoissa usein käytetty kenttä ja jokainen suurten luetteloruutujen lajitteluun käytetty kenttä. 4D tukee tavallisia B-puu-indeksejä, avainsanaindeksejä sanapohjaiseen tekstihakuun ja yhdistelmäindeksejä, jotka kattavat useita kenttiä.

Mitä ei indeksoida

Jokainen indeksi lisää kirjoituskustannuksia ja tallennustilaa. Boolean-kentän indeksointi, jossa on vain kaksi mahdollista arvoa, auttaa harvoin. Kentän indeksointi, jota luetaan vain osana koko tietueen näyttöä, lisää yleiskustannuksia ilman hyötyä. Tarkista indeksit sen jälkeen, kun sovelluksella on todellisia käyttötapoja, sen sijaan että arvailet etukäteen.

Kyselystrategia

ORDA-kyselyt (ds.Invoice.query("Status = :1"; "Open")) ovat yleensä parempia kuin klassiset QUERY-komennot uudessa koodissa, koska ne palauttavat entiteettivalintoja, jotka voidaan lajitella, suodattaa ja siirtää metodien välillä ilman uudelleenkyselyä. Erittäin suurissa taulukoissa kyselyn rajoittaminen indeksoiduilla ehdoilla ennen indeksoimattomien suodattimien käyttöä pitää vastausajat ennustettavina.

Aiheeseen liittyvä: Microsoft Power Apps — Yritystason alhaisen koodin sovelluskehitys yhdistettynä Microsoft 365:een, Dataverseen ja Power Automateen..

ORDA ja moderni 4D-arkkitehtuuri

ORDA (Object Relational Data Access) on 4D:n oliopohjainen tiedonkäyttökerros, joka esiteltiin versiossa 4D v17. Se esittää taulukot tietoluokkina (dataclasses) ja tietueet entiteetteinä, joten taulukosta nimeltä Invoice tulee ds.Invoice ja kentästä nimeltä TotalNet tulee $invoice.TotalNet.

Tällä on arkkitehtoninen seuraus 4D-arkkitehtuurin suunnittelulle: taulukoiden ja kenttien nimet ovat nyt osa julkista APIasi. Kentän uudelleennimeäminen rikkoo koodin tavalla, joka on nähtävissä käännösvaiheessa, mutta epäjohdonmukainen nimeäminen tekee ORDA-koodista vaikeasti luettavaa. Käytännön omaksuminen – yksikön muotoiset taulukoiden nimet, PascalCase-kentät, ei lyhenteitä – kannattaa välittömästi.

ORDA tukee myös asiakaspuolen entiteettivalintoja, jotka ladataan vain osittain, mikä muuttaa luettelonäyttöjen suorituskykyprofiilia. Entiteettivalintaan sidottu luetteloruutu voi näyttää tuhansia rivejä lataamatta jokaista tietuetta, olettaen että sen takana oleva kysely on indeksoitu.

Lukijan suosikki: Knack — Kooditon tietokannan rakentaja, joka on tarkoitettu portaaleihin, hakemistoihin ja sisäisiin työkaluihin – kiinteähintaisella hinnoittelulla käyttäjäkohtaisten maksujen sijaan..

Asiakas-palvelin-, yhden käyttäjän ja web-käyttöönotto

Käyttöönoton topologia muokkaa 4D-arkkitehtuurin suunnittelua enemmän kuin monet kehittäjät odottavat.

Yhden käyttäjän sovellukset ajavat tietomoottorin ja käyttöliittymän yhdessä prosessissa. Lukitus on triviaalia; suorituskyvyn optimointi liittyy pääasiassa paikallisen levyn nopeuteen.

Asiakas-palvelin-malli jakaa 4D-palvelimen (tietomoottori) ja 4D-asiakkaan (käyttöliittymä). Tietueet lukitaan palvelimella, ja kunkin kyselyn verkon edestakainen viive muuttuu merkittäväksi. Arkkitehtuurit, jotka tekevät monta pientä kyselyä per näyttö, toimivat tässä huonosti; kyselyiden eräjako ja entiteettivalintojen käyttö vähentävät edestakaisia viestejä.

Web- ja REST-käyttöönotto paljastaa saman tietomallin 4D:n REST-palvelimen tai koottujen web-metodien kautta. Tietoturva nousee etualalle: taulukoiden ja kenttien pääsyä on rajoitettava rooleilla ja oikeuksilla, ja mikä tahansa liiketoimintasääntö, joka on toteutettu vain lomakemetodissa, on käytännössä voimaton web-asiakkaille.

Nimeämiskäytännöt ja dokumentaatio

Johdonmukainen nimeäminen ei ole hienoa, mutta se on ratkaisevaa 4D-arkkitehtuurin suunnittelussa. Toimiva käytäntö 4D:lle:

• Taulukot: Yksikkösubstantiivit, PascalCase (“Customer”, “InvoiceLine”).
• Kentät: PascalCase, ilman tyyppiprefiksejä (“InvoiceDate”, ei “dInvDate”).
• Relaatiot: nimetty kohdetaulukon mukaan (“Customer_Invoices”).
• Metodit: verbi ensin (“CreateInvoice”, “RecalculateTotals”).
• Luokat: Substantiivi ensin (“InvoiceService”, “TaxCalculator”).

Skeeman dokumentointi – vaikka vain yhtenä Markdown-tiedostona, jossa luetellaan jokainen taulukko, sen tarkoitus ja keskeiset relaatiot – helpottaa perehdytystä ja tulevia migraatioita huomattavasti. 4D:n rakenneeditori näyttää relaatiot graafisesti, mutta se ei selitä, miksi taulukko on olemassa.

Yleisiä 4D-arkkitehtuurin suunnitteluvirheitä

Liiketoimintalogiikan sijoittaminen lomakemetodeihin. Lomakemetodeja ei voida kutsua web-konteksteista tai ajoitetuista tehtävistä, joten sinne loukkuun jäänyt logiikka on monistettava.

Valintaan perustuvien klassisten komentojen käyttö uudessa koodissa. Klassiset valinnat ovat prosessisidonnaisia eivätkä ne siirry hyvin prosessien välillä; ORDA-entiteettivalinnat ovat joustavampia.

Liitostaulukon ohittaminen. Useiden arvojen tallentaminen yhteen tekstikenttään (pilkuilla erotetut tunnukset) tuhoaa indeksoinnin ja tekee raportoinnista tuskallista.

Kaiken indeksointi. Kirjoitussuorituskyky heikkenee, ja hyötyä saadaan harvoin.

Oikeuksien huomiotta jättäminen käyttöönottoon asti. Tietoturvamallin jälkiasennus valmiiseen sovellukseen on huomattavasti vaikeampaa kuin sen suunnittelu skeeman rinnalla.

Kuinka päättää: Käytännön tarkistuslista

Ennen 4D-arkkitehtuurin suunnittelua, käy läpi nämä kysymykset:

1. Kuinka monta samanaikaista käyttäjää on, ja yhdistävätkö he LAN-, WAN- vai web-yhteydellä?
2. Millä entiteeteillä on luonnollinen yksi-moneen-suhde ja mitkä tarvitsevat liitostaulukoita?
3. Mitkä kentät esiintyvät hakuehdoissa tai lajittelujärjestyksissä suurissa taulukoissa?
4. Mitkä liiketoimintasäännöt on noudatettava riippumatta tulopisteestä (lomake, web, tuonti)?
5. Yhdistetäänkö tietoja koskaan toiseen järjestelmään, mikä vaatisi UUID-avaimia?
6. Kuka ylläpitää tätä kahden vuoden kuluttua, ja onko nimeäminen heille loogista?

Vastaukset näihin kuuteen kysymykseen määräävät suurimman osan 4D-projektin rakenteellisista päätöksistä.

Lisälukemista

Virallinen 4D-dokumentaatio osoitteessa developer.4d.com kattaa ORDA:n, luokat, oikeudet ja käyttöönoton yksityiskohtaisesti. Relaatiomallinnuksen perusteista, jotka pätevät alustasta riippumatta, luke lisää Wikipedian artikkelista tietokannan normalisoinnista.

Laajempaa kontekstia low-code- ja nopean sovelluskehitysalustan (RAD) osalta löytyy Wikipedian artikkelista low-code development platforms. 4D SAS julkaisee myös julkaisutiedotteita ja migraatio-oppaita, joissa kuvataan, milloin ORDA, luokat ja muut 4D-arkkitehtuurin suunnitteluominaisuudet esiteltiin.

Usein kysyttyjä kysymyksiä

Mitä on 4D-arkkitehtuurin suunnittelu?

4D-arkkitehtuurin suunnittelu on prosessi, jossa suunnitellaan 4D (4th Dimension) -sovelluksen rakenne: sen taulukot, kentät, relaatiot, indeksit, liiketoimintalogiikkakerros ja esityskerros. Se määrittää, miten sovellus toimii, kuinka helposti sitä voidaan muuttaa ja kuinka turvallisesti se voidaan ottaa käyttöön työpöytä-, asiakas-palvelin- tai web-asiakkaille.

Onko 4D-arkkitehtuuri sama kuin 4D BIM?

Ei. 4D BIM lisää ajan neljänneksi ulottuvuudeksi rakennustietomallinnukseen rakentamisen aikataulutusta varten. 4D-arkkitehtuuri ohjelmiston merkityksessä tarkoittaa sovellusten suunnittelua 4D-tietokanta-alustalla. Näillä kahdella alalla on sama lyhenne, mutta ei mitään muuta yhteistä.

Pitäisikö minun käyttää ORDAa vai klassisia 4D-komentoja?

ORDA on paras vaihtoehto uudelle kehitykselle. Se palauttaa entiteettivalintoja, jotka voidaan siirtää metodien välillä, lajitella ja suodattaa ilman tarvetta tehdä uutta kyselyä, ja se esittää taulukot ja kentät luettavien objektien ominaisuuksina. Klassiset valintapohjaiset komennot ovat edelleen hyödyllisiä legacy-koodissa ja joissakin erikoistapauksissa.

Kuinka monta indeksiä 4D-taulukossa pitäisi olla?

Kiinteää lukumäärää ei ole. Indeksoi viiteavaimet, yleisissä hakuehdoissa käytetyt kentät ja kentät, joita käytetään suurten luetteloiden lajitteluun. Vältä kenttien indeksointia, joilla on alhainen kardinaalisuus, kuten boolean-arvot tai tilakentät, joissa on vain kaksi tai kolme arvoa, sillä kirjoituskustannukset ylittävät yleensä lukuhyödyn.

Mikä ensisijaisen avaimen tyyppi minun pitäisi valita 4D:ssä?

Automaattisesti kasvavat longint-avaimet ovat kompakteja ja nopeita, ja ne sopivat yksittäisiin sivustoihin. UUID-tekstiavaimet ovat suurempia, mutta maailmanlaajuisesti ainutlaatuisia, mikä on tärkeää yhdistettäessä tietoja useista sivustoista tai integroidessa ulkoisiin järjestelmiin. Monet projektit käyttävät longint-avainta sisäisesti ja erillistä yksilöllistä ulkoista viitekenttää.

Voinko muuttaa 4D-tietomallia käyttöönoton jälkeen?

Kyllä, mutta huolella. Taulukoiden, kenttien ja indeksien lisääminen on yleensä yksinkertaista. Kenttätyyppien muuttaminen, ORDA-koodin käyttämien kenttien uudelleennimeäminen tai käytössä olevan tietokannan suhteiden uudelleenjärjestely edellyttää suunniteltua migraatiota, joka mieluiten testataan ensin tuotantotietojen kopiolla.