.jpg)
.
Én erre az eszközre esküszöm: SqlDbx
Értékelésem:
+ Van free personal edition belőle (igaz erősen butított)
+ Egyetlen pici 2+ MB-os exe (C-ben írva), azaz maximálisan portable alapból.
+ Létezik x86 és x64-re egyaránt
+ Leggyorsabb, legnatívabb adatelérés és adatmegjelenítés
+ Letisztult puritán felület, "mindent a gyorsaságért" jegyében.
+ A legspécibb Cassandrát, Hive-ot, egzotikumokat támogatja
+ Amire nincs ODBC, az kávzi nem is létezik. :)
+ A drága pl.: DataDirectes eszközöket is jól támogatja.
+ Scriptelhető, parancssorból vezérelhető
+ Excel és egyéb exportok
+ Visual Diff
+ SQL-formatter
+ ResultGrid kereshető
+ Intelligens Editor
+ Tökéletes script-generálások
+ A másik szimpi tool (Advanced Query Tool) azért vesztett evvel az SqlDbx-szel szemben, mert (sokkal) lassabb volt.
- A fizetős licence: 300 USD (commercial kategóriában nem kibírhatatlan)
- Egy dolgot nem tud ODBC2JDBC gateway-t
2014. szeptember 14., vasárnap
Greenplum-client for Windows
.
Falak omlanak le, mítoszok dőlnek meg, paradigmaváltás szemtanui lehetünk. :)
Régen "kikezdhetetlen" igazság volt, hogy valós enterprise környezetbe Oracle kell, aminek meg is lett az eredménye, hogy az RDBMS-tortából az Oracle mindig is valami hihetetlen nagy szeletet volt képes kihasítani.
2001-ben:
Oracle: 46%
IBM: 23.6%
Microsoft:: 6.7%
2008-ban, Gartner mérés szerint (több is lehetett, ezért nem 100% az összeg):
Oracle Database: 70%
Microsoft SQL Server: 68%
MySQL (Oracle Corporation): 50%
IBM DB2: 39%
IBM Informix: 18%
SAP Sybase Adaptive Server Enterprise: 15%
SAP Sybase IQ: 14%
Teradata: 11%
2014-ben:
"13% run Hadoop, either in pilot (8%) or production (5%). An additional 21% are considering"
Ami korábban elképzelhetetlen volt (számomra legalábbis): egy amerikai multi cég komplett iparága most akarja áttenni háromféle(!), 10+(!) ERP-jének analitikus platformját (100%-ban vegytiszta Oracle-ről) egyrészt olcsó tömegtárolású Apache Hadoop-ra, másrészt kritikus tárolású adatait Greenplumra. Egy Hawq-ra még nem "értek meg", de ez is csak idő kérdése. :). Mindezt a költségoptimalizálás jegyében..
És, ha mindez még nem lenne elég, akkor a következő még nagyobb "mélyütés" a témában:
- Ugyanez a cég úgy tervezi kidobni meglévő Informatica folyamatait, hogy még csak nem is egy Talendet helyez fókuszba (ami mára enterprise verzióban nagyon drága lett, ha jól tudom kb. negyede egy Informaticának, ami azért nem semmi)
- Hanem egyenesen vissza akar térni a régi SQL-es vagy a modern trendi open source SQOOP-ra. Ezt a nagy-nagy örömhírt (számomra visszaigazolást) napok óta sikertelenül próbálom megemészteni. Én világéletemben nagy ellensége voltam ugyanis az indokolatlanul brutáldárga ETL-GUI-knak, azóta, hogy Oracle Warehouse Builder 2.1-gyel beléptem ebbe a világba (is). (Azon az alapon, hogy én szakmai alapon vitatom, hogy elvileg lehetséges lenne jó eszközt fejleszteni, nemhogy gyakorlatilag).
Nagyon drukkolok, hogy az ilyen dolgokból trend legyen. ;)
És sikerült rátalálni egy nagyon jó eszközre, egy élmény vele dolgozni.
Falak omlanak le, mítoszok dőlnek meg, paradigmaváltás szemtanui lehetünk. :)
Régen "kikezdhetetlen" igazság volt, hogy valós enterprise környezetbe Oracle kell, aminek meg is lett az eredménye, hogy az RDBMS-tortából az Oracle mindig is valami hihetetlen nagy szeletet volt képes kihasítani.
2001-ben:
Oracle: 46%
IBM: 23.6%
Microsoft:: 6.7%
2008-ban, Gartner mérés szerint (több is lehetett, ezért nem 100% az összeg):
Oracle Database: 70%
Microsoft SQL Server: 68%
MySQL (Oracle Corporation): 50%
IBM DB2: 39%
IBM Informix: 18%
SAP Sybase Adaptive Server Enterprise: 15%
SAP Sybase IQ: 14%
Teradata: 11%
"13% run Hadoop, either in pilot (8%) or production (5%). An additional 21% are considering"
Ami korábban elképzelhetetlen volt (számomra legalábbis): egy amerikai multi cég komplett iparága most akarja áttenni háromféle(!), 10+(!) ERP-jének analitikus platformját (100%-ban vegytiszta Oracle-ről) egyrészt olcsó tömegtárolású Apache Hadoop-ra, másrészt kritikus tárolású adatait Greenplumra. Egy Hawq-ra még nem "értek meg", de ez is csak idő kérdése. :). Mindezt a költségoptimalizálás jegyében..
És, ha mindez még nem lenne elég, akkor a következő még nagyobb "mélyütés" a témában:
- Ugyanez a cég úgy tervezi kidobni meglévő Informatica folyamatait, hogy még csak nem is egy Talendet helyez fókuszba (ami mára enterprise verzióban nagyon drága lett, ha jól tudom kb. negyede egy Informaticának, ami azért nem semmi)
- Hanem egyenesen vissza akar térni a régi SQL-es vagy a modern trendi open source SQOOP-ra. Ezt a nagy-nagy örömhírt (számomra visszaigazolást) napok óta sikertelenül próbálom megemészteni. Én világéletemben nagy ellensége voltam ugyanis az indokolatlanul brutáldárga ETL-GUI-knak, azóta, hogy Oracle Warehouse Builder 2.1-gyel beléptem ebbe a világba (is). (Azon az alapon, hogy én szakmai alapon vitatom, hogy elvileg lehetséges lenne jó eszközt fejleszteni, nemhogy gyakorlatilag).
Nagyon drukkolok, hogy az ilyen dolgokból trend legyen. ;)
Na de vissza a blogposzt címében felvetett problémához. Szokásos "játék", új rdbms-nél, mi a legjobb eszköz című versenyben.:) A kérdés azért merül fel, mert a Greenplum egy PostgreSQL-származék, elvben kell szeressen egy free open source PgAdmin-t, de a helyzet az, hogy eleve warninggal indul csak el, de az igazán nagy baj vele, hogy fagyogat, miközben éterbe küldi a benne lévő SQL-eket (Greenplum v4.2-nél).
És sikerült rátalálni egy nagyon jó eszközre, egy élmény vele dolgozni.
Aginity Workbench
http://www.aginity.com/workbench/greenplum/
http://www.aginity.com/documentation/wb/gp/
http://www.aginity.com/workbench/greenplum/
http://www.aginity.com/documentation/wb/gp/
Értékelésem:
+ Free Community Edition(licence file-lal aktiválandó)
+ Free Community Edition(licence file-lal aktiválandó)
+ x86 + x64 platformokra is létezik.
+ Greenplum-specifikus
+ Greenplum-specifikus
+ DBA+SQL-fejlesztés támogatása
+ Natív adatelérés
+ Nem JAVA-s a GUI, hanem ez is natív C/C++-os(?), hálistennek.
+ Nagyon szép, gyors és egészséges használni.
+ Baromi gyors.
+ Natív adatelérés
+ Nem JAVA-s a GUI, hanem ez is natív C/C++-os(?), hálistennek.
+ Nagyon szép, gyors és egészséges használni.
+ Baromi gyors.
- gmail-es cím nem elég a hozzájutáshoz, kell egy valódi munkahelyi.
- nem minden script-generálás megy jól (de javíthatók).
Ami toolokat én találtam még:
- Aqua Data Studio (fizetős)
- EMS (fizetős)
- Navicat (fizetős)
- RazorSQL (fizetős, jdbc-s)
Ami toolokat én találtam még:
- Aqua Data Studio (fizetős)
- EMS (fizetős)
- Navicat (fizetős)
- RazorSQL (fizetős, jdbc-s)
-SqlWorkbenchJ (free, jdbc-s, egyszerűbb SQL-re jó, stabilitási "kihívásai" vannak neki)
2014. szeptember 3., szerda
Oracle Reports RDF-file migrálása
.
Az alábbiakban egy gyors, rövid, habkönnyű morgolódás fog következni, aminek tárgya vélhetőleg és szerencsére kevés BI-ban mozgó embert érint, viszont annál bosszantóbb.
Létezik az Oracle Corporation termék-portfóliójában egy cucc: Forms and Reports.
Jellemzők:
- tejútrendszer-méretű ipari hulladék maga a szoftver, éremesélyesként indul a "világ legrosszabb szoftvere" versenyben. Úgy volt elképesztően drága, hogy architektúrálisan, használhatóságilag teljesen félretervezett volt (szvsz).
- Oracle saját fejlesztése volt, nem akvirálta (nem néztem utána, csak így emlékszem), az OWB-hez hasonlóan egyébként, az is nevezetes saját fejlesztés volt, ott is nagyon komoly visszás történésekkel.
- Ehibázott mivolta ellenére rengetegen használták, és ami külön érdekes Magyarországon is.
- Nagyon nem mindegy az RDF verziószáma (nem átjárhatók).
Feladat:
Oracle Riports-os RDF file-t migráljunk valamely "korszerű" - jah pardon rossz szót használtam, mondjuk úgy inkább, hogy aktuálisan fejlesztett ;) - BI-eszközbe.
RDF file jellemzői
- Bináris hulladék, de érdekes módon a közepén van olvasható, ezáltal kimásolható SQL
- Sokféle (pl.: szerializált) RDF file van (Google-ben önmagában nem érdemes keresni tehát). A mi esetünkben egy spéci Oracle Riports Definition File-ról beszélünk.
- Van benne SQL, kliens/szerver-oldali PlSql, prezentációs réteg infói.
RDF-migrálás alternatívái:
(1) További tool igénybevétele nélkül, egyszerűbb SQL-es (értsd egyébként helyes elv alapján perdöntően szerver-oldali SQL-re támaszkodó üzleti logikájú) riportok RDF alapján is migrálható, amennyiben van screenshot, meg egy Excel-kimenet, reprezentatív adatmintával.
(2) Ha valaki precízen akar hozzáférni az RDF-hez, akkor innentől kettéágazik az út.Oracle-felé akarja venni a migrációs utat, avagy más frissebb, jobb, használhatóbb alternatívák felé (pl.: Tableau)
(2a) Az Oracle út minden finomkodás nélkül bátran minősíthető botrányosnak.
Egyfelöl az Oracle BI Enterprise (talán a Siebeltől vették meg) már megvásárlásakor, egy ultradrága, barátságtalan, nehezen adminsiztrálható, gigantikus overhead-es, elavult eszköz volt. Ezt választani korszerű BI-platformnak monumentális pénzkidobás, fékezett habzású élménnyel. (szvsz).
Másfelöl botrányos azért, mert az elterjedt Oracle Reports RDF támogatását gyalázatosan oldották meg. Noha egy egyszerű feladatról lenne szó, egy bitre ismert internal file-t kiexportálni valami olvasható formátumra.
- Oracle BI Publisher gyári prezi alapján például 11g-be meg sem írták a konverziót.
- Rengeteg terméknév/verzió van közkézen, ember legyen a talpán, aki követni tudja miből, mikor mi lett a nagy akviziciók utáni termékintegrálás után.Melyiknek milyen install-követelményei / előfeltételei, meg lehetőségei vannak. Noha - ismétlem - csak egy egyszerű RDF-file infóihoz szeretnénk hozzáférni.
- Oracle BI Publisher tehát kiesik, 11g alapból, 10g azért, mert nem installható korszerű Win7/Win8 alá korrekten.
- Oracle BI Enterprise 11g-vel azért nem érdemes kísérletezni, mert alapból 3-4 GB az installkit, de kell neki Fusion Middleware, meg Bealogic Webserver maga alá. E nélkül el sem indul az install.
- Vannak olyan verziók, amik megkövetelik a szerver-oprendszert
- Ami megy mondjuk Win XP alatt, de hivatalosan nem támogatta még a Win7-et például, az jellemzően nem is megy Win7 alatt: már az install sem.
Összefoglalva, lehet küzdeni, meg jó sok munkaórát beleölni az RDF-migrálásba, csak kérdés érdemes-e. Az én véleményem az, hogy a legegyszerűbb és legolcsóbb megoldás, úgy tekinteni az RDF-re, mint ha nem Oracle-eredetű lenne, lásd (2b)-t, XML-t kell belőle csinálni és aztán intenzíven elfelejteni az egész Oracle BI-vonalat.
(2b) Amennyiben nem Oracle a migrálási célplatform, akkor a legegyszerübb megoldás XP-s virtuális gép, 10-es 11-es Oracle Dev Suite install (complete-t, amiben benne van a Forms and Reports), ezek még baráti méretű 1 GB-os install anyagok, ráadásul gond nélkül felmennek. Aztán rwconverter-rel vagy Reports IDE-ből lementeni a szükséges infókat, aztán lehet koncentrálni a jövőbeli BI-fejlesztésekre.
Két hasznos link:
RDF-to-BI Publisher Conversion Utility (2012-01)
Steps to convert RDF into BI (2012-05)
Szoktuk mondani beszállítóként, hogy "az ügyfél minden elött". Egy Oracle megavendor képes volt minden szakmailag és emberileg elvárható minimum-követelménnyel szembemenve kiszolgáltatni (1)hűséges, (2) sok pénzt fizetű (3) nagyméretű ügyfélbázisát ilyen léptékben, a nagy akviziciók és integrációk nyomán.
Lássuk be: nem kicsit szomorú.
Az alábbiakban egy gyors, rövid, habkönnyű morgolódás fog következni, aminek tárgya vélhetőleg és szerencsére kevés BI-ban mozgó embert érint, viszont annál bosszantóbb.
Létezik az Oracle Corporation termék-portfóliójában egy cucc: Forms and Reports.
Jellemzők:
- tejútrendszer-méretű ipari hulladék maga a szoftver, éremesélyesként indul a "világ legrosszabb szoftvere" versenyben. Úgy volt elképesztően drága, hogy architektúrálisan, használhatóságilag teljesen félretervezett volt (szvsz).
- Oracle saját fejlesztése volt, nem akvirálta (nem néztem utána, csak így emlékszem), az OWB-hez hasonlóan egyébként, az is nevezetes saját fejlesztés volt, ott is nagyon komoly visszás történésekkel.
- Ehibázott mivolta ellenére rengetegen használták, és ami külön érdekes Magyarországon is.
- Nagyon nem mindegy az RDF verziószáma (nem átjárhatók).
Feladat:
Oracle Riports-os RDF file-t migráljunk valamely "korszerű" - jah pardon rossz szót használtam, mondjuk úgy inkább, hogy aktuálisan fejlesztett ;) - BI-eszközbe.
RDF file jellemzői
- Bináris hulladék, de érdekes módon a közepén van olvasható, ezáltal kimásolható SQL
- Sokféle (pl.: szerializált) RDF file van (Google-ben önmagában nem érdemes keresni tehát). A mi esetünkben egy spéci Oracle Riports Definition File-ról beszélünk.
- Van benne SQL, kliens/szerver-oldali PlSql, prezentációs réteg infói.
RDF-migrálás alternatívái:
(1) További tool igénybevétele nélkül, egyszerűbb SQL-es (értsd egyébként helyes elv alapján perdöntően szerver-oldali SQL-re támaszkodó üzleti logikájú) riportok RDF alapján is migrálható, amennyiben van screenshot, meg egy Excel-kimenet, reprezentatív adatmintával.
(2) Ha valaki precízen akar hozzáférni az RDF-hez, akkor innentől kettéágazik az út.Oracle-felé akarja venni a migrációs utat, avagy más frissebb, jobb, használhatóbb alternatívák felé (pl.: Tableau)
(2a) Az Oracle út minden finomkodás nélkül bátran minősíthető botrányosnak.
Egyfelöl az Oracle BI Enterprise (talán a Siebeltől vették meg) már megvásárlásakor, egy ultradrága, barátságtalan, nehezen adminsiztrálható, gigantikus overhead-es, elavult eszköz volt. Ezt választani korszerű BI-platformnak monumentális pénzkidobás, fékezett habzású élménnyel. (szvsz).
Másfelöl botrányos azért, mert az elterjedt Oracle Reports RDF támogatását gyalázatosan oldották meg. Noha egy egyszerű feladatról lenne szó, egy bitre ismert internal file-t kiexportálni valami olvasható formátumra.
- Oracle BI Publisher gyári prezi alapján például 11g-be meg sem írták a konverziót.
- Rengeteg terméknév/verzió van közkézen, ember legyen a talpán, aki követni tudja miből, mikor mi lett a nagy akviziciók utáni termékintegrálás után.Melyiknek milyen install-követelményei / előfeltételei, meg lehetőségei vannak. Noha - ismétlem - csak egy egyszerű RDF-file infóihoz szeretnénk hozzáférni.
- Oracle BI Publisher tehát kiesik, 11g alapból, 10g azért, mert nem installható korszerű Win7/Win8 alá korrekten.
- Oracle BI Enterprise 11g-vel azért nem érdemes kísérletezni, mert alapból 3-4 GB az installkit, de kell neki Fusion Middleware, meg Bealogic Webserver maga alá. E nélkül el sem indul az install.
- Vannak olyan verziók, amik megkövetelik a szerver-oprendszert
- Ami megy mondjuk Win XP alatt, de hivatalosan nem támogatta még a Win7-et például, az jellemzően nem is megy Win7 alatt: már az install sem.
Összefoglalva, lehet küzdeni, meg jó sok munkaórát beleölni az RDF-migrálásba, csak kérdés érdemes-e. Az én véleményem az, hogy a legegyszerűbb és legolcsóbb megoldás, úgy tekinteni az RDF-re, mint ha nem Oracle-eredetű lenne, lásd (2b)-t, XML-t kell belőle csinálni és aztán intenzíven elfelejteni az egész Oracle BI-vonalat.
(2b) Amennyiben nem Oracle a migrálási célplatform, akkor a legegyszerübb megoldás XP-s virtuális gép, 10-es 11-es Oracle Dev Suite install (complete-t, amiben benne van a Forms and Reports), ezek még baráti méretű 1 GB-os install anyagok, ráadásul gond nélkül felmennek. Aztán rwconverter-rel vagy Reports IDE-ből lementeni a szükséges infókat, aztán lehet koncentrálni a jövőbeli BI-fejlesztésekre.
Két hasznos link:
RDF-to-BI Publisher Conversion Utility (2012-01)
Steps to convert RDF into BI (2012-05)
Szoktuk mondani beszállítóként, hogy "az ügyfél minden elött". Egy Oracle megavendor képes volt minden szakmailag és emberileg elvárható minimum-követelménnyel szembemenve kiszolgáltatni (1)hűséges, (2) sok pénzt fizetű (3) nagyméretű ügyfélbázisát ilyen léptékben, a nagy akviziciók és integrációk nyomán.
Lássuk be: nem kicsit szomorú.
Feliratkozás:
Bejegyzések (Atom)
Bejegyzések
