Je možné partition-wise join zapnout jenom pro konkrétní dotaz, např. pomocí něčeho jako jsou hinty u Oracle SQL?
Chápu to tedy tak, že není syntaxe pro to, aby se to zapnulo přímo v SQL dotazu :-) Řešení přes zapnutí pro session je jasné, ale znamená to hlídat, aby se to vzápětí zase vždy vypnulo (i při případné chybě), a u některých nástrojů může být problém místo jednoho příkazu posílat tři. Ale spíš mne to jenom zajímalo, ono se to asi nebude používat tak často, že by to někoho vyloženě trápilo.
Parametrizace části dotazu aktuálně v Postgresu možná není - už to není úplné tabu jako před lety. Řeší se změna chování CTE - kde někde, někdy by se hodilo původní chování, jindy jiné. Analogie hintů v Oracle lze pořešit extenzí http://pghintplan.osdn.jp/pg_hint_plan.html.
Jinak kdyby to bylo nutné zapínat, vypínat per command - tak je možné SQL příkaz zapouzdřit do funkce a nastavení udělat per funkce. Konfigurace session je na implementována jako zásobník. Funkce s vlastní konfigurací překryje session konfiguraci, ale po ukončení funkce (ok nebo s chybou) se aktivní konfigurace vrací zpátky na session, a to, co si nastavilo pro funkci, mizí.
Zdravím a děkuji za výborný článek. Chtěl bych se zeptat autora z čeho čerpá věta "...PostgreSQL.. se začíná postupně a úspěšně nasazovat i v korporátním prostředí".
PostgeSQL fandím, ale že bych někde viděl jeho pronikání do velkých firem, tak to jsem zatím nepotkal. Stále (dle mých zkušeností) je to databáze vnímaná spíše pro geeky - firmy sáhnou nejčastěji po SQL Serveru nebo Oracle a pokud není důvod investovat do těchto dvou, pak jako free řešení se vybere MySQL(MariaDB).
Díky za reakci.
Oracle umírá, cenová politika je totiž extrémně nepřátelská. Ve firmě například nemůžete mít server bez supportu. Buď platíte všechno nebo porušujete podmínky. Pokud máte desítky serverů, nemůžete prostě nějaké neplatit.
PostgreSQL s PostGISem je dostačující náhrada a dle zkušeností výkon je cca shodný. Funkcionalita je dneska už docela nepodstatná, pokud si přivyknete na NoSQL a nějakou integraci mezi tím vším dohromady. Vlastně se vám začne celý ten SQL koncept zdát zbytečně nafouklý a extrémní. Raději méně funkcí a opravdu kvalitně a to rozhodně není připad Oracle, kde je snad vše nějak zabugované nebo v legacy stavu.
Neumírá. Jen změnili obchodní strategii. Místo více firem platících velké peníze se zaměřují na méně firem platících nehorázně velké peníze. Důvod je právě ten, co píšete - na takové to "domácí žvýkání" mají velkou konkurenci, která je i po započtení nákladů na impelementaci a support výrazně levnější. Většina původních zákazníků už dnes prostě Oracle nepotřebuje a používají ho už jen ze setrvačnosti nebo kvůli vendor locku.
Proto se zaměřují na tu špičku ledovce, které nabízí špičkové technologie. Za obrovské peníze. Drtivá většina firem pro věci jako je Multitenant, In Memory apod. nemá žádné využití. Pár jich ale pro to využití má a mohou si dovolit si za to připlatit.
Doby, kdy typickým zákazníkem Oracle byla střední fabrika s 200 lidmi a 20 uživateli, je pryč. Tihle se přesouvají k levnějším věcem jako MS SQL.
Mimochodem, na co potřebujete desítky produkčních serverů? Pokud nejsou plně vytížené, pak je zajímavý třebas právě ten Multitenant - sice je to za příplatek a jen pro Enterprise edici, ale umožní vám to v jedné instanci (a tudíž za jedny peníze) provozovat až 253 databází.
I kdyz uz me Oracle zivi pomerne dlouho tak musim rict, ze to s nim jde pekne z kopce. Pomalu a jiste. Pro male zakazniky to neni a tech velkych je malo. Pribyvaji nove funkce, o ktere vice-mene nikdo nestoji a stare problemy zustavaji. Pokud jste velka korporace u kupujete uz hotovy SW, tak ten zcela urcite nebude vyzadovat zadnou extra cost option, takze pro veci jako In-memory neni pouziti. A pokud jste velka koroporace a vyvijite si SW sami, tak zase nedate programatorum prava, aby si takovou vec jako In-memory vubec vyzkouseli.
Navic diky tomu, ze ty nove technologie pouziva tak malo zakazniku, tak muzete narazit na ruzne chyby anebo limity o kterych jste na zacatku nemeli tuseni.
Oracle se pouziva hlavne ze setrvacnosti, a taky kvuli slevam. Ono je to na prvni pohled nepochpoitelne pro nekoho kdo to vidi z venku. Korporace chteji platit za support a nakonec jim vyjde, ze MySQL, Mongo, EnterpriseDB jsou vlastne velice drahe v porovnani s tim kolik stoji support Oracle po vsech slevach.
Pro zajímavost - naše společnost vyvíjí a implementuje obchodní skladové a pokladní systémy, PostgreSQL nasazujeme v drtivé většině centrálních i filiálkových modulů pro větší obchodní řetězce včetně 100+ prodejen, ke dnešku to dělá 120 obchodních centrál s téměř 5000 pokladních míst rychloobrátkových prodejen (5000-30000 položek sortimentu).
P.V.A. systems s.r.o.
Česká spořitelna se použití Postgresu přihlásila veřejně - další nemohu jmenovat, ale většina zbývajících bank uvažuje o použití (případně už migruje) PostgreSQL. Samozřejmě, že nikdo nečeká, a já to neříkám, že se migrují kritické služby nebo petabajtové warehouses. Nicméně už to, že mají Postgres ve svém podporovaném stacku něco znamená. Někam se Postgres dostane díky PostGISu, jinam díky Jiře, Confluence. Někde se používá kombinace - Oracle, Postgres. Oracle jako primární databáze - bo je to Oracle, kvůli aplikacím a certifikacím, a Postgres jako sekundární (pro analýzy, a ostatní věci), kvůli 0 nákladům na CPU.
Jinak ta věta čerpá z mé zkušenosti - kde jsem za poslední rok školil a konzultoval.
Zrovna před chvilkou jsme tady (jedna z největších a nejprestižnější firem v zemi, ne v ČR) měli oznámení nové Database Strategy. Otevřeně tam přiznali že Oracle EE, který zde byl dlouhá léta jedinou volbou, je tak drahý že se na většinu nasazené nevyplatí a novou výchozí volbou je PostgreSQL. Ideálně jako RDS v AWS kde je ta celá služba spravovaná Amazonem, prostě se zapne a není k tomu potřeba mít armádu DBAs.
Samozřejmě přechod z Oraclu "jak se to dělalo před 10 lety" na PostgreSQL to s sebou nese pár změn. Např. doporučení odstranit business logiku z DB a vrátit ji do aplikace. Ne že by to v Pg nešlo, ale DB má být jen pro data, čímž se usnadní budoucí migrace.
Dál třeba princip Jedna databáze = Jedna aplikace, tzn konec masivních databází ke kterým porůznu přistupovaly různé firemní aplikace a při upgradu bylo potřeba vypnout půlku firmy. Místo toho samozřejmě používat pro přístup k datům APIs, atd.
Do 6 let chtějí omezit Oracle na naprosté minimum a používat ho jen tam kde objektivně není jiná možnost. Ale např. všechny interně vyvíjené systémy musí migrovat z Oracle pryč.
A to je firma která platí skoro 200 Oracle EE licencí, žádný maličký startup.
Ono na tom není nic šokujícího a nesouvisí to jen s databází, ty staré monolitické systémy se prostě ukázaly jako neudržitelné. Drahé, obtížně škálovatelné - navíc všechno propojit přes API je již taky letitá věc tak minimálně 15 let zpět. Takže to mělo být mrtvé již dávno. Odstranění logiky z databází může také mít pozitivní vliv při používání NoSQL na nějaké archivační / analytické úlohy.
Oracle zůstane prostě tam, kde není zbytí a nové úlohy se už pod něj pravděpodobně dělat nebudou. Navíc to není cluster (parodii RAC nepočítám). Takže je to vlastně úplně mrtvé.
jenom bych se zeptal jako uplny laik, existuje (existovala v minulosti) nejaka zakladni sql databaze ktera umi asi tak 1/1000 moznosti co maji stavajici sql databaze ?
chtel pro zacinat na necem uplne primitivnim, predpoklada ze jako u ostatnich aplikaci aplikace z roku 1990 toho umeli oproti dnesnim asi tak tu jednu tisicinu coz by mi vyhovovalo ..
To je blbost. Zacni normalne na Postgresu, je to jednoducha, kvalitni, standardni databaze s dobrou podporou ANSI SQL.
Zadne advanced veci delat nemusis, pokud nechces. Instalace je jednoducha, spusteni klienta taky.
A muzes na nem bez problemu pouzivat zakladni ANSI SQL prikazy uplne v pohode a postupne se ucit.
Jak píše Kraxna, doporučil bych PostgreSQL. Těch rozšířených možností si nemusí všímat, ale ten základ je standardní SQL. Různé jednoduché databáze často mají spoustu nestandardních vlastností, takže je obvykle těžší na pochopení, jak vlastně SQL databáze fungují (protože neřešíte, jak něco udělat s prostředky SQL, ale s omezenými prostředky dané databáze); zároveň se na nich člověk často naučí různé zlozvyky.
To je dost zvláštní dotaz. Asi jako "existuje auto, co má asi tak 1/1000 možností, co má Škoda Superb?"
Neexistuje. Všechna jezdí. Neumí toho o moc víc a neumí toho ani o moc méně.
A na čem začít strašně moc záleží na tom, co vlastně chcete dělat a co se chcete učit:
- Pokud SQL, pak prakticky vše podporuje nějakou verzi ANSI SQL - pak volte podle toho, co zvládnete nainstalovat a spustit.
- Pokud správu databáze, tak to se dost zásadně liší a zkušenosti s Oracle nepoužijete na MS SQL apod.
- Pokud se chcete učit jen základy práce s databází, tak na to je dobrý i pitomý MS Access. Ten je sice spíš "databáze" než databáze, ale díky VBA a grafickým nástrojům se v tom dá splácat celá aplikace (byť některé věci jsou tam úplně na zvracení, například automatický save).
- Pokud se chcete učit matematiku a logiku spojenou s databázemi (relace, normalizace apod.), pak funguje v zásadě kde co. Já mám na tohle dobré zkušenosti s Oracle, ale neumím si představit, proč by MS SQL nebo PostgreSQL měly být jiné. Většinu práce stejně budete dělat tužkou na papír.
- Pokud vytvářet databázové aplikace, tak tam je háček v tom, že dnes se databázové aplikace občas vytvářejí bez databází. Ve chvíli, kdy prostě použijete ORM nebo nějaký podobný přístup, tak je najednou úplně ukradené, co máte za databázi.
Mé doporučení by bylo, že čistě na hraní si je dobrý Oracle XE. Na plácání aplikací stylu "databáze klientů" je MS Access. Pokud z toho chcete časem zkusit udělat něco webového, tak MySQL. Pokud chcete udělat něco ne čistě webového, tak PostgreSQL. Pokud se chcete naučit něco do životopisu, tak MS SQL. Pokud jen uvažujete o tom, že by si vaše aplikace data místo do .csv, .xml apod. ukládala data do databáze, tak koukněte po SQLite.
diky za obsahlou odpoved no asi skoncim u toho MS Access (nebyl by pro me nize uvedene potreby jednodussi winbase 602 nebo to co je v LibreOffice ?)
ambice jako domaci user bych mel neco co mozna nejjednodussiho co by se uvnitr chovalo jako db ale byla to vlastne desktopova app kam se z jedny strany strci rucne nejaky data a z druhy vypadne po jednoduchem dotazu nejaky vysledek
proto mne treba zajimalo jestli bych se si nemel obstarat firebird (nejakou uplne prvni verzi), nebo neexistuje nejaka podobna app postavena na sqlite, nebo se podivat po nejakem abandonware, preci jen Oracle 1985 pod DOSem asi mel mene funkci coz by mi vyhovovalo
alternativne pak jestli by mym zamerum nevyhovoval FileMaker (mam mj. starsi macbook pro)
pak je taky moznost ze nejlepsi db na trhu je Excel :)
Nedávno jsem narazil na https://github.com/harelba/q/ - SQL over CSV, vyzkoušené to nemám.
Dobrý článek.
Procedurám se většinou kvůli výkonu snažím vyhnout, ale musím říct, že podpora Pythonu v Postgresu se mi již párkrát hodila. Díky jeho univerzálnosti lze dotazy jednoduše rozšířit o téměř cokoliv, kvůli čemu bych jinak musel psát mnohem složitejší program. Hodilo se to na prototypování analýz, malou procedurou lze dosáhnout zajímavé transformace a člověku to dost ušetří čas - nechá chvíli chroupat Posgres místo aby strávil mnohem delší dobu psaním komplikovanějšího kódu.
V Gentoo je beta k dispozici:
[I] dev-db/postgresql
Available versions:
(9.3) 9.3.22 (~)9.3.23 (~)9.3.23[1]
(9.4) 9.4.17 (~)9.4.18 (~)9.4.18[1]
(9.5) 9.5.12 (~)9.5.13 (~)9.5.13[1]
(9.6) 9.6.8 (~)9.6.9 (~)9.6.9[1]
(10) 10.3 (~)10.4 (~)10.4[1]
(11) m11_beta1 m11_beta1[1] **9999
(12) **9999[1]
{doc kerberos ldap libressl nls pam perl -pg_legacytimestamp python +readline selinux +server ssl static-libs systemd tcl threads uuid xml zlib ELIBC="FreeBSD NetBSD OpenBSD glibc musl uclibc" KERNEL="linux" PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6" PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
Installed versions: 10.4(10)1(doc kerberos ldap nls pam readline server ssl tcl threads uuid xml zlib -libressl -perl -python -selinux -static-libs -systemd ELIBC="glibc -FreeBSD -NetBSD -OpenBSD -musl -uclibc" KERNEL="linux" PYTHON_SINGLE_TARGET="python3_5 -python2_7 -python3_4 -python3_6" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6")
Homepage: http://www.postgresql.org/
Description: PostgreSQL RDBMS