Достъп до непублична схема в PostgreSQL с Pentaho

Нека започна с това, че това, което знам за Пентахо, няма да запълни нито един абзац. По-запознат съм с PostgreSQL. Работя с някои изпълнители, които изграждат набор от месечни отчети в Pentaho (v. 4.5) за моята компания. Някои от данните трябва да преминат през ETL процес и да бъдат събрани за целите на отчитането. От гледна точка на dba(ish), бих искал да преместя тези таблици в отделна схема на PostgreSQL.

Знам, че Pentaho често се използва с MySQL (който няма схеми) и се притеснявам, че това може да създаде проблеми. Направих малко "гугъл" и не намирам много посещения по темата, но намерих затворен бъг отпреди няколко години - което означава, че функционалността трябва да се поддържа.

преди да направя това, бих искал да видя дали някой знае причина това да се провали или да е лоша идея. (или ако сте го направили и работи чудесно, моля, уведомете ме и за това).

Последни бележки: Използвам PostgreSQL 9.1.5 и нямам достъп до екземпляр на Pentaho, за да тествам това дори сам. И се надявам, че добрите хора в общността на Stackoverflow ще споделят своя опит и ще ме спестят от необходимостта да инсталирам такъв, а часовете игра/тестване, за да добия представа за това, е лоша идея.

РЕДАКТИРАНЕ:

Знаех, че този въпрос е малко неясен, но се надявах, че някой ще го прочете и ще сподели опита си. И така, позволете ми да го опиша по-ясно и да задам по-изрични въпроси.

Аз не съм направил нищо. Не познавам Пентахо. Не искам да уча Pentaho (не че има нещо лошо в Pentaho... Просто не е там, където са моите интереси в момента). Фирмата ми нае изпълнители (не съм ги наел). Имат опит с Pentaho, но с MySQL. Те всъщност не знаят нищо за PostgreSQL. Има някои важни разлики между PostgreSQL и MySQL. Включително факта, че PostgreSQL поддържа схеми (докато MySQL използва отделна база данни... подобни по концепция може да се държат различно по някои начини). Някои ORM (и инструменти) наистина не харесват това... например рамката Django все още не поддържа напълно схеми в Postgresql (знам това, защото често използвам Python и Django и животът ми е много по-добър, когато държа нещата в „обществената“ схема). Поради моя опит със схемите на Django и PostgreSQL, съм малко подозрителен относно преместването на тези данни в нова схема.

Разбирам, че където и да са таблиците, те ще имат нужда от разрешения, за да имат достъп до данните.

Моите изрични въпроси:

  • Използвате ли Pentaho за достъп до база данни на PostgreSQL за достъп до таблици в схеми, различни от „публични“ (по подразбиране).
  • Ако е така, просто работи ли (няма проблеми)?
  • Ако сте имали проблеми, бихте ли споделили с мен (и общността на Stackoverflow) онлайн ресурси, които са ви помогнали? Или бихте искали да опишете подробно какво си спомняте тук?
  • Знаете ли за нещо, което просто няма да работи правилно? Например открита грешка в Pentaho, свързана с тази тема.

Отново, това не е вашият стандартен вид въпрос. Надявам се, че някой има опит и е готов да го сподели тук и да ме спаси от необходимостта да губя време в настройка на нов екземпляр на Pentaho и в опити да науча Pentaho достатъчно добре, за да го тествам и т.н.

Благодаря.


person David S    schedule 22.10.2012    source източник
comment
Съжалявам, не разбирам. Какъв точно е вашият въпрос?   -  person a_horse_with_no_name    schedule 22.10.2012
comment
@a_horse_with_no_name ... Мислех, че го направих доста ясно. И цитирам: преди да направя това, бих искал да видя дали някой знае причина това да се провали или да е лоша идея. (или ако сте го направили и работи чудесно, моля, уведомете ме и за това).   -  person David S    schedule 22.10.2012
comment
какво пробвахте Създадохте ли нова схема, копирахте ли някои таблици в нея и опитахте ли да изпълните отчети срещу тези таблици? Какво се случи, когато направи това? Някакви съобщения за грешка? Освен това под непублична имате предвид схема, която е наречена нещо различно от публична, или имате предвид схема, наречена нещо различно от публична, която има ограничени разрешения?   -  person Mike Sherrill 'Cat Recall'    schedule 22.10.2012
comment
@Catcall. Моля, вижте моите редакции. Благодаря.   -  person David S    schedule 23.10.2012


Отговори (4)


Стъпките на Pentaho (входове, изходи на таблици и т.н.) обикновено ви позволяват да посочите схема на база данни.

Направих бърз тест с помощта на PDI и нашия екземпляр на Postgres 8.4 и успях да изследвам, чета от и записвам в таблици в различни схеми.

Така че мисля, че това е разумна посока. Надявам се това да помогне.

person FremenFreedom    schedule 22.10.2012
comment
Благодаря ви много за отговора! - person David S; 23.10.2012
comment
@David S: Няма проблем. Не съм много запознат с последиците от използването на различните драйвери на Postgres JDBC във версиите, но текущата версия на инструментите за проектиране Pentaho се доставя с драйвери 8.4. Може да не е проблем или вашите изпълнители може да са актуализирали, но реших да го спомена. - person FremenFreedom; 23.10.2012
comment
Добър съвет. Ще го имам предвид. Благодаря отново за помощта. - person David S; 23.10.2012

Два пътя, по които можете да поемете:

1) Какво каза предишната публикация („Стъпките на Pentaho (входящи данни, изходи и т.н.) обикновено ви позволяват да посочите схема на база данни.“)

2) Във връзка с база данни, разширен раздел, „Предпочитаното име на схема“.

Ако работите с различни схеми, можете да създадете по една връзка към база данни за всяка схема. С този подход можете да оставите полето на схемата в стъпките за вход/изход празно.

person Milos    schedule 30.10.2012

Използваме MS SQL сървър и мога да ви кажа, че Pentaho се бори с идеята за схема. Много от техните приложения ви позволяват да изберете схема, но Pentaho, както казахте, е създаден да използва нещо като mySQL.

Накарайте потребителя на базата данни на pentaho да работи така, както би работил в mySQL.

Направихме потребителя на базата данни по подразбиране dbo, след което структурирахме нашите таблици като dbo.dimDimension, dbo.factFactTable и т.н. По принцип използвайте dbo само за целите на Pentaho. (Или каквато и да е схема, която искате да използвате по подразбиране.)

person Max    schedule 06.11.2012
comment
Благодаря ви много за отговора! Много се оценява. - person David S; 09.11.2012

Използвам PDI и PgSQL широко всеки ден с куп различни схеми. Работи добре. Единственият проблем, с който може да се сблъскате, е неприятната практика на Pg да принуждава идентификаторите без кавички да бъдат малки вместо главни. Скоро разбрах, че всичко е по-лесно, когато зададох свойството за разширена връзка на „Цитира всичко в базата данни“.

Да, трябва да цитирате всичко, когато пишете SQL, ако PDI не го прави вместо вас, но работи доста добре. Не съм експериментирал с принуждаване на всички идентификатори към малки букви, но очаквам, че и това ще работи.

И да, използвайте и „Предпочитано име на схема“, но имайте предвид, че някои стъпки използват тази опция, а други не. Не можете например да очаквате да добави имена на схеми към SQL, който въвеждате в стъпка за въвеждане на таблица.

Единствените други проблеми, с които може да се сблъскате, са ограниченията на JDBC драйвера на Pg. Не е толкова добър, колкото този на SQL Server или DB2, но единственото нещо, с което съм имал проблеми, беше изпращането на редове за грешка от стъпка за извеждане на таблица към друга стъпка, когато стъпката за извеждане на таблица е била в пакетен режим.

Забавлявайте се с изучаването на PDI. Това е чудесно допълнение към вашите DBA умения.

Браян

person Brian.D.Myers    schedule 21.12.2012
comment
Благодаря! Наистина оценявам отговора. Бях изкован за първоначалния въпрос (дори получих няколко гласа против - хаха). Оценявам съвета. - person David S; 22.12.2012