PL/pgSQL
HERAKLES - 09-12-2005 19:53
PL/pgSQL
Mam do przerzucenia dane z jednej bazki do drugiej (z jednego sera na drugi)
chciałbym to elegancko zrobić w plpgsql czy to się da zrobić, bo coś nie
mogę nic znaleźć w tym temacie w docu.?
Grzegorz Szyszlo - 09-12-2005 19:53
HERAKLES napisał(a):
> Mam do przerzucenia dane z jednej bazki do drugiej (z jednego sera na drugi)
> chciałbym to elegancko zrobić w plpgsql czy to się da zrobić, bo coś nie
> mogę nic znaleźć w tym temacie w docu.?
pytanie, czemu akurat tak? nie prosciej pgdump a potem psql i wciagnac
plik txt ?
znik.
HERAKLES - 09-12-2005 19:53
Grzegorz Szyszlo wrote:
> HERAKLES napisał(a):
>> Mam do przerzucenia dane z jednej bazki do drugiej (z jednego sera na
>> drugi) chciałbym to elegancko zrobić w plpgsql czy to się da zrobić, bo
>> coś nie mogę nic znaleźć w tym temacie w docu.?
>
> pytanie, czemu akurat tak? nie prosciej pgdump a potem psql i wciagnac
> plik txt ?
>
> znik.
chodzi o to: baza X zasysa sobie dane z bazy Y następnie obrabia to tak jak
lubi najbardziej i spowrotem wgrywa dane do bazy Y, elegancko by było aby
wszystko robiła baza X a nie aplikacja, bo jak to robi aplikacja to wygląda
to tak:
aplikacja Z zaciąga dane z bazy Y następnie wgrywa dane do bazy X, baza X
wykonuje to co lubi najbardziej, następnie zgrywa dane z bazy X i wgrywa
dane do bazy Y, byłoby po prostu ładniej.
Robert Grabowski - 09-12-2005 19:53
HERAKLES wrote:
[...]
> aplikacja Z zaciąga dane z bazy Y następnie wgrywa dane do bazy X, baza X
> wykonuje to co lubi najbardziej, następnie zgrywa dane z bazy X i wgrywa
> dane do bazy Y, byłoby po prostu ładniej.
dblink?
pozdrawiam
Robert Grabowski
HERAKLES - 09-12-2005 19:53
Robert Grabowski wrote:
> HERAKLES wrote:
> [...]
>> aplikacja Z zaciąga dane z bazy Y następnie wgrywa dane do bazy X, baza X
>> wykonuje to co lubi najbardziej, następnie zgrywa dane z bazy X i wgrywa
>> dane do bazy Y, byłoby po prostu ładniej.
>
> dblink?
>
> pozdrawiam
> Robert Grabowski
i tu się nasuwa kolejne pytanie: gdzie jest doc do tego, szukam w goglu i
nic?
Piotr 'piter' Hlawski - 09-12-2005 19:53
HERAKLES wrote:
> i tu się nasuwa kolejne pytanie: gdzie jest doc do tego, szukam w goglu i
> nic?
W contribie...
--
..:: Piter // phlawski@gmail.com // gg: 4534287 ::.
Nie miejcie do mnie pretensji.
HERAKLES - 09-12-2005 19:53
Piotr 'piter' Hlawski wrote:
> HERAKLES wrote:
>
>> i tu się nasuwa kolejne pytanie: gdzie jest doc do tego, szukam w goglu i
>> nic?
>
> W contribie...
>
Fajnie można bliższe wskazówki?
hubert depesz lubaczewski - 09-12-2005 19:53
Dnia 07.12.2005 HERAKLES <herakles@buziaczek.pl> napisał/a:
> Fajnie można bliższe wskazówki?
http://www.dbf.pl/faq/tresc.html?rozdzial=10#o10_30
depesz
--
*------------------------------------------------------------------*
najwspanialszą rzeczą jaką dało nam nowoczesne społeczeństwo, jest
niesamowita wręcz łatwość unikania kontaktów z nim
Grzegorz Szyszlo - 09-12-2005 19:54
HERAKLES napisał(a):
>>pytanie, czemu akurat tak? nie prosciej pgdump a potem psql i wciagnac
>>plik txt ?
>>
>>znik.
>
> chodzi o to: baza X zasysa sobie dane z bazy Y następnie obrabia to tak jak
> lubi najbardziej i spowrotem wgrywa dane do bazy Y, elegancko by było aby
> wszystko robiła baza X a nie aplikacja, bo jak to robi aplikacja to wygląda
> to tak:
> aplikacja Z zaciąga dane z bazy Y następnie wgrywa dane do bazy X, baza X
> wykonuje to co lubi najbardziej, następnie zgrywa dane z bazy X i wgrywa
> dane do bazy Y, byłoby po prostu ładniej.
No i masz problem. Bo baza jako taka jest w pewnym sensie głupią
składownią danych. Baza niczego ani nie zasysa, ani nie wypluwa. Jeśli
już, to aplikacja (klient) podłącza się do bazy, i zleca wyplucie
z niej danych, lub napycha bazę danymi.
Zamieszanie bierze się stąd, że zaawansowane bazy pozwalają
na wbicie w nie same nawet całej aplikacji, tyle że nie zawsze
to ma sens. poza tym trafiasz na kolejny głupawy problem,
tzn. i tak jakiś klient z zewnątrz musi zainicjować pracę
takiej aplikacji, bo baza sama z siebie czegoś takiego nie zrobi.
czasem się mówi że baza coś tam potrafi zrealizować samodzielnie,
ale jest to zazwyczaj uzupełnienie do bazy, osobny kawał kodu,
który z punktu widzenia bazy jest traktowany jak klient ;)
Nie bardzo wiem co tam chcesz robić, czy operacja ma się
odbywać manualnie, czy automatycznie zgodnie z jakimś harmonogramem.
jeśli to drugie, to czy nie prościej kawał aplikacji przerobić
na daemona i niech taki daemon sam (po dostarczeniu odpowiednich
wytycznych) decyduje kiedy się uaktywniać? albo kawałek kodu aplikacji
przepisujący dane pomiędzy bazami był odpalany po prostu z crona?
nie ma sensu wpychać do bazy czegoś, co tak naprawdę nie jest w niej
potrzebne.
zupełnie inną sprawą jest, jeśli klient podłącza się do bazy,
ale musi korzystać z danych zawartych w innej bazie, zaś
zaimplementowanie drugiego podłączenia jest z jakichś względów
nieporęczne. właśnie po to postgres ma możliwość, aby tabelki
bazy zewnętrznej, były prezentowane mniej więcej jak lokalne
tabelki bazy. z takiego połączenia mogą korzystać procedury
wbudowane. tyle że powraca poprzedni problem. procedurę
musi coś wywołać, bo sama z siebie tego nie zrobi.
znik.
HERAKLES - 09-12-2005 19:54
Grzegorz Szyszlo wrote:
> HERAKLES napisał(a):
>
>>>pytanie, czemu akurat tak? nie prosciej pgdump a potem psql i wciagnac
>>>plik txt ?
>>>
>>>znik.
>>
>> chodzi o to: baza X zasysa sobie dane z bazy Y następnie obrabia to tak
>> jak lubi najbardziej i spowrotem wgrywa dane do bazy Y, elegancko by było
>> aby wszystko robiła baza X a nie aplikacja, bo jak to robi aplikacja to
>> wygląda to tak:
>> aplikacja Z zaciąga dane z bazy Y następnie wgrywa dane do bazy X, baza X
>> wykonuje to co lubi najbardziej, następnie zgrywa dane z bazy X i wgrywa
>> dane do bazy Y, byłoby po prostu ładniej.
>
> No i masz problem. Bo baza jako taka jest w pewnym sensie głupią
> składownią danych. Baza niczego ani nie zasysa, ani nie wypluwa. Jeśli
> już, to aplikacja (klient) podłącza się do bazy, i zleca wyplucie
> z niej danych, lub napycha bazę danymi.
>
> Zamieszanie bierze się stąd, że zaawansowane bazy pozwalają
> na wbicie w nie same nawet całej aplikacji, tyle że nie zawsze
> to ma sens. poza tym trafiasz na kolejny głupawy problem,
> tzn. i tak jakiś klient z zewnątrz musi zainicjować pracę
> takiej aplikacji, bo baza sama z siebie czegoś takiego nie zrobi.
> czasem się mówi że baza coś tam potrafi zrealizować samodzielnie,
> ale jest to zazwyczaj uzupełnienie do bazy, osobny kawał kodu,
> który z punktu widzenia bazy jest traktowany jak klient ;)
>
> Nie bardzo wiem co tam chcesz robić, czy operacja ma się
> odbywać manualnie, czy automatycznie zgodnie z jakimś harmonogramem.
> jeśli to drugie, to czy nie prościej kawał aplikacji przerobić
> na daemona i niech taki daemon sam (po dostarczeniu odpowiednich
> wytycznych) decyduje kiedy się uaktywniać? albo kawałek kodu aplikacji
> przepisujący dane pomiędzy bazami był odpalany po prostu z crona?
No właśnie tak jest upchnołem wszystkie obliczenia w funkcjach nie widzę
potrzeby zasysania danych do aplikacji zresztą wcześniej robiłem to właśnie
w samej aplikacji i buło wolniej. Teraz pojawiła się potrzeba wypluwania
efektu tych obliczeń do innej bazy, jest to świetne rozwiązanie, gdyż ser
kożystający z tych dzanych wogóle nie jest obciążony, problem polega na
tym, że skoro już wszystko jest w bazie to dlaczego by nie i to wgrywanie
danych ale se darowałem i copy. Fakt jest to postgres i działając na jednym
połączeniu używam tylko jednego procka ale i tak pozostałych trzech
potrzebuję do czego innego. A to od razu pytanie, czy da się np. przypisać
jakoś połączenie(powiedzmy np. nazwą użytkownika) do konkretnego procka,
mam tam trzy fajne softy i bazkę i zależałoby mi aby każdy miał swój układ
scalony.
>
> nie ma sensu wpychać do bazy czegoś, co tak naprawdę nie jest w niej
> potrzebne.
Zgadzam się jeżeli jednak wykrywam duże przyspieszenia gdy wszystko robię w
samej bazie to czemu mam robić inaczej? a kopiowanie z bazy do bazy tak dla
czystej elegancji, bo jak już wszystko jest w bazie to niech będzie tam
wszystko.
> zupełnie inną sprawą jest, jeśli klient podłącza się do bazy,
> ale musi korzystać z danych zawartych w innej bazie, zaś
> zaimplementowanie drugiego podłączenia jest z jakichś względów
> nieporęczne. właśnie po to postgres ma możliwość, aby tabelki
> bazy zewnętrznej, były prezentowane mniej więcej jak lokalne
> tabelki bazy. z takiego połączenia mogą korzystać procedury
> wbudowane. tyle że powraca poprzedni problem. procedurę
> musi coś wywołać, bo sama z siebie tego nie zrobi.
>
> znik.
Otóż do tej pory rozwiązuje ten problem: select .. into temp ... ===>> COPY
===>>create temp table ===>> COPY ===>> ale i jest tu problem z indeksami
itd itd, nie podoba mi się to.
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle, SQL, PL/SQL. Jak =?ISO-8859-2?Q?napisa=E6_zapytanie=2C?==?ISO-8859-2?Q?_kt=F3re_zwr=F3ci_nazw=EA_atrybutu=2C_kt=F3reg o?==?ISO-8859-2?Q?_warto=B6ci_spe=B3niaj=B1_zadany_warunek?=
www.fotosearch.pl & www.fotosearch.com >> ceny
[MySQL] Jakie kodowanie aby =?ISO-8859-2?Q?by=B3y_i_pl_ogo?==?ISO-8859-2?Q?nki_i_o_z_dwoma_kropkami_nad_nim_=3F_=3B?==?IS O-8859-2?Q?=29?=
Oracle PL/SQL Wstawianie =?ISO-8859-2?Q?wynik=F3w_kolekcji_d?==?ISO-8859-2?Q?o_tabeli?=
[Oracle PL/SQL] Cursor i zapis =?ISO-8859-2?Q?rekord=F3w_do_?==?ISO-8859-2?Q?kolejnych_plik=F3w?=
MySQL + UTF8 + PL znaki - jest =?ISO-8859-2?Q?jaki=B6_logiczny?==?ISO-8859-2?Q?_spos=F3b_=3F?=
[Forum] www.forum.weeb.pl
Photoshop CS/CS PL - Biblia
[pgsql] Akcja w =?iso-8859-2?b?emFsZb9ub7ZjaQ==?= od liczby zmienionych =?iso-8859-1?q?rekord=F3w?=
[sql][pgsql] zapytanie sql
zanotowane.pldoc.pisz.plpdf.pisz.plred-hacjenda.opx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
