Siirry pääsisältöön
HPO Software Askel askeleelta etenevät oppaat 4D-tietokantojen ja low-code-sovellusten rakentamiseen – ensimmäisestä taulukosta valmiiksi liiketoimintasovellukseksi.

Osa tämän sivuston linkeistä on kumppanuuslinkkejä: ostamalla niiden kautta voimme ansaita komission ilman lisäkustannuksia sinulle. Tämä ei vaikuta suosituksiimme. Lue lisää kumppanuusilmoituksestamme. Kumppanuusilmoitus.

Parhaat tietokantataulukkosuunnittelutyökalut verrattuna (2026)

Tietokantataulukoiden suunnittelutyökalu on ohjelmisto, jolla määritetään taulukoita, kenttiä, tietotyyppejä, suhteita, indeksejä ja rajoituksia visuaalisesti tai koodissa ennen lomakkeiden ja liiketoimintalogiikan rakentamista. Vaihtoehdot kattavat vähintään neljä luokkaa: pelkät kaaviomallintajat, skeema-ensimmäiset SQL-editorit, integroidut low-code-alustat ja migraatiokehykset. Oikea valinta riippuu siitä, onko skeemasi totuuden lähde vai kaavio, joka ajautuu epätahdiksi.

  • Tietokantataulukoiden suunnittelutyökalut on jaettu neljään kätevään luokkaan: pelkät kaaviomallintajat (draw.io, Lucidchart), skeemakeskeiset SQL-editorit (DBeaver, DataGrip, pgAdmin), integroidut low-code-alustat (4D, with Dataverse, FileMaker) ja migraatiokehykset (Flyway, Liquibase, Prisma Migrate).
  • Tärkein yksittäinen päätös on se, missä skeema sijaitsee: visuaalisessa mallissa, versioiduissa SQL-tiedostoissa vai alustan omassa luettelossa. Työkalut, jotka säilyttävät kaksi kopiota totuudesta, luovat epäjohdonmukaisuutta (drift).
  • Pienille tiimeille suunnatuissa yrityssovelluksissa integroitu alusta, jossa taulukot, lomakkeet, arvolistat ja logiikka ovat yhdessä paikassa, poistaa kokonaisen luokan integraatiovirheitä.
  • Pelkät kaaviotyökalut ovat erinomaisia viestinnässä ja kauheita rakennusartefakteina: ne eivät pakota tyyppejä, avaimia tai viittauksen eheyttä.
  • Normalisointi kolmanteen normaalimuotoon (3NF) on edelleen oletuskohteena transaktioskeemoissa; tietoinen denormalisointi on suorituskykyyn liittyvä päätös, ei suunnittelun oikopolku.
  • Riippumatta siitä, minkä työkalun valitset, skeeman tulee olla vietävissä tekstinä, jotta sitä voidaan tarkastella, vertailla (diff) ja hallita versionhallinnalla.

Mitä tietokantataulukoiden suunnittelutyökalu todella tekee

Taulukoiden suunnittelutyökalut hoitavat yllättävän laajan valikoiman tehtäviä, ja toimittajat sumentavat luokkarajoja tarkoituksella. Taustalla olevien ominaisuuksien ymmärtäminen on nopein tapa verrata niitä rehellisesti.

Entiteettien ja attribuuttien määrittäminen. Tietokantataulukoiden suunnittelutyökalu antaa vähintään mahdollisuuden nimetä taulukoita, lisätä kenttiä ja määrittää tietotyyppejä. Laatuero näkyy siinä, miten se käsittelee tyyppejä, joista tietokannat ovat eri mieltä: päivämäärät aikavyöhykkeillä ja ilman, kiinteän tarkkuuden desimaalit, UUID:t, JSON-sarakkeet ja taulukot.

Suhdemallinnus. Yksi-moneen, monta-montaan liitostaulukon kautta ja yksi-yhteen -suhteiden on oltava visuaalisesti ilmaistavissa ja pakotettavissa luodussa skeemassa. Työkalu, joka piirtää “crow’s-foot”-viivan mutta ei luo vierasavainrajoitusta, on piirustustyökalu, ei suunnittelutyökalu.

Rajoitusten ja indeksien käsittely. Ensisijaiset avaimet, yksilöllisyysrajoitukset, tarkistusrajoitukset (check constraints), oletusarvot, null-arvoisuus ja indeksit ovat asioita, joilla todelliset skeemat saavat luotettavuutensa. Erityisesti indeksisuunnittelu on suorituskykyyn liittyvä päätös, joka kuuluu suunnitteluvaiheeseen, eikä sitä tule lisätä vasta ensimmäisen hitaan kyselyn jälkeen.

Skeeman generointi ja migraatio. Työkalun tulisi tuottaa DDL-koodia (data definition language), jota tietokanta voi suorittaa, ja mieluiten migraatiopolku nykyisestä skeemasta uuteen. Tämä on rajaviiva mallintajan ja rakennusjärjestelmän välillä.

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

Dokumentointi ja käänteinen suunnittelu. Työkalun osoittaminen olemassa olevaan tietokantaan ja tarkan kaavion saaminen takaisin on välttämätöntä kaikille, jotka perivät legacy-järjestelmän. Käänteisen suunnittelun laatu vaihtelee suuresti.

Tietokantataulukoiden suunnittelutyökalujen neljä luokkaa

1. Pelkät kaaviomallintajat

Työkalut kuten draw.io, Lucidchart ja yleiskäyttöisten kaaviosarjojen ER-kaavio-ominaisuudet mahdollistavat entiteetti-suhdekaavioiden nopean piirtämisen. Ne ovat lyömättömiä skeeman hahmotteluun ei-teknisten sidosryhmien kanssa, ja ne vievät kuvia, jotka toimivat dokumentaatiossa.

Kompromissina on se, että kaaviolla ei ole yhteyttä käynnissä olevaan tietokantaan. Mikään ei estä kenttää nimeämästä uudelleen kaaviossa mutta ei tietokannassa, tai päinvastoin. Vuosia kestävässä skeemassa tämä ajautuminen on yleisin sekaannusten lähde pienissä tiimeissä.

Jos olet ostoksilla: — Halpakoodisovellusten rakentaja, joka liitetään laajempaan Zoho-sviittiin ja hinnat käyttäjää kohti sovelluksen sijaan..

2. Skeema-ensimmäiset SQL-editorit ja IDE:t

DBeaver, JetBrains DataGrip, pgAdmin, MySQL Workbench ja SQL Server Management Studio sisältävät kaikki visuaalisia taulukoiden suunnittelijoita, jotka luovat todellista DDL-koodia live-yhteyden kautta. Määrität sarakkeet ruudukossa, määrität tyypit ja rajoitukset, ja työkalu lähettää ja suorittaa CREATE TABLE tai ALTER TABLE -lauseen.

Tämä kategoria sopii kehittäjille, jotka lukevat SQL-kieltä sujuvasti ja haluavat itse tietokannan olevan totuuden lähde. Varauksena on, että näiden työkalujen visuaaliset suunnittelijat tuottavat usein oikean, mutta ei tarkasteltavan DDL-koodin: saat lopullisen tilan, et migraatioskriptiä, jonka voisit lisätä pull requestiin. Niiden yhdistäminen migraatiokehykseen ratkaisee tämän ongelman.

3. Integroidut low-code- ja sovellusalustat

Alustat kuten 4D, FileMaker, Microsoft Power Platform with Dataverse ja muut vastaavat sovelluskehitysympäristöt käsittelevät taulukon määrittelyä osana sovellusprojektia. Esimerkiksi 4D:ssä rakenneeditori määrittelee taulukot, kentät ja relaatiot, ja nämä määritelmät ovat välittömästi lomakkeiden, kyselyjen ja sisäänrakennetun kielen käytettävissä: erillistä ORM-kerrosta ei tarvitse synkronoida.

Etu pienille IT-rakentajitiimeille on johdonmukaisuus: kun kentän tyyppiä muutetaan rakenteessa, siihen sidottu lomake, siihen liitetty arvolista ja sitä suodattava kysely näkevät kaikki saman määritelmän. Kompromissina on siirrettävyys. Alustan luettelossa määritetty skeema on yleensä vietävissä, mutta ei triviaalisti siirrettävissä toiseen suoritustilaan.

4. Migraatio- ja schema-as-code-kehykset

Flyway, Liquibase, Prisma Migrate, Alembic ja Entity Framework Migrations käsittelevät skeemaa versioituna tekstinä. Kirjoitat tai generoit migraatiotiedostoja, committaat ne ja käytät niitä järjestyksessä eri ympäristöissä.

Tämä on vahvin vaihtoehto tiimeille, jotka käyttävät jo Gitiä ja jatkuvaa integraatiota, koska skeeman muutoksista tulee tarkasteltavia artefakteja, joilla on historia. Hintana on, että visuaalisesta mallista tulee (jos sellaisen haluaa) johdettu näkymä eikä totuuden lähde: tarvitset erillisen vaiheen kaavioiden regenerointiin live-skeemasta.

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

Vertailu: Mikä tietokantataulukoiden suunnittelutyökaluluokka sopii millekin tiimille

LuokkaTotuuden lähdeParas seuraavillePääasiallinen heikkous
Pelkkä kaaviomallintajaPiirustusViestintä, varhaiset suunnittelutyöpajatEi pakotusta, ajautuu erilleen tietokannasta
Skeema-ensimmäinen SQL-editoriLive-tietokantaSQL-kieleen tottuneet kehittäjätGeneroitu DDL on vaikea tarkastella muutoksena
Integroitu low-code-alustaAlustaprojektiPienet tiimit, jotka julkaisevat yrityssovelluksiaRajoitettu siirrettävyys muihin suoritustiloihin
MigraatiokehysVersioidut migraatiotiedostotGitiä ja CI/CD:tä käyttävät tiimitEi visuaalista mallia, ellei sitä generoida erikseen

Tietokantataulukoiden suunnittelutyökalun arviointi: Kriteerien tarkistuslista

Näiden kriteerien läpikäynti järjestyksessä karsii nopeasti useimmat ehdokkaat.

  1. Käyttääkö se sitä, mitä se piirtää? Generoi DDL ja tarkista se. Vierasavainten, yksilöllisyysrajoitusten ja tarkistusrajoitusten on oltava mukana.
  2. Voidaanko skeema viedä tekstinä? Jos ainoa vientimuoto on proprietäärinen binaaritiedosto tai kuva, et voi verrata, tarkistaa tai hakea sitä puhtaasti.
  3. Hallitseeko se migraatiot vai vain luomisen? Taulukon luominen on yksinkertaista. Taulukon muokkaaminen tietokannassa, jossa on live-dataa – ei-nullattavan sarakkeen lisääminen, taulukon jakaminen, tyypin muuttaminen – on vaihe, jossa työkalut todistavat arvonsa.
  4. Kuinka hyvä käänteinen suunnittelu on? Osoita työkalu todelliseen, sotkuiseen tuotantotietokantaan ja katso tulokset. Kommentit, indeksit ja rajoitukset ovat yleensä ensimmäisiä uhreja.
  5. Ymmärtääkö se kohdetietokantasi erityistyypit? PostgreSQL:n jsonb, SQL Serverin datetimeoffset ja MySQL:n enum eivät ole keskenään vaihdettavissa, ja työkalu, joka tasoittaa ne kaikki “tekstiksi”, maksaa myöhemmin.
  6. Mitä tapahtuu lomakkeille ja kyselyille, kun kenttä muuttuu? Integroidussa alustassa tämä on automaattista; jaetussa pinossa tämä on manuaalinen refaktorointi.
  7. Onko olemassa nimeämiskäytäntöä, jota voit pakottaa? Taulukoiden ja sarakkeiden johdonmukainen nimeäminen kannattaa vuosien ajan. Jotkut työkalut sallivat mallien määrittämisen; useimmat eivät.

Suunnittelun perusteet, joita työkalu ei tee puolestasi

Mikään tietokantataulukoiden suunnittelutyökalu ei kerro, onko skeemasi oikea. Muutama periaate hoitaa suurimman osan työstä.

Normalisoi ensin kolmanteen normaalimuotoon. Jokaisen ei-avainmääritteen on oltava riippuvainen avaimesta, koko avaimesta eikä mistään muusta kuin avaimesta. Tämä eliminoi päivitysanomalioita, eli tilanteita, joissa sama fakta on tallennettu kahteen paikkaan ja kopiot eivät täsmää. Wikipedian artikkeli tietokantojen normalisoinnista on vankka viite normaalimuotoihin ja niiden perusteluihin.

Meidän valintamme: — Pitkäaikainen tiimeille, jotka tarvitsevat mukautettuja sovelluksia työpöydälle, verkkoon ja mobiililaitteille yhdestä tiedostosta..

Valitse avaimet harkitusti. Surrogate-kokonaisluku tai UUID-ensisijainen avain sekä erillinen yksilöllisyysrajoitus luonnolliselle avaimelle on yleinen ja perusteltu malli. Muuttuvan liikearvon, kuten sähköpostiosoitteen, käyttäminen ensisijaisena avaimena aiheuttaa kaskadipäivitysongelmia.

Mallinna monta-monta-suhteet liitostaulukolla. Liitostaulukko, jossa on kaksi vierasavainta ja valinnaisesti itse suhdetta kuvaavia attribuutteja, on standardiratkaisu. Pilkuilla eroteltujen listojen tallentaminen yhteen sarakkeeseen on anti-malli, joka aiheuttaa tuskallisimmat migraatiot myöhemmin.

Päätä nimenomaisesti pehmeistä poistoista. deleted_at-aikaleimasarake säilyttää historian, mutta monimutkaistaa jokaista kyselyä. Kova poisto on yksinkertaisempaa, mutta peruuttamattomaa. Valitse yksi ja käytä sitä johdonmukaisesti sekoittamisen sijaan.

Suunnittele tarkastettavuus alusta alkaen. Created-at, updated-at ja created-by -sarakkeet ovat halpoja lisätä suunnitteluvaiheessa ja kalliita täyttää jälkikäteen.

Missä integroidut alustat muuttavat laskelmaa

Pienen tiimin IT-rakentajalle integroidun alustan vetovoima on siinä, että tietokantataulukoiden suunnittelutyö ei ole erillinen vaihe. 4D:ssä rakenneeditori on paikka, jossa taulukot, kentät ja suhteet määritellään, ja samat määritelmät ohjaavat lomakkeita, listaruutuja, arvolistoja ja sisäänrakennettua kyselykieltä. Kentän tyypin muuttaminen heijastuu automaattisesti sitä näyttävään käyttöliittymään.

Tämä on tärkeää, koska pienyrityssovellusten kalleimmat virheet eivät ole SQL-virheitä, vaan ristiriitoja sen välillä, mitä tietokanta tallentaa ja mitä lomake odottaa. Alusta, joka omistaa molemmat päät tästä sopimuksesta, poistaa ristiriidan rakenteellisesti.

Rehellinen varaus on, että integroidut alustat edellyttävät sitoutumista niiden suoritustilaan. Jos sovelluksen odotetaan elävän alustaa pidempään tai jos tiedot on avattava muille järjestelmille vakaan SQL-rajapinnan kautta, varmista, että alusta tukee standarditietokantayhteyksiä ja puhdasta skeeman vientiä ennen rakentamista.

Käytännön työnkulku: Tyhjältä sivulta toimitettuun skeemaan

Toistettava sarja, joka toimii kaikissa neljässä kategoriassa:

  1. Listaa substantiivit. Kirjoita ylös kaikki entiteetit, joista liiketoiminnassa puhutaan: asiakkaat, tilaukset, laskut, toimipisteet, teknikot. Näistä tulee ehdokastaulukoita.
  2. Listaa verbit. Jokaisesta substantiivien välisestä suhteesta tulee vierasavain tai liitostaulukko.
  3. Luonnostele kaavio. Käytä tässä pelkkää kaaviotyökalua. Se on nopeaa ja mahdollistaa ei-teknisen palautteen.
  4. Määritä tyypit ja rajoitukset. Siirry työkaluun, jolla oikeasti rakennat, ja aseta tyypit, null-arvoisuus, oletukset ja avaimet.
  5. Generoi ja tarkasta DDL. Lue generoitu SQL. Jos et pysty lukemaan sitä, se on itsessään merkittävä havainto.
  6. Täytä realistisella datalla. Kymmenen riviä uskottavaa dataa paljastaa tyyppi- ja pituusvirheet, jotka tyhjä skeema kätkee.
  7. Luo päästä päähän -lomake. Tämä on integraatiotesti. Jos lomake vaatii kiertotapoja tietojen näyttämiseksi, skeema on väärä.
  8. Versioi skeema. Committaa DDL- tai migraatiotiedostot. Jokainen myöhempi muutos muodostaa uuden tiedoston, ei koskaan muutosta vanhaan.

Lähteet ja lisälukemista

  • Table (database) — Wikipedia: In a database, a table is a collection of related data organized in table format (consisting of columns and rows). In relational databases, and flat file databases…
  • Design tool — Wikipedia: Design tools are objects, media, or computer programs, which can be used to design. They may influence the process of production, expression and perception of design…

Usein kysyttyjä kysymyksiä

Mikä on paras tietokantataulukoiden suunnittelutyökalu aloittelijoille?

Aloittelijat hyötyvät eniten integroidusta alustasta, jossa taulukon määritys, lomake ja kyselykieli jakavat yhden projektin, koska synkronoitavaksi ei jää erillistä kerrosta. Pelkät kaaviotyökalut ovat hyvä ensimmäinen askel entiteetti-suhdemallinnuksen oppimisessa, mutta ne eivät pakota mitään. Käytännön polku on piirtää kaaviotyökalulla ja rakentaa sitten alustalla, joka omistaa skeeman.

Voinko suunnitella tietokantataulukoita kirjoittamatta SQL:ää?

Kyllä. Visuaaliset taulukkosuunnittelijat työkaluissa, kuten DBeaver, pgAdmin ja MySQL Workbench, luovat DDL:n puolestasi, ja sisäänrakennetut matalakoodialustat piilottavat SQL:n kokonaan rakenneeditorin taakse. Huomioitavaa on, että sinun pitäisi silti opetella lukemaan luotua SQL:ää, koska tämä on ainoa luotettava tapa varmistaa, että työkalu tuotti aiot rajoitukset.

Mitä eroa on tietomallilla ja tietokantaskeemalla?

Tietomalli on kokonaisuuksien, attribuuttien ja suhteiden käsitteellinen kuvaus, joka on riippumaton tietystä tietokantatuotteesta. Tietokantaskeema on kyseisen mallin konkreettinen toteutus tietyssä järjestelmässä, mukaan lukien tarkat tietotyypit, indeksit ja rajoitukset. Suunnittelutyökalujen avulla voit yleensä työskennellä mallitasolla ja luoda sitten skeeman.

Kuinka monta taulukkoa pienyrityssovelluksessa tulisi olla?

Oikeaa määrää ei ole, mutta useimmat pienyrityssovellukset päätyvät jonnekin noin kymmenen ja viidenkymmenen taulukkoon, kun asiakkaat, tilaukset, rivikohdat, viitetiedot, käyttäjät ja tarkastustaulukot otetaan huomioon. Hyvin vähän taulukoita sisältävä skeema osoittaa yleensä, että toistuvia tietoja on pakattu yksittäisiin sarakkeisiin, mikä aiheuttaa ongelmia myöhemmin.

Pitäisikö minun käyttää sijaistunnusta vai luonnollista avainta?

Sijaistunnukset (automaattisesti kasvavat kokonaisluvut tai UUID:t) ovat yleensä turvallisempia, koska ne eivät koskaan muutu ja erottavat skeeman mahdollisesti kehittyvistä liiketoimintasäännöistä. Luonnolliset avaimet, kuten sähköpostiosoite tai tuotekoodi, voidaan silti pakottaa yksilöllisellä rajoituksella sijaistunnuksen rinnalla. Tämä antaa sinulle sekä vakauden että liiketoimintatason ainutlaatuisuuden, jota tarvitset.

Kuinka pidän kaavion synkronoituna todellisen tietokannan kanssa?

Luo kaavio reaaliaikaisesta tietokannasta sen sijaan, että ylläpidät sitä käsin käyttämällä tietokantataulukon suunnittelutyökalun käänteissuunnitteluominaisuutta. Jos työkalusi ei voi tehdä käänteissuunnittelua, käsittele kaaviota dokumenttina, jossa on viimeinen voimassaolopäivä, ja luo se uudelleen jokaisen skeeman muutoksen jälkeen. Migraatiokehyksiä käyttävät tiimit lisäävät usein rakennusprosessiinsa vaiheen, joka luo kaaviot automaattisesti uudelleen.

Valinta yhdellä lauseella

Valitse tietokantataulukoiden suunnittelutyökaluksi luokka, joka vastaa skeeman sijaintia: kaavio keskusteluja varten, SQL-editori kehittäjien omistamille tietokannoille, siirtotiedostot Git-pohjaisille tiimeille ja integroitu alusta, kun haluat taulukoiden, lomakkeiden ja arvoluetteloiden pysyvän yhtenäisinä ilman manuaalista synkronointia.

Usein kysytyt kysymykset

Mikä on paras tietokantataulukon suunnittelutyökalu aloittelijoille?

Aloittelijat hyötyvät eniten integroidusta alustasta, jossa taulukon määritys-, lomake- ja kyselykieli jakavat yhden projektin, koska synkronoinnissa ei ole erillistä tasoa. Pelkät kaaviotyökalut ovat hyvä ensimmäinen askel entiteetti-suhteiden mallintamisen oppimisessa, mutta ne eivät pakota mitään. Käytännön polku on piirtää kaaviotyökalu ja rakentaa sitten alusta, joka omistaa skeeman.

Voinko suunnitella tietokantataulukoita kirjoittamatta SQL:ää?

Kyllä. Visuaaliset taulukkosuunnittelijat työkaluissa, kuten DBeaver, pgAdmin ja MySQL Workbench, luovat DDL:n puolestasi, ja sisäänrakennetut matalakoodialustat piilottavat SQL:n kokonaan rakenneeditorin taakse. Varoitus on, että sinun pitäisi silti opetella lukemaan luotua SQL:ää, koska tämä on ainoa luotettava tapa varmistaa, että työkalu tuotti aiot rajoitukset.

Mitä eroa on tietomallilla ja tietokantaskeemalla?

Tietomalli on kokonaisuuksien, attribuuttien ja suhteiden käsitteellinen kuvaus, joka on riippumaton tietystä tietokantatuotteesta. Tietokantaskeema on kyseisen mallin konkreettinen toteutus tietyssä järjestelmässä, mukaan lukien tarkat tietotyypit, indeksit ja rajoitukset. Suunnittelutyökalujen avulla voit yleensä työskennellä mallitasolla ja luoda sitten skeeman.

Kuinka monta taulukkoa pienyrityssovelluksessa tulisi olla?

Oikeaa määrää ei ole, mutta useimmat pienyrityssovellukset päätyvät jonnekin noin kymmenen ja viidenkymmenen taulukkoon, kun asiakkaat, tilaukset, rivikohdat, viitetiedot, käyttäjät ja tarkastustaulukot otetaan huomioon. Hyvin vähän taulukoita sisältävä skeema osoittaa yleensä, että toistuvia tietoja on tukahdutettu yksittäisiin sarakkeisiin, mikä aiheuttaa ongelmia myöhemmin.

Pitäisikö minun käyttää korvaavainta vai luonnollista avainta?

Korvaavat avaimet (automaattisesti kasvavat kokonaisluvut tai UUID:t) ovat yleensä turvallisempia, koska ne eivät koskaan muutu ja irrota skeemaa mahdollisesti kehittyvistä liiketoimintasäännöistä. Luonnolliset avaimet, kuten sähköpostiosoite tai tuotekoodi, voidaan silti pakottaa yksilöllisellä rajoituksella sijaisavaimen rinnalla. Tämä antaa sinulle sekä vakauden että liiketoimintatason ainutlaatuisuuden, jota tarvitset.

Kuinka pidän kaavion synkronoituna todellisen tietokannan kanssa?

Luo kaavio reaaliaikaisesta tietokannasta sen sijaan, että ylläpidät sitä käsin käyttämällä tietokantataulukon suunnittelutyökalun käänteissuunnitteluominaisuutta. Jos työkalusi ei voi käännellä, käsittele kaaviota dokumenttina, jossa on viimeinen voimassaolopäivä, ja luo se uudelleen jokaisen skeeman muutoksen jälkeen. Siirtokehystä käyttävät tiimit lisäävät usein rakennusprosessiinsa vaiheen, joka luo kaaviot automaattisesti uudelleen. Valinta yhdellä lauseella Valitse tietokantataulukon suunnittelutyökalulle luokka, joka vastaa skeemasi sijaintia: keskustelukaavio, SQL-editori kehittäjien omistamalle tietokannalle


Kokeile FileMakeria ilmaiseksi 45 päivää

Pitkäaikainen relaatiotietokanta-alusta tiimeille, jotka tarvitsevat mukautettuja sovelluksia työpöydälle, verkkoon ja mobiililaitteille yhdestä tiedostosta.