Introduce to file.dbs (database-schema)

Pošto u zadnje vrijeme svašta nešto normaliziram…evo još jednog meni jako važnog djela.
Znači ideja je da se struktura baze održava kroz nekakvu schemu koja je pregledna i koju je jednostavno održavati.
Tako radim skoro otkako radim sa bazama i stvar je od neprocjenjive vrijednosti.
Naravno, kako je taj pristup odličan… onda taj pristup nije gotovo nitko zaobišao…tako da mnogi frameworci imaju opciju održavanja strukture baze tako nekim pristupom.

No ono što sam do sada vidio unutar drugih frameworka, je po malo promašilo footbal.
Mnogi od njih su tu strukturu održavanja baze isprepleli sa funkcijama i code-om samog frameworka…a to nikako nije cilj. U najamanju ruku je problem što onda ta struktura nije lako prenosiva…a i svašta još nešto se za time povlači.

Stoga najveći benefit bi bio za sve strane da se osmisli buety sintaksa koja je jednostavna za pisati…koja nije zagađena nikakvom suvišnom sintaksom …i onda da se frameworci oslanjaju na tu sintaksu da dalje po njoj održavaju strukturu baze.

Ja sam to osobno u svom frameworku izveo na način da framework samostalno prepozna ako sam mijenjao nešto unutar scheme baze …i onda automatski restruktuira bazu…tako da ne moram niti kucati nekakve glupave naredbe kroz konsolu tipa: “Add migration → update database”.
Što bi to kucao? Ako sam promjenio schemu to je već dovoljan znak frameworku da želim da baza prati tu strukturu. I to onda radi glatko i tečno…

U tu svrhu ću predstaviti najjednostavniju sintaksu do koje sam uspio doći…koja se lako parsira i lako širi sa novim metapodacima, jer sigurno da nisam uveo sve metapodatke u startu…

Sintaksa je sama po sebi skroz intuitivna:

table_prefix = system  	 		
table_used = car*, accident 	
component=system				
engine=InnoDB					
charset=utf8 					
collate=utf8_bin 				
   
car
	carID INT UNSIGNED NOT NULL	 
	color VARCHAR(10)
	hp INT UNSIGNED
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (carID)

	comment=This is table about cars

car_accidents
	rowID INT UNSIGNED NOT NULL
	carID INT UNSIGNED
	accidentID INT UNSIGNED
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (rowID)

	UNIQUE(carID, accidentID)
	charset=utf16

accident
	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	city VARCHAR(50)
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city) 



A evo je i sa pojašnjenjima pod kojim pravilima mora biti pisana:

// metadata of .dbs schema, for example... 

table_prefix = system  	 		// prefix addad to any of table name below
table_used = car*, accident 	// list of table which will be generated from tables below. For listing tables it's used syntax described >here<
component=system				// component name associated with tables below -> it can help system to organize tables with different databases.
engine=InnoDB					// master configuration for all tables...it can be overwrited for any table independent
charset=utf8 					// -- || --
collate=utf8_bin 				// -- || --
comment= some master comment	// -- || -- 
   
car
	
	carID INT UNSIGNED NOT NULL	 
	color VARCHAR(10)
	hp INT UNSIGNED
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (carID)

	comment=This is table about cars

car_accidents
	rowID INT UNSIGNED NOT NULL
	carID INT UNSIGNED
	accidentID INT UNSIGNED
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (rowID)

	UNIQUE(carID, accidentID)
	charset=utf16

accident
	accidentID INT UNSIGNED NOT NULL,
	country VARCHAR(50),	 	 
	city VARCHAR(50),	 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
	PRIMARY KEY (accidentID),
	INDEX(country,city),



/*
Table schema block, upute:

Prva linija je ime tablice. Ta linija ne smije sadržavati ništa u svom retku, tj. mora se nalaziti samostalno u svom redu. Po tom pravilu se djele table-blokovi
Nakon toga dolazi popis definicija polja tablice. Te definicije su ekvivalente SQL definicijama polja, osim što svako polje mora biti opisano u svom retku, ali zato definicija polja ne mora završavati razmakom.
Nakon popisanih polja, mora biti navedeno PIRMARY KEY polje
Nakon PRIMARY KEY-a mogu biti dodani meta-podaci o tablici koji mogu sadržavati: (U uglatim zagradam su popisane defaultne vrijednosti tih parametara)

	- index
	- unique
	- engine  [InnoDB]
	- charset [utf8]
	- collate [utf8_bin]
	- comment

Format pisanja metapodataka može biti na dva načina, npr. sljedeće dvije instrukcije imaju isto značenje:
	INDEX = carID
	INDEX(carID)

Ali svaki meta-podatak mora ići u novu liniju!

*/

Svaka sugestija što smatrate da bi bilo nezaobilazno u startu uvesti u tu sintaksu, je dobrodošla. :wink:

P.S. a u modularnom sistemu koji sam spomenuo u temi do, svaka komponenta će nositi sa sobom svoj .dbs file kako bi rekla sistemu u koji se instalira što joj od baze treba.

Koliko baza održavaš da ti treba ovako nešto?

Osobno, održavanje baza radim ručno, NEMA AUTOMATIKE.

Iskreno ni ja ne volim pretjerano automatike kod održavanja baze …pogotovo onu automatiku čiji source code mi nije dobro poznat. Igrao sam se nešto sa entity frameworkom, koji ima tu logiku da automatski hendla bazu…pa mi je jednom sve pobrisao iz vrag zna kojeg razloga. Očito je bilo do mog nepoznavanje dokumentacije…ali kod baze si ne želim priuštiti da zbog nepoznavanja dokumentacije imam takva iznenađenja.

E sad, ovo gore je tako prosta logika i bez puno kerefeka…da je praktički 100% pouzdana i svatko si to može složiti u par dana posla. A prednosti su stvarno mnogobrojne.
Radim tako već 6 godina i nikada sa tim alatićem nisam imao problema. A osjećaj kada takav dio posla automatiziraš…još dan danas osjećam rastrećenje utega sa leđa. Stvarno nešto bez čega više nebi pomišljao raditi “niti u snovima”. I ovo radi osjetno fluidnije od migracija koje sam probao i u Laravelu i u ASP. NET MVC5 frameworku.

Prednosti:

  1. Nakon što razvijaš nešto lokalno, vjerovatno se razvija i struktura baze. Nakon publishiranja projekta onda moraš sve te promjene raditi ponovno na bazi. Što je:
  • podložno greški

  • utrošak vremena

  • čimpanza posao

  • te je i nezgodno pratiti koje promjene su se sve desile lokalno

  • i što ćeš sa onim vremenom između publishiranja novog programa i updejta strukture baze? Ako radiš ručno, ili moraš prvo updejtati strukturu baze…ili prvo publishirati novi code. U međuvremenu dok nisu sinkronizirani onda moraš zaključavati izvršavanje programa…da se nebi nešto “polomilo”. (Nije uvijek opasnost, ali može biti)

  1. Ako program radi na više publishiranih instanci…npr. prodao si program ka više klijenata i svaki taj klijent kod sebe ima svoju bazu u pozadini programa. I sve te baze su očito iste strukture pošto su dio istog programa.
    Onda tu ovakav način rada iskače oho-ho na vidjelo kada ti je dovoljno napraviti updejt programa, a struktura baze se sama podesi prema novoj potrebi. Tu bi žešći “pain in the ass” bio to ručno hendlati.

E sad, moja uporaba ovako nečega će se tek razgranati.
Kao što već rekoh, sa .dbs file-om svaka komponenta može imati svoju vlastitu definiciju što joj treba na bazi. I onda se može automatizirati instalacija takvih komponenti.
Naravno, ima tu fine problematike za rješiti…

…npr,

  • što ako dvije komponente zahtjevaju da imaju tablicu istog imena?
  • kako ograničiti da jedna komponenta ima pristup samo svojim tablicama ?
    …itd.

No ta problematika nema veze sa .dbs sintaksom.
.dbs sintaksu sam zamislio kao osnovu za schemu koja jednoznačno i elegantno opisuje kako treba izgledati struktura baze. Kako će to tko upotrijebiti, u potpunosti je na njemu.

Pravo pitanje se jedino postavlja zašto nisam išao sa .SQL sintaksom…pa zato jer ima suvišnih djelova. Ja sam kod smišljanja sintaksi orijentiran na strogi minimalizam.

Znači imamo SQL:

CREATE TABLE IF NOT EXISTS `car` (
  `carID` int(10) UNSIGNED NOT NULL,
  `color` varchar(10) DEFAULT NULL,
  `hp` int(10) UNSIGNED DEFAULT NULL,
  `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='';

ALTER TABLE `car`
  ADD PRIMARY KEY (`carID`),
  ADD KEY `color` (`color`);



CREATE TABLE IF NOT EXISTS `accident` (
  `accidentID` int(10) UNSIGNED NOT NULL,
  `country` varchar(50) DEFAULT NULL,
  `city` varchar(50) DEFAULT NULL,
  `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `datum` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='';

ALTER TABLE `accident`
  ADD PRIMARY KEY (`accidentID`),
  ADD KEY `country___city` (`country`,`city`),


vs moje:

engine=InnoDB
charset=utf8
collate=utf8_bin

car

	carID INT UNSIGNED NOT NULL
	color VARCHAR(10)
	hp INT UNSIGNED 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (carID)
	INDEX(color)

accident

	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	city VARCHAR(50) 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city)

Mislim da nema nikakve dvojbe što je preglednije i jednostavnije za ručno održavanje.

A da ne govorim da čisti SQL niti ne može baš direktno paziti da ne dodaje index ukoliko isti već postoji, pa bi se gornji SQL kod dodavanja indexa još morao dodatno nagrditi sa nekakvim naredbama sljedećeg tipa:

```
SELECT COUNT(1) IndexIsThere FROM INFORMATION_SCHEMA.STATISTICS
WHERE table_schema=DATABASE() AND table_name='mytable' AND index_name='index_name';
```

…a onda bi direktna SQL schema izgledala katastrofalno za ovakvu primjenu.
A složiti engine koji .dbs prevodi u .sql nije problem.

Svaki novi projekt moraš uglavnom održavati minimalno jednu bazu. To je već dovoljno za ovakav alat da se isplati.

Iako rekoh da ni ja ne volim pretjerano automatiku, malo sam baš danas proširio mogućnosti engina koji imam. Naime o čemu se radi…ako razvijaš strukturu baze i dođeš do tablice recimo:

accident
	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	city VARCHAR(50) 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city)

I sada u jednom momentu odlučiš obrisati polje city i imaš novu schemu:

accident
	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city)

Moj engine do sada nije brisao to polje. (Ne briše ga ni sada, jer bi takav pristup bio suviše opasan.)
Do sada sam ručno odrađivao brisanje polja, tablica ili indexa …pa sam imao nula straha da može nešto slučajno poći po zlu samo od sebe.

E sad, i te rijetke situacije kada sam nešto morao ručno brisati u bazi…su mi dopizdile, heh. Tako da sam odlučio napraviti nešto po tom pitanju. I napravio sam to tako da se mora ručno zadati da se neko polje briše…to je onda unutar logike engine-a dovoljno pouzdano da ne može slučajno nešto biti obrisano.

accident
	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	- city VARCHAR(50) 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city)

Znak minus sam izabrao kao najelegantniji način …ali me ovaj razgovor nečemu naučio. :smiley:
Iako je ovako engine pouzdan, netko tko nebi čitao dokumentaciju, mogao bi nehotice ostaviti upisan minus i nesvjesno obrisati polje.
Zato konačna odluka pada na:

accident
	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	DELETE city VARCHAR(50) 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city)

ili

accident
	accidentID INT UNSIGNED NOT NULL
	country VARCHAR(50)	 	 
	date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
	PRIMARY KEY (accidentID)
	INDEX(country,city)
	DELETE_FIELD(city)

Sumnjam da netko nehotice može koristiti keyword DELETE :slight_smile:

Heto, hvala što si me naveo na to saznanje. :slight_smile:

Meni se ova ideja cini ok, iako sam totalni noob sto se tice baza.

Inace ja bih ovo napravio kao neki CLI, umjesto da se sve samo izvrsava prilikom izmjene file-a.
Jednostavno daje vise fleksibilnosti i sigurnosti.

Sto se sintakse tice jesi razmisljao da koristis yaml ili toml umjesto da pises svoj “mini jezik” ?

Lagano sam skeptičan…
Baza mi je uvijek bila previše vrijedna da bih je prepustio automatikama.

Ovakve stvari su korisne jer ako na kraju i propadne sve jako ćeš puno naučiti. Ja bih samo spomenuo da možda imaš malo krivu predodžbu o framework-cima koje automatiziraju rad s bazom, njezinom strukturom i migracijama. Npr. ovaj engine koji ti radiš ima skoro svaki framework ili lib koji se brine o strukturi baze i njezine migracije.

Ja imam najviše iskustva s Django ORM-om i njegovim migracijama i to je jedna od najboljih stvari kod njega - rješava te muke, problema i gnjavaže. Napišeš model, pokreneš komandu koja izgenerira migraciju i to je to. Ono što on radi je da ti i omogućuje da se vratiš na bilo koji prethodni korak u migracijama.

Oni koji se hvale da sve to rade ručno i da ne vjeruju automatizacijama očito nisu radili na velikim projektima i u velikim-raznolikim timovima. U većini timova kreiranje i migracija baze se događa nekoliko puta u procesu razvoja. Npr. svaki developer kad počne raditi na projektu. Pa onda ako piše testove koji moraju za svoje potrebe kreirati novu bazu. Pa onda kad se kod push-a u repozitorij neki pokreću automatske testove (continious integration). Pa imamo testne, staging i produkcijske poslužitelje. Svaka ta grupa ima svoju bazu na kojoj treba održavati strukturu, okidati migracije. Ako se taj proces na automatizira imaš veliki problem i veliki gubitak nečijeg vremena.

Ako sam dobro shvatio, ti migracije obicno pises u jeziku u kome je napisan framework ?

Prednost ovog pristupa je to sto je language-agnostic, ako se to moze uzeti kao prednost :slight_smile:
Mana ovog u odnosu na to sto nude FW-ci je to sto nemas nacina da uradis rollback.

Da piše se u Pythonu.

Npr. primjer modela (polja su ona koju su definirana uz pomoć models.TipPolja):

Migracija je ovakva (generirani kod, ne piše se ručno):

Neko generičko rješenje za održavanje strukture baze i migracije definitivno ima svoju potencijalnu korisničku bazu. Nemaju ni svi frameworci rješenja koja rade. :wink:

1 Like

Bilo bi mi jako čudno da ti nije ok. …kao što mi je u nekim temama čudno. :stuck_out_tongue:
Ali ova ideja je puno manje “ispred vremena”, nego druge …pa ću imati razumjevanja.

Bravo, odličan hint.
Razmišljao sam o tako nekakvoj jednostavnoj sintaksi da je treba uvesti za ovakve stvari…ali nisam znao da postoji yaml. Sada vidim da on upravo podržava to o čem sam razmišljao…da se sa jednostavnom sintaksom može opisati podosta toga…proučit ću ga svakako. Ako ne upadne ovdje, upast će sigurno u buduće “normalizacijske” zahvate.
Ovdje sam vagao sa JSON-om …ali on je “bljak” ako tražimo lijepu sintaksu.

Postoji način da bude još vrijednija, a ne da se to uništi. :slight_smile:
Baza je vrijedna upravo zato jer automatizira puno toga…ili ćeš svaki puta ručno kontrolirati što smije pobrisati SQL naredba “DELETE * FROM table WHERE …” …ako ne vjeruješ SQL enginu da će to dobro odraditi prema SQL naredbi?

Postoji relativno jednostavni načini da se ovakve automatike uvedu bez ikakve opasnoti i bez ikakvih poteškoća…i bez ikakve ovisnosti o frameworcima. (Ne zagovaram da FW-ci ne valjaju, ali nema svatko priliku uskočiti u njih iz vlaka koji već juri)

Svjestan sam toga…iako to nisam znao u vrijeme kada mi je ovo trebalo i kada sam si to inicijalno složio. Kasnije sam probao kako to funkcionira u Laravelu i .NET MVC5 …i već sam rekao da mi se fluidnost njihove izvedbe nije svidjela.

Istina, ti framworci nude i vraćanje migracija u neki korak ranije…ja to još nisam uveo. Iskreno, nije mi još nikada ni trebalo. Ako bi i sumnjao da ću se u neki korak morati vratiti…nebi mi bio problem spremiti samo tu verziju .dbs file-a i to je to.
A ako bi baš često imao potrebu skakati naprijed/nazad sa migracijama…onda bi si i to automatizirao.
No bitno je primjetiti da to nema veze sa sintaksom .dbs file-a.
.dbs file je osmišljen da može jednoznačno opisati strukturu baze …a hoće li engine koji ga parsira paziti o stupnjevima migracije…to je zaseban i neovisan dio.

Djelomično se slažem, ali nisam htio to tim riječima priopćiti za @trnac …niti je to nužno istina.
Recimo, moji šefovi imaju “milijunski projekat” …i aplikacija koja im to pravi dobiva novu bazu za svakog novog klijenta. (Iako su sve baze iste strukture)
I kada dolaze promjene u strukturama baza…onda sve to ručno štrikaju i tu se više ne zna tko pije tko plaća. A ja im govorim da im je vražji posao sada kada imaju 20-ak baza…što će ih tek čekat kada ih bude 100-njak? :smiley:
Ukazujem im da idu totalno ne-skalabilnim putem.
Ali su pipice jer su im te baze život i nedaju nikom ni blizu bazama (iako svi trenutni i bivši radnici imaju connection-stringove, haha). A sami su nesposobni i u strahu da išta tu unaprijeđuju.
Btw. ja ću im to složiti…ali zasad mi je gušt gledati kako se pate, a vraćam im u život ionako puno bitnije stvari.

Poanta je da ipak imaš ljude koji rade na velikim projektima, ali na primitivan način. :wink: I vjerujem takvih nije malo.

Ono što mi je zanimljivo…dosadašnje iskustvo mi je pokazalo da takvi vrlo često lupaju bolje pare od onih koji se suviše usmjeruju da ne rade na “primitivan” način …ali zato od prevelikog hvatanja sa najnovijim tehnološkim rješenjima…nisu uhvatili vremena razmisliti kuda će usmjeriti to svoje znanje koje već imaju, pa rade za “šaku jada”.

Imaš tako dva tipa ljudi…oni koji se specijaliziraju za neko znanje …i oni koji rade svašta pomalo bez nekog ulaza u dubinu.
Ako razmisliš koje dvije krajnosti takve grupe ljudi mogu biti, onda imaš:

  • ovi prvi su ljudi koji znaju SVE, ali o ničem
  • a drugi su koji znaju o SVEMU, ali ništa

A nijedno ne valja nimalo. Otišao sam van teme kao obično xd …ali želim reći da nije sreća niti u prevelikom poznavanju tehnologije. Treba u svemu biti optimalan…i bitnije je znati usmjeriti ono što već znamo, nego bespotrebno težiti novom učenju ako dosadašnje još nismo upogonili kako treba.

Netko tko neće automatizirati te neke aspekte nad bazom…ništa ga ne koči da ono “sitno” što zna, da to i hebeno dobro usmjeri.

To je itekako ogromna prednost.

To nije mana ovog pristupa…jer kao što rekoh, ovaj pristup nije ničim ograničen da ima sve što imaju FW-ci koje spominjete.
Ograničenja mogu postojati konkretno u nekom engineu koji će parsirati .dbs file…ali to nije ograničenje pristupa, nego konkretno samo tog enginea.

Ovaj pristup može podržati sve što nude moderni FW-ci, a osim toga može ponuditi i više. Tako da ovaj pristup dodatno podiže level fleksibilnosti i generalno mogućnosti.

Inače …kada god se uoči da svi frameworci rade “nešto isto”, to je opravdan razlog da se razmisli kako se to nešto može unaprijediti i normalizirati da sve strane od toga imaju dodatnu korist.

Nemojte misliti da ja to radim sa nekom nadom/iluzijom da ću promjeniti svijet…ne radi se o tome!
Nego ako shvatiš kako bi pomogao comunnity-u, onda si shvatio i kako ćeš pomoći direktno sebi. Jer ako radiš na više projekata sa nekom grupom ljudi, onda si ti već taj “comunity” u svom mini svijetu. I sve što je dobra praksa da unaprijedi globalno comunity …unaprijedit će i tebe osobno ako se držiš takvih principa.
Zato trenutno sva svoja dugogodišnja opažanja želim kvalitetno normalizirati…da postavim sebi čvrst temelj za naredne pustolovine.

To je bilo čisto da pojasnim koja filzofija se skriva iza moga sve učestalijega iskakanja sa temama o novim “normama”.

žž.

Kao i sve drugo…ni to nije ograničenje.
Meni je inače i bez CLI ovo pre-fantastično. Kako si podesim .dbs file, tako mi izgleda baza…i točka.

  • em 100 puta brže ovako razvijam bazu, nego da to radim kroz nekakav phpMyAdmin
  • em nemam nikakvih muka oko održavanja paralelno više baza

Jednostavno daje vise fleksibilnosti i sigurnosti.

Sa CLI bi se mogle uvesti neke dodatne naredbe. Velim nema ograničenja da se doda i to…tako da fleksibilnosti ne može faliti. Sintaksa je temeljni level…na njoj se može izgraditi što god.

A što se tiče sigurnosti…stvarno ne vidim nikakav problem.
Suviše je jasno da ako si otišao svjesno mijenjati .dbs file, da posljedično želiš da ti baza to isprati sa svojom strukturom.

Framework se podesi da lokalno samo na event “fileOnChange()” trigira update baze…a u produkciji da ga trigira samo na onPublish()
Isto tako ako postoji izmjena na .dbs file-u, onda engine unutar sebe nakon što splita po tablicama …ne radi ništa sa onim tablicama koje izgledaju isto kao zadnji put. Tako da ovo stvarno leti…neosjetno da i postoji. Stvar super optimizirana…i effort-less se sve dešava u pozadini.

A hebeno ne kužim zašto u C# kada pokrenem naredbu AddMigration…moram čekati hebenih xx sekundi. I onda još jednom moram čekati xx sekundi nakon što pokrenem UpdateDatabse()
Hebemeu miša, dovoljno bi me živciralo što moram kucati dvije naredbe…a ne što još moram čekati da se i izvrše. Stvarno ne znam koji je klinac u glavi Microsoftovim developerima…užas nad užasom svaki njihov alat. U strukturi samog C# jezika su se napeli ko jarci na zadnje noge da ne izgube milisekundu u run-timeu za prepoznavanju tipa varijable…a u praksi korištenja tih istih alata čekaš 10-ak sekundi za najveće idotarije koje bi trebale ići ispod sekunde… žasu.

Ima neovisnih alata za migraciju, gdje se pise doslovno sql sintaksa.

Jedan od alata je:
https://flywaydb.org/

I nije jedini.

A kako bi u svojoj strukturi rijesio funkcije, procedure, insert statemente i sl.?

Pa ako bi se neki od tih alata fokusirao na sintaksu kao na main point …rado bi preuzeo tu sintaksu. :slight_smile:

Mada, nije ni sintaksa toliko problematična ako postoji u par verzija…dovoljno je da engine može prepoznati o kojoj je riječ i obradi je po njenim pravilima.
Sve sintakse koliko god bile unificirane…uvijek imaju minorne razlike.
Najbitnije mi je da je pristup modularan…da je sintaksa “seljiva” od komponente do komponente. Što nije primjer kod alata koji to imaju integrirano u svoj code.

Pa da ti iskreno kažem, nije mi još trebalo.
Što se tiče funkcija i procedura, kada dođe vrijeme do toga…vrlo jednostavno ću to odraditi. Neću izmišljati ništa novo, nego ću koristiti nativnu sintaksu za procedure…i samo ću ih prenostiti iz .dbs-a do engina koji ih razumije.
Malo ću trebati samo poraditi na tome kako da ih uklopim u postojeću okolinu/strukturu .dbs-a da se zadrži preglednost, ali to vjerujem nebi trebao biti problem.

Za inserte slično, koristit ću se nativnom SQL sintaksom, kao što se koristim kod definicije polja.
Mada su inserti malo tricky…tako da neću žurit sa time. :slight_smile:
Ima tu sada već raznih kombinacija koje upadaju u igru. :smiley:

Ovako iz glave koju problematiku vidim:
(a u praksi uvijek bude više problematike koja se izvana vidi, tako da je to lagano tanak led. xd)

  • kako će kompajler .dbs-a znati jel program s razlogom brisao neki redak koji ima definiran insert?
  • po kojem ključu paziti da se insert ne ponovi? Primary key je najčešće autoincrement…pa i to može biti tricky. (Lako je kod inicijalne situacije kada se prvi puta kreiraju tablice iz nule…ali hendlati putem razlike i sve što može doći sa insertovima…to već postaje lagano tricky. Tu ću se držati onoga što kaže trnac…što manje automatike, glava mirnija)
  • itd.

…kao što rekoh, nemam žurbe sa time. Izgleda jednostavno, ali skriva zamke. :slight_smile: