[LUGOS-PROG] MySQL vs. Postgresql

Aleksander Kmetec aleksander.kmetec at email.si
Sun Nov 9 10:35:01 CET 2003


Anze wrote:
> Ce se zelis omejiti na eno samo bazo, izvoli - in ja, uporabljaj foreign 
> key-e, transakcije, vse lepe stvari, ki ste se jih ucili pri osnovah 
> relacijskih baz.

Se opravičujem, če se narobe razumel, ampak tole si napisal, kot da so
zgoraj naštete funkcije tam samo za to, da lahko na faksu sestavijo
kompleten izpit; če že niso popolna neumnost.
Upam, da nisi eden izmed tistih, ki mislijo, da so enostavne SELECT,
INSERT, UPDATE in DELETE vse funkcije, ki bi jih kdorkoli, kjerkoli,
kadarkoli lahko potreboval.

> Ampak ko bos selil aplikacijo na drugo bazo, bos naJ... (in 
> to z velikim J) Ampak ti ocitno teh izkusenj se nimas. Blagor enim.

Zakaj bi moral pri selitvi aplikacije naj****? Težave pri portanju med
bazami so skoraj vedno posledica slabega načrtovanja aplikacije, ne pa
posebnosti baz.

Na hitro se spomnim treh možnosti:

a) Funkcionalnost za delo z bazo imaš razmetano po celi aplikaciji. Sicer
je grdo, zahtevno za vzdrževanje in neprimerno za portanje, ker ti ostane
samo izdelava vzporedne verzije; je pa zelo enostavno za sprogramirat.

b) Lahko uporabljaš samo najosnovnejši nabor funkcinalnosti, ki je skupen
vsem bazam. Na tak način dobiš aplikacijo, ki jo je sicer enostavno
prenašati med različnimi tipi baz; nobene izmed teh baz pa ni sposobna
kvalitetno izkoristiti. In bog ne daj, da naletiš na kako bazo, ki katere
od funkcij ne podpira.

c) Pri samem načrtovanju aplikacije, ali pa, v najslabšem primeru, ob prvi
potrebi po portanju, DB funkcionalnost premakneš iz same aplikacije v ločen
layer. S tem ne mislim samo enega fajla z ločenimi SQL stavki za različne
baze, ampak kompleten nabor razredov/funkcij/česarkolipač, ki ti omogočajo
transparentno delo z različnimi tipi podatkovnih baz. Enostavno za
portanje, enostavno za vzdrževanje in lepo organizirano; zahteva pa nekaj
več načrtovanja.

Ko se pojavi potreba po podpiranju nove platforme, se prevede samo ta del.
Tako je npr. shranjevanje zapisa vedno shraniZapis(data), "osrčju"
aplikacije pa se niti slučajno ne sanja, kaj se dejansko zgodi - ali se
podatki zapišejo v MySQL, PostgreSQL, tekstovno datoteko, ali /dev/null.

Seveda ima ta način še eno slabost - dokaj nekompatibilen je z zelo
popularnim načinom programiranja v stilu "najprej začnimo pisati, bomo že
na polovici ugotovili, kaj delamo", ker je zelo dobro vedeti kaj je
potrebno narediti, še preden začneš z delom. Ampak večina "odličnih
programerjev" je predobrih za načrtovanje, "ker je risanje črt in oblačkov
samo za otroke in informatike"** in se ne spuščajo na tak nivo.

(**: neumna izjava, ki jo prepogosto slišimo od študentov računalništva)

Sicer sem zgrešil originalno temo MySQL vs. Postgresql; ampak vsaj ustreza
lugos-prog. :)


LP,
Aleksander








More information about the lugos-prog mailing list