Jen malé doplnění - PostgreSQL fungoval na Windows od verze 6.4, byť za použití Cygwin - http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7a6b562fdf60f1d1ebe9e2bc154d0ffd56dab2d1 - joj, bývala doba, kdy jsme byli mladí a chytří ;-)
Kdyz se zacinaji psat vzpominkove clanky, tak se neodvratne blizi ctyricitka.
Nic ve zlem, mam uz to davno za sebou. :-)
Klasickou otazkou na vzpomnkovych vecerech penzistu - databasistu je, proc se SQL mela vlastne jmenovat RUFUS?
Nekteri mini, ze to znamenalo 'Relational User Friendly Universal System', ale zasveceni vedi, ze tak se jmenoval pes Franca Putzoly. (Franco Putzolu je spoluautor toho znameho 5-minutoveho pravidla = 'data, ktera jsou potreba behem pristich 5 minut by mela zustat v pameti :-) )
Vzpomínkový článek to není - skoro nic z toho nepamatuju - i když čtyřicítka už je za rohem :) - kdyby to byly memoáry, tak by to bylo o FoxPro, Turbo Pascalu, prvních pokusech ve VBA, kdy jsme syntaxi jazyka luštili z pár příkladů dodaných k Excelu 5.0 :). Ale je hrozně zajímavý sledovat, jak i v Americe je svět malý - v podstatě databáze udělalo pár lidí.
Potvrzuje se, že vzdělaných, schopných a mravných tvůrců je velmi omezené množství a šíření benefitů jejich produktů se neobejde bez komunitní dělby práce. Mám jen jediný dotaz k autorovi či jiným zasvěcencům: Je SQL natolik konfliktní s požadavky na uchovávání dat a manipulaci s nimi v současné době rychlých sítí, cloudů a heterogenních datových struktur, že to vede k nonSQL? Děkuji.
Ono je docela složité - NoSQL databáze mají podstatně jednodušší datový model a díky tomu mohou být jednodušší na implementaci, na provoz - a je fakt, že pro projekty, kde nedochází k hromadnému (dávkovému) zpracování dat je model key/value ideální. Díky jednoduchému modelu lze relativně snadno NoSQL databáze distribuovat, lze je i snadno replikovat. Nic z toho neplatí pro klasické SQL ACID databáze. Ve chvíli, kdy budeme chtít hromadně zpracovat data, tak u NoSQL db narazíme - minimálně větší pracností použití. Je fakt, že klasická architektura SQL databází vznikala začátkem 80 let a opravdu už neodpovídá možnostem, které tu jsou - na druhou stranu - je po třiceti letech docela dobře odladěná - a díky relativnímu nadbytku výkonu tenhle fousatý koncept pořád dobře slouží v praxi a bude sloužit. To samé lze napsat i o OS.
Určitě lze napsat moderní ultrarychlou SQL ACID db - viz VoltDB nebo SciDB - tyto databáze jsou moderní, velice výkonné - a téměř nikdo je nepoužívá, protože jsou příliš nové, nejsou user friendly a stávající SQL db z 80 a 90 let výkonnostně stačí. SQL je natolik dobře vymyšlené, že tu bude dalších 50 let - ohledně architektury SQL databází jsme - cituji Stonebrakera "na konci jedné éry", kdy se u stávajících databází dá čekat jen pokrok v mezích zákona, a bude se čekat cca 5-10 let na další generaci SQL databází, které budou z gruntu napsané pro cloud ať veřejný nebo privátní.
Jen doplneni k aktualnim komercnim projektum - PostgreSQL optimalizovany pro beh na VMware vSphere virtualizaci:
http://www.vmware.com/products/application-platform/vfabric-postgres/overview.html
+ Database as a Service rozhrani:
http://www.vmware.com/products/application-platform/vfabric-data-director/overview.html