🚀 go-pugleaf

On Mon, 31 Aug 2015 21:05:34 +0200, MaRc wrote:

> Jakiego naprostrzego sposobu użyć do takiej rejestracji zmian w tabeli?
> 
> W postgresie muszę chyba użyć triggera, aczkolwiek nie działa on ze 
> starszymi serwerami :/

W Postgresie triggery są od dawien dawna, od co najmniej 15 lat na pewno.
 
> W mysql?

Też są, choć młodsze, od chyba wersji 5 czyli od 10 lat.

Przy czym MySQL to raczej zabawka, a PG to poważny serwer.

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

szemrany <szemrany@offline.off> napisał(a)
> Przy czym MySQL to raczej zabawka, a PG to poważny serwer.
>

Będzie jakiś flame?!

Może ja zacznę: pgAdmin jest do niczego w porównaniu z mySQL Workbench.

-- 
Tomek

On Mon, 31 Aug 2015 21:27:07 +0000 (UTC), Tomek Kańka wrote:

>> Przy czym MySQL to raczej zabawka, a PG to poważny serwer.
> 
> Będzie jakiś flame?!

Lepszy flejm niż pustynia :-)

> Może ja zacznę: pgAdmin jest do niczego w porównaniu z mySQL Workbench.

A co to ma do samego serwera, przepraszam?

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

szemrany <szemrany@offline.off> napisał(a)
> Lepszy flejm niż pustynia :-)

Tutaj się zdadzamy, więdz pomijamy temat:).

>
>> Może ja zacznę: pgAdmin jest do niczego w porównaniu z mySQL Workbench.
>
> A co to ma do samego serwera, przepraszam?
>


Bo liczy się cały ekosytem: drivery, dodatkowe bibliteki, narzedzia dla
administratorów/developerów. Bo jak tego nie ma, to próg wejścia jest
wyższy i odstrasza.

I jak odplam (codziennie) pgAdmina, to mnie nerw bierze. 
Choć możliwe, że jakbym cześciej używał mySQL to nerw byłby podobny:).
Ale jak przy robieniu jakiejś aplikacji musiałem używałeć, to ten Workbench mi nawet nie
przeszkadzał.

-- 
Tomek

On Mon, 31 Aug 2015 21:57:17 +0000 (UTC), Tomek Kańka wrote:

>>> Może ja zacznę: pgAdmin jest do niczego w porównaniu z mySQL Workbench.
>>
>> A co to ma do samego serwera, przepraszam?

> Bo liczy się cały ekosytem: drivery, dodatkowe bibliteki, narzedzia dla
> administratorów/developerów. Bo jak tego nie ma, to próg wejścia jest
> wyższy i odstrasza.
> 
> I jak odplam (codziennie) pgAdmina, to mnie nerw bierze. 
> Choć możliwe, że jakbym cześciej używał mySQL to nerw byłby podobny:).
> Ale jak przy robieniu jakiejś aplikacji musiałem używałeć, to ten Workbench mi nawet nie
> przeszkadzał.

Za "chwilę" będzie nowe narzędzie do administrowania PG odf firmy Upscene,
więc będzie ok.

A teraz serwery. Co ma MySQL czego brakuje PG? :-)

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On 2015-08-31, MaRc <tuksmr@gmail.com> wrote:
> Witam
> Potrzebuję rejestrować, a raczej zapisywać czas ostatniej zmiany w tabeli.
> Mam tabelę nodes i jeśli coś do tej tabeli zostanie dodane, updateowane 
> lub delete to by do tabeli nodes_lupdate był wpisywany timestamp.
> tabela nodes_lupdate zawiera jedynie jedną kolumnę o nazwie tstamp. chcę 
> zrobić "UPDATE nodes_lupdate set tstamp = now()" jeśli cokolwiek zmieni 
> sie w tabeli nodes. potrzebne jest mi to do generowania danych do 
> radiusa, jeśli nie było zmiany to nie ma potrzeby generowania nowej 
> konfiguracji co za tym idzie nie ma potrzeby reloadu serwera.
>
> Jakiego naprostrzego sposobu użyć do takiej rejestracji zmian w tabeli?
>
> W postgresie muszę chyba użyć triggera, aczkolwiek nie działa on ze 
> starszymi serwerami :/

Znaczy to? Znalazłeś wersję postgresa w której nie działają triggery.
Gratulacje. A teraz podziel się informacją co to za wersja, bo o ile ja
wiem, to triggery są "od zawsze".

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

Dzięki Panowie za sugestie, ale nie pytanie i wątek nie jest o wyższości 
jednego serwera nad drugim.

Wiem, że triggery w PG są od dawna, ale jak próbowałem zrobić na 8.3 to 
krzyczał, że nie można użyć jakieś funkcji, dopiero od 9.1 to działało. 
Nie pamietam dokładnie jakiej, ale nie mogłem osiągnąć tego co chciałem, 
a mianowicie wykonanie funcji przy określonych zdarzeniach.

Moje pytanie odnośnie dwóch baz spowodowane jest, że musi to działać na 
dwóch silnikach.
Podpowiecie jak to zrobić prawidłowo na tych bazach?


-- 
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a 
wówczas pobije cię swoimi argumentami.

W dniu 2015-09-01 o 10:08, MaRc pisze:
> Moje pytanie odnośnie dwóch baz spowodowane jest, że musi to działać na
> dwóch silnikach.
> Podpowiecie jak to zrobić prawidłowo na tych bazach?
>
Przecież znasz odpowiedź. Trigera do bazy może dołożyć admin. Programista 
pisał swoje, jeśli nie dodał (kto i kiedy, co) to jego wina (a powinien - bo 
wtedy dba o własną d..). Nie widzę problemu, dodaj triger na on.. delete, 
update. Struktura bazy jest twoja, logiki nie zmieniasz.


-- 
Artur

W dniu 2015-09-01 o 10:08, MaRc pisze:
> Dzięki Panowie za sugestie, ale nie pytanie i wątek nie jest o wyższości
> jednego serwera nad drugim.
>
> Wiem, że triggery w PG są od dawna, ale jak próbowałem zrobić na 8.3 to
> krzyczał, że nie można użyć jakieś funkcji, dopiero od 9.1 to działało.
> Nie pamietam dokładnie jakiej, ale nie mogłem osiągnąć tego co chciałem,
> a mianowicie wykonanie funcji przy określonych zdarzeniach.
>
> Moje pytanie odnośnie dwóch baz spowodowane jest, że musi to działać na
> dwóch silnikach.
> Podpowiecie jak to zrobić prawidłowo na tych bazach?
>
>
Po pierwsze skoro nie może użyć "jakiejś" funkcji to zastosuj "jakąś" 
inną funkcję. Szklana kula nie działa. Jak napiszesz z czym konkretnie 
masz to dostaniesz konkretną pomoc.
A tak poza tym PostgreSQL starszy niż 9.0 nie jest już wspierany i lada 
dzień (wrzesień 2015) zakończy karierę 9.0.

-- 
Pozdrawiam,
Leszek Kubrak

> Po pierwsze skoro nie może użyć "jakiejś" funkcji to zastosuj "jakąś"
> inną funkcję. Szklana kula nie działa. Jak napiszesz z czym konkretnie
> masz to dostaniesz konkretną pomoc.

Zgadza się nie szklana kula, ale teraz nie pamiętam dokładnie, ale to 
było chyba to, że nie mogłem użyć LANGUAGE plpsql.

Może jakiś exampel jak to prawidłowo zrobić?


-- 
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a 
wówczas pobije cię swoimi argumentami.

W dniu wtorek, 1 września 2015 12:22:13 UTC+2 użytkownik MaRc napisał:
> > Po pierwsze skoro nie może użyć "jakiejś" funkcji to zastosuj "jakąś"
> > inną funkcję. Szklana kula nie działa. Jak napiszesz z czym konkretnie
> > masz to dostaniesz konkretną pomoc.
> 
> Zgadza się nie szklana kula, ale teraz nie pamiętam dokładnie, ale to 
> było chyba to, że nie mogłem użyć LANGUAGE plpsql.
> 
CREATE LANGUAGE plpgsql
http://www.postgresql.org/docs/current/static/sql-createlanguage.html

> CREATE LANGUAGE plpgsql
> http://www.postgresql.org/docs/current/static/sql-createlanguage.html
>

to mogło być to :)
a w mysql jak osiągnąć efekt o który mi chodzi?


-- 
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a 
wówczas pobije cię swoimi argumentami.

> 
> Może jakiś exampel jak to prawidłowo zrobić?
> 
> 
http://www.postgresql.org/docs/9.4/static/plpgsql-trigger.html#PLPGSQL-DML-TRIGGER

W dniu 2015-09-01 o 12:43, irq pisze:
>
>>
>> Może jakiś exampel jak to prawidłowo zrobić?
>>
Nie trzeba example - co, kto, kiedy to mało. Trzeba robić kopie, przed, po. 
W przypadku delete kopię tego co zostało usunięte. Taka tabela historyczna 
będzie niestety większa od źródłowej. Coś za coś. Nie trzeba zaraz tego 
rozgłaszać, we właściwym momencie może uratować Ci d.. Zwłaszcza kiedy ma 
się do czynienia z wrażliwymi danymi.


-- 
Artur

On 2015-08-31, MaRc <tuksmr@gmail.com> wrote:
> Potrzebuję rejestrować, a raczej zapisywać czas ostatniej zmiany w tabeli.
> Mam tabelę nodes i jeśli coś do tej tabeli zostanie dodane, updateowane 
> lub delete to by do tabeli nodes_lupdate był wpisywany timestamp.
> tabela nodes_lupdate zawiera jedynie jedną kolumnę o nazwie tstamp. chcę 
> zrobić "UPDATE nodes_lupdate set tstamp = now()" jeśli cokolwiek zmieni 
> sie w tabeli nodes. potrzebne jest mi to do generowania danych do 
> radiusa, jeśli nie było zmiany to nie ma potrzeby generowania nowej 
> konfiguracji co za tym idzie nie ma potrzeby reloadu serwera.

w tej tabeli nodes_lupdate masz tylko jeden rekord, czy jeden dla
każdego rekordu w nodes?

jeśli jeden dla każdego w nodes, to czemu po prostu nie zrobisz nowej
kolumny w nodes?

jeśli jeden rekord, i zmieniamy to za każdym razem jak cokolwiek się
zmieni, to to jest bardzo niebezpieczne rozwiązanie, bo będzie ci się
lockować przy transakcjach robiących cokolwiek innego niż jednorekordowa
zmiana w nodes.

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

W dniu 02.09.2015 o 12:32, hubert depesz lubaczewski pisze:
> w tej tabeli nodes_lupdate masz tylko jeden rekord, czy jeden dla
> każdego rekordu w nodes?

tylko jeden rekord, który będzie mówił o tym, że nastąpiła jakakolwiek 
zmiana w tabeli nodes i trzeba będzie wygenerować nowy config.

>
> jeśli jeden dla każdego w nodes, to czemu po prostu nie zrobisz nowej
> kolumny w nodes?

to nie jest rozwiązanie. bo przy DELETE nie bedzie tej informacji bo 
wiersz zostanie usunięty. pozatym, trzeba porównywać x wierszy z datą. 
przy osobnej tabeli jedynie z datą nie ma takiego problemu


>
> jeśli jeden rekord, i zmieniamy to za każdym razem jak cokolwiek się
> zmieni, to to jest bardzo niebezpieczne rozwiązanie, bo będzie ci się
> lockować przy transakcjach robiących cokolwiek innego niż jednorekordowa
> zmiana w nodes.

hmm, nie robię masowych updateow ale o tym nie pomyslałem. czyli jeśli 
bym zrobił masową zmiane, powiedzmy 100 rekordów, objął to transakcją to 
z tego co rozumiem, to sie nie wykona, zostanie zlockowane?

dla mnie newralgiczne są trzy kolumny z tabeli nodes. może tylko je 
"śledzić" i triggerować? ale nie zmienia to faktu ewentualnej masowej 
zmiany, o której wspomniałeś.

to jak to naładniej z poziomu bazy zrobić?





>
> depesz
>


-- 
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a 
wówczas pobije cię swoimi argumentami.

On 2015-09-03, MaRc <tuksmr@gmail.com> wrote:
> hmm, nie robię masowych updateow ale o tym nie pomyslałem. czyli jeśli 
> bym zrobił masową zmiane, powiedzmy 100 rekordów, objął to transakcją to 
> z tego co rozumiem, to sie nie wykona, zostanie zlockowane?

jedna się wykona. ale jak bedzie wiele polaczen do bazy danych, kazde
costam robilo/zmienialo, to bedzie problem.

> dla mnie newralgiczne są trzy kolumny z tabeli nodes. może tylko je 
> "śledzić" i triggerować? ale nie zmienia to faktu ewentualnej masowej 
> zmiany, o której wspomniałeś.
> to jak to naładniej z poziomu bazy zrobić?

ja by zrobil tak: tabela na informacje o zmianie ma jedna kolumnę, ale
wiele wierszy.
i po prostu zamiast update, to insert.

insert sie nie zalockuje. dodatkowo - w danych wstawianych do tej tabeli
mozesz zawrzec dodatkowe informacje - np. id rekordu zmienionego.

a to cos co ma aktualizowac dane na zewnatrz bazy - po prostu jak zrobi
swoje to niech kasuje rekordy z tabeli "zmian" i juz.

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/