🚀 go-pugleaf

W dniu 28-09-2016 o 18:51, Ronald Kuczek pisze:
> Cześć,
>
> Zainstalowałem właśnie aktualną wersję Postgresa (9.6 RC1) i tak jak nie
> zaobserwowałem żadnych problemów z samym silnikiem, tak nowy PGAdmin to
> już zupełnie inna bajka ...
> Zastanawiam się kogo świerzbiły palce i komu przeszkadzało dobrze
> działające od kiedy pamiętam narzędzie graficzne (a w Postgresie siedzę
> dość długo). *Nowinka* jest moim zdaniem koszmarnie wolnym wynalazkiem a
> praca z nim wymaga dużej dozy anielskiej cierpliwości lub herbaty z melisą.
> Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na
> dzień zmienić przyzwyczajenia.
> Może coś można zrobić/zoptymalizować ? Jakieś
> doświadczenia/opinie/pomysły ?

Nie znam PGAdmina, ale jeśli jest to chociaż trochę podobne do 
phpMyAdmina to doskonale Cię rozumiem.
Osobiście korzystam z HeidiSQL i nie wyobrażam sobie już pracy bez tego 
narzędzia.

pozdrawiam
W.

On Wednesday, September 28, 2016 at 3:35:21 PM UTC-4, Wojtek Gapiński wrote:
> W dniu 28-09-2016 o 18:51, Ronald Kuczek pisze:
> > Cześć,
> >
> > Zainstalowałem właśnie aktualną wersję Postgresa (9.6 RC1) i tak jak nie
> > zaobserwowałem żadnych problemów z samym silnikiem, tak nowy PGAdmin to
> > już zupełnie inna bajka ...
> > Zastanawiam się kogo świerzbiły palce i komu przeszkadzało dobrze
> > działające od kiedy pamiętam narzędzie graficzne (a w Postgresie siedzę
> > dość długo). *Nowinka* jest moim zdaniem koszmarnie wolnym wynalazkiem a
> > praca z nim wymaga dużej dozy anielskiej cierpliwości lub herbaty z melisą.
> > Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na
> > dzień zmienić przyzwyczajenia.
> > Może coś można zrobić/zoptymalizować ? Jakieś
> > doświadczenia/opinie/pomysły ?
> 
> Nie znam PGAdmina, ale jeśli jest to chociaż trochę podobne do 
> phpMyAdmina to doskonale Cię rozumiem.
> Osobiście korzystam z HeidiSQL i nie wyobrażam sobie już pracy bez tego 
> narzędzia.
> 
> pozdrawiam
> W.

Na razie wyglada ze PgAdmin4 jest duzo wolniejszy od PgAdmin3 (chociaz ladniej wyglada). Osobiscie preferuje JetBrains DataGrip - ale nie jest za darmo. Z darmowych lubie SQuirrel SQL Client. Prz okazji przyjze sie HeidiSQL - moze potrafi cos co SQuirrel nie umie.

W dniu 2016-09-28 o 21:35, Wojtek Gapiński pisze:
> W dniu 28-09-2016 o 18:51, Ronald Kuczek pisze:
>> Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na
>> dzień zmienić przyzwyczajenia.
>> Może coś można zrobić/zoptymalizować ? Jakieś
>> doświadczenia/opinie/pomysły ?
>
> Nie znam PGAdmina, ale jeśli jest to chociaż trochę podobne do
> phpMyAdmina to doskonale Cię rozumiem.
> Osobiście korzystam z HeidiSQL i nie wyobrażam sobie już pracy bez tego
> narzędzia.

pgAdmin to właśnie takie narzędzie desktopowe podobne do HeidiSQL

phpPgAdmin to narzędzie jak phpMyAdmin (tylko 58 razy gorsze).

a pgAdmin 4 to jakieś kompletne nieporozumienie

On Wed, 28 Sep 2016 18:51:27 +0200, Ronald Kuczek wrote:

> Zainstalowałem właśnie aktualną wersję Postgresa (9.6 RC1) i tak jak nie 
> zaobserwowałem żadnych problemów z samym silnikiem, tak nowy PGAdmin to 
> już zupełnie inna bajka ...
> Zastanawiam się kogo świerzbiły palce i komu przeszkadzało dobrze 
> działające od kiedy pamiętam narzędzie graficzne (a w Postgresie siedzę 
> dość długo). *Nowinka* jest moim zdaniem koszmarnie wolnym wynalazkiem a 
> praca z nim wymaga dużej dozy anielskiej cierpliwości lub herbaty z melisą.
> Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na 
> dzień zmienić przyzwyczajenia.
> Może coś można zrobić/zoptymalizować ? Jakieś doświadczenia/opinie/pomysły ?

Sprawdź nowe narzędzie, które miało niedawno premierę. DB Workbench. To
znaczy narzędzie stare, ale od ostatniej wersji wspiera Postgresa, nie wiem
jaki jest obecny poziom wsparcia, ale można się spodziewać, że z biegiem
czasu będzie to najlepszy graficzny menadżer Postgresa.

-- 
pozdrawiam
Roman Tyczka

W dniu środa, 28 września 2016 18:51:32 UTC+2 użytkownik Ronald Kuczek napisał:

> Może coś można zrobić/zoptymalizować ? Jakieś doświadczenia/opinie/pomysły ?

psql

W dniu 28.09.2016 o 21:35, Wojtek Gapiński pisze:
> Nie znam PGAdmina, ale jeśli jest to chociaż trochę podobne do
> phpMyAdmina to doskonale Cię rozumiem.
> Osobiście korzystam z HeidiSQL i nie wyobrażam sobie już pracy bez tego
> narzędzia.

Dzięki za typ. Zainstalowałem HeidiSQL ale jakby to powiedzieć ... 
szukam dalej ;-)

Pozdrawiam
Rony

W dniu 28.09.2016 o 23:47, Adam M pisze:

>
> Na razie wyglada ze PgAdmin4 jest duzo wolniejszy od PgAdmin3 (chociaz ladniej wyglada). Osobiscie preferuje JetBrains DataGrip - ale nie jest za darmo. Z darmowych lubie SQuirrel SQL Client. Prz okazji przyjze sie HeidiSQL - moze potrafi cos co SQuirrel nie umie.
>

Dzięki za typ, spróbuję. To, że PgAdmin4 jest dużo wolniejszy od 
PgAdmin3 to małe niedopowiedzenie ;-) Kurczę, myślałem, że laptop, na 
którym można grać w najnowsze gry da radę, ale nie daje, widać za słaby :D

Pozdrawiam
Rony

W dniu 29.09.2016 o 11:50, Roman Tyczka pisze:
> Sprawdź nowe narzędzie, które miało niedawno premierę. DB Workbench. To
> znaczy narzędzie stare, ale od ostatniej wersji wspiera Postgresa, nie wiem
> jaki jest obecny poziom wsparcia, ale można się spodziewać, że z biegiem
> czasu będzie to najlepszy graficzny menadżer Postgresa.
>
Dzięki za odzew, spróbuję.

Pozdrawiam
Rony

W dniu 29.09.2016 o 16:49, irq pisze:
> W dniu środa, 28 września 2016 18:51:32 UTC+2 użytkownik Ronald Kuczek napisał:
>
>> Może coś można zrobić/zoptymalizować ? Jakieś doświadczenia/opinie/pomysły ?
>
> psql
>
psql to konsola. Nie mam problemu ze środowiskiem tekstowym, ale 
pracując w środowisku graficznym człowiek przyzwyczaja się do gui.
Do czasu PGAdmina 3 to było świetne gui, z nową wersją chłopaki 
strzelili we własne kolano.

Pozdrawiam
Rony

W dniu 29.09.2016 o 08:09, ww pisze:
> a pgAdmin 4 to jakieś kompletne nieporozumienie

Zgadzam się w pełni. Podręcznikowa ilustracja powiedzenia - co się 
polepszy to się popieprzy.

Pozdrawiam
Rony

W dniu 2016-09-29 o 23:30, Ronald Kuczek pisze:
> W dniu 28.09.2016 o 23:47, Adam M pisze:
>
>>
>> Na razie wyglada ze PgAdmin4 jest duzo wolniejszy od PgAdmin3 (chociaz
>> ladniej wyglada). Osobiscie preferuje JetBrains DataGrip - ale nie
>> jest za darmo. Z darmowych lubie SQuirrel SQL Client. Prz okazji
>> przyjze sie HeidiSQL - moze potrafi cos co SQuirrel nie umie.
>>
>
> Dzięki za typ, spróbuję. To, że PgAdmin4 jest dużo wolniejszy od
> PgAdmin3 to małe niedopowiedzenie ;-) Kurczę, myślałem, że laptop, na
> którym można grać w najnowsze gry da radę, ale nie daje, widać za słaby :D

Jedyne wytłumaczenie tej sytuacji to BETA. Z czasem może będzie lepiej. 
U mnie się to już na starcie 13 razy wysypało.

W dniu 2016-09-29 o 11:50, Roman Tyczka pisze:
> On Wed, 28 Sep 2016 18:51:27 +0200, Ronald Kuczek wrote:
>
>> Zainstalowałem właśnie aktualną wersję Postgresa (9.6 RC1) i tak jak nie
>> zaobserwowałem żadnych problemów z samym silnikiem, tak nowy PGAdmin to
>> już zupełnie inna bajka ...
>> Zastanawiam się kogo świerzbiły palce i komu przeszkadzało dobrze
>> działające od kiedy pamiętam narzędzie graficzne (a w Postgresie siedzę
>> dość długo). *Nowinka* jest moim zdaniem koszmarnie wolnym wynalazkiem a
>> praca z nim wymaga dużej dozy anielskiej cierpliwości lub herbaty z melisą.
>> Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na
>> dzień zmienić przyzwyczajenia.
>> Może coś można zrobić/zoptymalizować ? Jakieś doświadczenia/opinie/pomysły ?
>
> Sprawdź nowe narzędzie, które miało niedawno premierę. DB Workbench. To
> znaczy narzędzie stare, ale od ostatniej wersji wspiera Postgresa, nie wiem
> jaki jest obecny poziom wsparcia, ale można się spodziewać, że z biegiem
> czasu będzie to najlepszy graficzny menadżer Postgresa.

Narzędzie dobre (używam do Firebirda) ale dla Postgresa wersja Lite 
jeszcze niedostępna :(


-- 
pozdrawiam
AS

On Thursday, September 29, 2016 at 11:37:20 PM UTC+2, Ronald Kuczek wrote:
> W dniu 29.09.2016 o 16:49, irq pisze:
> > W dniu środa, 28 września 2016 18:51:32 UTC+2 użytkownik Ronald Kuczek napisał:
> >
> >> Może coś można zrobić/zoptymalizować ? Jakieś doświadczenia/opinie/pomysły ?
> >
> > psql
> >
> psql to konsola. Nie mam problemu ze środowiskiem tekstowym, ale 
> pracując w środowisku graficznym człowiek przyzwyczaja się do gui.
> Do czasu PGAdmina 3 to było świetne gui, z nową wersją chłopaki 
> strzelili we własne kolano.
> 
> Pozdrawiam
> Rony

Ja nawet bym nie próbował czegoś innego niż konsoli.
Pozdrawiam

On Fri, 30 Sep 2016 12:09:21 -0700 (PDT), M.M. wrote:

>> psql to konsola. Nie mam problemu ze środowiskiem tekstowym, ale 
>> pracując w środowisku graficznym człowiek przyzwyczaja się do gui.
>> Do czasu PGAdmina 3 to było świetne gui, z nową wersją chłopaki 
>> strzelili we własne kolano.
>> 
>> Pozdrawiam
>> Rony
> 
> Ja nawet bym nie próbował czegoś innego niż konsoli.
> Pozdrawiam

ERD też w konsoli budujesz?

-- 
pozdrawiam
Roman Tyczka

On Saturday, October 1, 2016 at 10:10:26 AM UTC+2, Roman Tyczka wrote:
> On Fri, 30 Sep 2016 12:09:21 -0700 (PDT), M.M. wrote:
> 
> >> psql to konsola. Nie mam problemu ze środowiskiem tekstowym, ale 
> >> pracując w środowisku graficznym człowiek przyzwyczaja się do gui.
> >> Do czasu PGAdmina 3 to było świetne gui, z nową wersją chłopaki 
> >> strzelili we własne kolano.
> >> 
> >> Pozdrawiam
> >> Rony
> > 
> > Ja nawet bym nie próbował czegoś innego niż konsoli.
> > Pozdrawiam
> 
> ERD też w konsoli budujesz?
> 
> -- 
> pozdrawiam
> Roman Tyczka

W zasadzie to tak, budują się w mojej wyobraźni, (nie tylko wtedy) gdy
pracuję w narzędziu tekstowym. 

Pozdrawiam

On Sat, 1 Oct 2016 04:29:05 -0700 (PDT), M.M. wrote:

>>> Ja nawet bym nie próbował czegoś innego niż konsoli.
>>> Pozdrawiam
>> 
>> ERD też w konsoli budujesz?

> 
> W zasadzie to tak, budują się w mojej wyobraźni, (nie tylko wtedy) gdy
> pracuję w narzędziu tekstowym. 

I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
500?

-- 
pozdrawiam
Roman Tyczka

On Saturday, October 1, 2016 at 7:09:35 PM UTC+2, Roman Tyczka wrote:
> On Sat, 1 Oct 2016 04:29:05 -0700 (PDT), M.M. wrote:
> 
> >>> Ja nawet bym nie próbował czegoś innego niż konsoli.
> >>> Pozdrawiam
> >> 
> >> ERD też w konsoli budujesz?
> 
> > 
> > W zasadzie to tak, budują się w mojej wyobraźni, (nie tylko wtedy) gdy
> > pracuję w narzędziu tekstowym. 
> 
> I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
> 500?

Nie wiem ile obejmuję. Tabel zazwyczaj 5, rzadziej 10 czy 20, czyli obiektów
gdzieś do 100 może do 150. Na graficznej prezentacji też więcej bym
nie ogarnął. Zwykle analizuję te tabele z którym chwilo muszę pracować i 
zwykle pracuję na 5-10 tabelach. Rzadko muszę podejmować decyzje, które
wymagałyby znajomości na pamięć 200 tabel i tysięcy obiektów.

Pozdrawiam

W dniu 02.10.2016 o 02:07, M.M. pisze:
>> I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
>> 500?
>
> Nie wiem ile obejmuję. Tabel zazwyczaj 5, rzadziej 10 czy 20, czyli obiektów
> gdzieś do 100 może do 150. Na graficznej prezentacji też więcej bym
> nie ogarnął. Zwykle analizuję te tabele z którym chwilo muszę pracować i
> zwykle pracuję na 5-10 tabelach. Rzadko muszę podejmować decyzje, które
> wymagałyby znajomości na pamięć 200 tabel i tysięcy obiektów.
>

Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych 
i tutaj niestety konsola staje się niewygodna. Na konsoli to można 
szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui 
jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na 
konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele 
wygodniejsze ...
Pozdrawiam
Rony

On Monday, October 3, 2016 at 4:12:53 PM UTC-4, Ronald Kuczek wrote:
> W dniu 02.10.2016 o 02:07, M.M. pisze:
> >> I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
> >> 500?
> >
> > Nie wiem ile obejmuję. Tabel zazwyczaj 5, rzadziej 10 czy 20, czyli obiektów
> > gdzieś do 100 może do 150. Na graficznej prezentacji też więcej bym
> > nie ogarnął. Zwykle analizuję te tabele z którym chwilo muszę pracować i
> > zwykle pracuję na 5-10 tabelach. Rzadko muszę podejmować decyzje, które
> > wymagałyby znajomości na pamięć 200 tabel i tysięcy obiektów.
> >
> 
> Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych 
> i tutaj niestety konsola staje się niewygodna. Na konsoli to można 
> szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui 
> jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na 
> konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele 
> wygodniejsze ...
> Pozdrawiam
> Rony

Szanowny kolega nie rozumie problemu:
Prawdziwy administrator/programista baz danych pracuje wylacznie z terminala tekstowego podlaczonego do sieci telefonicznej modemem o predkosci 300bps - wtedy ma wiecej czsu na budowanie bazy danych w wyobrazni ;-) 
A pozatym zdrowia zycze ;-)
Adam

W dniu 03.10.2016 o 22:22, Adam M pisze:

> Szanowny kolega nie rozumie problemu:
> Prawdziwy administrator/programista baz danych pracuje wylacznie z terminala tekstowego podlaczonego do sieci telefonicznej modemem o predkosci 300bps - wtedy ma wiecej czsu na budowanie bazy danych w wyobrazni ;-)
> A pozatym zdrowia zycze ;-)
> Adam
>

A no chyba, że tak, to przepraszam. Zachowałem się jak gówniarz, to się 
więcej nie powtórzy :-D

Pozdrawiam
Rony.

On Monday, October 3, 2016 at 10:12:53 PM UTC+2, Ronald Kuczek wrote:
> W dniu 02.10.2016 o 02:07, M.M. pisze:
> >> I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
> >> 500?
> >
> > Nie wiem ile obejmuję. Tabel zazwyczaj 5, rzadziej 10 czy 20, czyli obiektów
> > gdzieś do 100 może do 150. Na graficznej prezentacji też więcej bym
> > nie ogarnął. Zwykle analizuję te tabele z którym chwilo muszę pracować i
> > zwykle pracuję na 5-10 tabelach. Rzadko muszę podejmować decyzje, które
> > wymagałyby znajomości na pamięć 200 tabel i tysięcy obiektów.
> >
> 
> Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych 
> i tutaj niestety konsola staje się niewygodna. Na konsoli to można 
> szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui 
> jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na 
> konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele 
> wygodniejsze ...


Gui ułatwia - nie ma tutaj z czym dyskutować. Ale, czy codziennie
pracujesz z inną bazą która ma rozmiar rzędu 40 tabel?
Jeśli tak, to faktycznie dużo czasu przeznaczasz na wgryzienie się w
strukturę bazy. Natomiast jeśli pracujesz przez dłuższy czas z jedną 
bazą która ma nawet ponad 100 tabel, to chyba czas na zrozumienie
struktury inwestujesz jednorazowo? Więc jeśli w skali kilku miesięcy
stracisz parę godzin czasu, to chyba aż takiego problemu nie ma?
Większy problem będzie, gdy niedopracowane GUI nie wyświetli jakiejś
tabeli? Poza tym GUI i tak nie zastąpi dobrego opisu.

Pozdrawiam

W dniu 03.10.2016 o 22:12, Ronald Kuczek pisze:

>
> Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych
> i tutaj niestety konsola staje się niewygodna. Na konsoli to można
> szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui
> jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na
> konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele
> wygodniejsze ...
> Pozdrawiam
> Rony
>


Niby tak, ale kiedyś mając nóż na gardle i jakiś poważny problem
rzuciłem w kąt gui i konsolę używałem ;)
Mimo, że wcale dobrze struktury tej bazy nie znałem.


-- 
Cezary Grądys
czarekgr@wa.onet.pl

On Tuesday, October 4, 2016 at 11:59:44 AM UTC+2, Czarek Grądys wrote:
> W dniu 03.10.2016 o 22:12, Ronald Kuczek pisze:
> 
> >
> > Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych
> > i tutaj niestety konsola staje się niewygodna. Na konsoli to można
> > szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui
> > jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na
> > konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele
> > wygodniejsze ...
> > Pozdrawiam
> > Rony
> >
> 
> 
> Niby tak, ale kiedyś mając nóż na gardle i jakiś poważny problem
> rzuciłem w kąt gui i konsolę używałem ;)
> Mimo, że wcale dobrze struktury tej bazy nie znałem.

Profesjonalna i zarazem łopatologiczna dokumentacja odgrywa 
największą rolę w takich sytuacjach. GUI tylko ciut pomaga.

Pozdrawiam

W dniu 2016-10-04 o 08:18, M.M. pisze:
> On Monday, October 3, 2016 at 10:12:53 PM UTC+2, Ronald Kuczek wrote:
>> W dniu 02.10.2016 o 02:07, M.M. pisze:
>>>> I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
>>>> 500?
>>>
>>> Nie wiem ile obejmuję. Tabel zazwyczaj 5, rzadziej 10 czy 20, czyli obiektów
>>> gdzieś do 100 może do 150. Na graficznej prezentacji też więcej bym
>>> nie ogarnął. Zwykle analizuję te tabele z którym chwilo muszę pracować i
>>> zwykle pracuję na 5-10 tabelach. Rzadko muszę podejmować decyzje, które
>>> wymagałyby znajomości na pamięć 200 tabel i tysięcy obiektów.
>>>
>>
>> Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych
>> i tutaj niestety konsola staje się niewygodna. Na konsoli to można
>> szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui
>> jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na
>> konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele
>> wygodniejsze ...
>
>
> Gui ułatwia - nie ma tutaj z czym dyskutować. Ale, czy codziennie
> pracujesz z inną bazą która ma rozmiar rzędu 40 tabel?
Nie widzisz, że robisz z siebie głupa.
> Jeśli tak, to faktycznie dużo czasu przeznaczasz na wgryzienie się w
> strukturę bazy. Natomiast jeśli pracujesz przez dłuższy czas z jedną
> bazą która ma nawet ponad 100 tabel, to chyba czas na zrozumienie
> struktury inwestujesz jednorazowo?
Zastałem coś co miało ok 200 tabel. Bez dokumentacji. Chociaż na kartce (nie 
jednej) było ERD. Zgroza, ale szefowi nie mogłem powiedzieć, że nie kumam. 
Za godzinę chciał mieć zestawienie, i tak kawałek po kawałku całość z kartki 
trafiła do głowy :) Jeśli byłoby 5-10 tabel, to kręcąc małym palcem bym to 
robił.
Więc jeśli w skali kilku miesięcy
> stracisz parę godzin czasu, to chyba aż takiego problemu nie ma?
> Większy problem będzie, gdy niedopracowane GUI nie wyświetli jakiejś
> tabeli? Poza tym GUI i tak nie zastąpi dobrego opisu.
Czego Ci nie wyświetli, motasz się. Rozpisz sobie to o czym mówisz na 
kartce, bo głowa jest zawodna bez logicznego myślenia.


-- 
Artur

W dniu 2016-10-04 o 12:22, M.M. pisze:
> On Tuesday, October 4, 2016 at 11:59:44 AM UTC+2, Czarek Grądys wrote:
>> W dniu 03.10.2016 o 22:12, Ronald Kuczek pisze:
>>
>>>
>>> Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych
>>> i tutaj niestety konsola staje się niewygodna. Na konsoli to można
>>> szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui
>>> jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na
>>> konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele
>>> wygodniejsze ...
>>> Pozdrawiam
>>> Rony
>>>
>>
>>
>> Niby tak, ale kiedyś mając nóż na gardle i jakiś poważny problem
>> rzuciłem w kąt gui i konsolę używałem ;)
>> Mimo, że wcale dobrze struktury tej bazy nie znałem.
>
> Profesjonalna i zarazem łopatologiczna dokumentacja odgrywa
> największą rolę w takich sytuacjach. GUI tylko ciut pomaga.
>
Gówno prawda, strzałki pomagają, widać co z czego. Nie trzeba nikogo się 
pytać... No chyba, że nie umiesz czytać schematów, nie umiesz ich robić. (?)


-- 
Artur

W dniu 04.10.2016 o 08:18, M.M. pisze:
> Gui ułatwia - nie ma tutaj z czym dyskutować. Ale, czy codziennie
> pracujesz z inną bazą która ma rozmiar rzędu 40 tabel?
> Jeśli tak, to faktycznie dużo czasu przeznaczasz na wgryzienie się w
> strukturę bazy. Natomiast jeśli pracujesz przez dłuższy czas z jedną
> bazą która ma nawet ponad 100 tabel, to chyba czas na zrozumienie
> struktury inwestujesz jednorazowo? Więc jeśli w skali kilku miesięcy
> stracisz parę godzin czasu, to chyba aż takiego problemu nie ma?
> Większy problem będzie, gdy niedopracowane GUI nie wyświetli jakiejś
> tabeli? Poza tym GUI i tak nie zastąpi dobrego opisu.

Przede wszystkim piszę sporo funkcji w plpgsql, nierzadko w projektach, 
które widzę pierwszy raz w życiu (i to na chwilę, do momentu zakończenia 
realizacji zlecenia) a moim zadaniem jest stworzenie funkcji 
zwracających odpowiednie wyniki zgodnie ze zleconą specyfikacją 
ewentualnie optymalizacja zapytań w danym projekcie. Strukturę tabel 
zazwyczaj mam lepiej lub gorzej udokumentowaną (niekiedy muszę się 
domyślać) ale do przeglądania/poprawiania kodu funkcji jakoś psql mi nie 
wystarcza. Nawet nie wiem jakie widoki systemowe trzeba odpytać, by 
wyciągnąć kod funkcji w psql (robi to za mnie gui, w widoki systemowe 
wgłębiać się nie muszę). Zresztą - jak masz takich funkcji 
kilkadziesiąt, do tego sporo typów to naprawdę bez gui pogubić się 
nietrudno.

Pozdrawiam
Rony

W dniu 2016-10-05 o 19:01, Ronald Kuczek pisze:
> W dniu 04.10.2016 o 08:18, M.M. pisze:
>> Gui ułatwia - nie ma tutaj z czym dyskutować. Ale, czy codziennie
>> pracujesz z inną bazą która ma rozmiar rzędu 40 tabel?
>> Jeśli tak, to faktycznie dużo czasu przeznaczasz na wgryzienie się w
>> strukturę bazy. Natomiast jeśli pracujesz przez dłuższy czas z jedną
>> bazą która ma nawet ponad 100 tabel, to chyba czas na zrozumienie
>> struktury inwestujesz jednorazowo? Więc jeśli w skali kilku miesięcy
>> stracisz parę godzin czasu, to chyba aż takiego problemu nie ma?
>> Większy problem będzie, gdy niedopracowane GUI nie wyświetli jakiejś
>> tabeli? Poza tym GUI i tak nie zastąpi dobrego opisu.
>
> Przede wszystkim piszę sporo funkcji w plpgsql, nierzadko w projektach,
> które widzę pierwszy raz w życiu (i to na chwilę, do momentu zakończenia
> realizacji zlecenia) a moim zadaniem jest stworzenie funkcji zwracających
> odpowiednie wyniki zgodnie ze zleconą specyfikacją ewentualnie optymalizacja
> zapytań w danym projekcie. Strukturę tabel zazwyczaj mam lepiej lub gorzej
> udokumentowaną (niekiedy muszę się domyślać) ale do przeglądania/poprawiania
> kodu funkcji jakoś psql mi nie wystarcza. Nawet nie wiem jakie widoki
> systemowe trzeba odpytać, by wyciągnąć kod funkcji w psql (robi to za mnie
> gui, w widoki systemowe wgłębiać się nie muszę). Zresztą - jak masz takich
> funkcji kilkadziesiąt, do tego sporo typów to naprawdę bez gui pogubić się
> nietrudno.
>
> Pozdrawiam
> Rony
>
Fajnie napisałeś. Dawno nie widziałem :) Z drugiej strony grupa jednak 
umiera, poziom spada :)To nie grupa od pytań po co jest w ogóle index. 
depesza dawno nie było :)

-- 
Artur

W dniu 04.10.2016 o 11:59, Czarek Grądys pisze:
> Niby tak, ale kiedyś mając nóż na gardle i jakiś poważny problem
> rzuciłem w kąt gui i konsolę używałem ;)
> Mimo, że wcale dobrze struktury tej bazy nie znałem.
>

W takich przypadkach zrzucam pg_dumpem schemat do pliku i tak po prostu, 
jak ten dinozaur informatyki czytam skrypt.

Pozdrawiam
Rony

W dniu 04.10.2016 o 12:22, M.M. pisze:
>
> Profesjonalna i zarazem łopatologiczna dokumentacja odgrywa
> największą rolę w takich sytuacjach. GUI tylko ciut pomaga.
>
Niestety, niekiedy ta ostatnia jest niekiedy tylko marzeniem i trzeba 
wyciągać wnioski na podstawie kodu/schematu. Zwłaszcza jeśli projekt 
prowadziło ileś tam osób/firm, ktoś tam poległ po drodze i strzelił 
focha z przytupem - czytaj nie odbiera telefonów i nie ma z kim pogadać 
a jednak problem rozwiązać trzeba. W sumie chyba wszyscy to mają - 
najbardziej nienawidzę poprawiać po kimś spier*lonej roboty.
Na szczęście dotychczas trafiałem na projekty, w których przynajmniej 
mam do dyspozycji zarówno schemat jak i kod źródłowy aplikacji 
korzystających z bazy danych.

Pozdrawiam
Rony

On Wednesday, October 5, 2016 at 8:54:50 PM UTC+2, Ronald Kuczek wrote:
> W dniu 04.10.2016 o 12:22, M.M. pisze:
> >
> > Profesjonalna i zarazem łopatologiczna dokumentacja odgrywa
> > największą rolę w takich sytuacjach. GUI tylko ciut pomaga.
> >
> Niestety, niekiedy ta ostatnia jest niekiedy tylko marzeniem i trzeba 
> wyciągać wnioski na podstawie kodu/schematu. 
A to czasami jest niemożliwe. 


> Zwłaszcza jeśli projekt 
> prowadziło ileś tam osób/firm, ktoś tam poległ po drodze i strzelił 
> focha z przytupem - czytaj nie odbiera telefonów i nie ma z kim pogadać 
> a jednak problem rozwiązać trzeba. 
To osobny problem. Przed takimi sytuacjami trzeba się zabezpieczyć, albo 
traktować jako wkalkulowane ryzyko. Generalnie o pracowników, wykonawców 
trzeba dbać, trzeba się zabezpieczyć dobrymi umowami korzystnymi dla 
obu stron, itd. Gdy jakiś czas temu miałem za zadanie zatrudnić/znaleźć 
zdolną osobę która nie ma wyjścia i musi szybko podjąć pracę nawet za
wynagrodzenie poniżej średniej, to odetchnąłem z ulgą, gdy się nie udało.
Co bym miał po powiedzmy pół roku współpracy? W najlepszym razie, to co
opisałeś wyżej, w najgorszym by mi jeszcze jakieś świnie na pożegnanie
podłożył. Po pół roku bym był odpowiedzialny za coś w stylu: poszło 
25tys i nikt nie umie kontynuować pracy. A i jeszcze jedno: nie warto
większych projektów robić na łeb na szyję w takich warunkach że
szkoda czasu na solidną dokumentację. Ale to wszystko, jak już napisałem,
osobny problem.


> W sumie chyba wszyscy to mają - 
> najbardziej nienawidzę poprawiać po kimś spier*lonej roboty.
To też osobny problem, schemat gui można wygenerować do spierdzielonej 
roboty i do dobrej.

> Na szczęście dotychczas trafiałem na projekty, w których przynajmniej 
> mam do dyspozycji zarówno schemat jak i kod źródłowy aplikacji 
> korzystających z bazy danych.
Nie wiem czy bym się podjął bez powyższych. Kilka razy próbowałem i straciłem
czas - w końcu i tak nie dałem rady poprawić spieprzonego projektu, a 
za czas, jaki poświęcilem na analizę i próby, nikt mi nie zapłacił. Chyba że
na stawkę godzinową bez żadnej odpowiedzialności.


Pozdrawiam

On Wednesday, October 5, 2016 at 6:58:29 AM UTC+2, artiun wrote:
> W dniu 2016-10-04 o 08:18, M.M. pisze:
> > On Monday, October 3, 2016 at 10:12:53 PM UTC+2, Ronald Kuczek wrote:
> >> W dniu 02.10.2016 o 02:07, M.M. pisze:
> >>>> I ile obiektów bazowych tak obejmujesz pamięcią? 10, 20? A jeśli baza ma
> >>>> 500?
> >>>
> >>> Nie wiem ile obejmuję. Tabel zazwyczaj 5, rzadziej 10 czy 20, czyli obiektów
> >>> gdzieś do 100 może do 150. Na graficznej prezentacji też więcej bym
> >>> nie ogarnął. Zwykle analizuję te tabele z którym chwilo muszę pracować i
> >>> zwykle pracuję na 5-10 tabelach. Rzadko muszę podejmować decyzje, które
> >>> wymagałyby znajomości na pamięć 200 tabel i tysięcy obiektów.
> >>>
> >>
> >> Tak się składa, że czasami muszę mieć wgląd na cały schemat bazy danych
> >> i tutaj niestety konsola staje się niewygodna. Na konsoli to można
> >> szybko zapytać, zdiagnozować prosty problem ale w codziennej pracy gui
> >> jest zwyczajnie wygodniejsze. Oczywiście można wszystko zrobić na
> >> konsoli tylko po kiego grzyba, jeśli narzędzia graficzne są o wiele
> >> wygodniejsze ...
> >
> >
> > Gui ułatwia - nie ma tutaj z czym dyskutować. Ale, czy codziennie
> > pracujesz z inną bazą która ma rozmiar rzędu 40 tabel?
> Nie widzisz, że robisz z siebie głupa.
Potrafisz podkręcić jasność wypowiedzi, czy tylko na tyle Cię stać?



> > Jeśli tak, to faktycznie dużo czasu przeznaczasz na wgryzienie się w
> > strukturę bazy. Natomiast jeśli pracujesz przez dłuższy czas z jedną
> > bazą która ma nawet ponad 100 tabel, to chyba czas na zrozumienie
> > struktury inwestujesz jednorazowo?
> Zastałem coś co miało ok 200 tabel. Bez dokumentacji. Chociaż na kartce (nie 
> jednej) było ERD. Zgroza, ale szefowi nie mogłem powiedzieć, że nie kumam. 
> Za godzinę chciał mieć zestawienie, i tak kawałek po kawałku całość z kartki 
> trafiła do głowy :) Jeśli byłoby 5-10 tabel, to kręcąc małym palcem bym to 
> robił.
> Więc jeśli w skali kilku miesięcy
> > stracisz parę godzin czasu, to chyba aż takiego problemu nie ma?
> > Większy problem będzie, gdy niedopracowane GUI nie wyświetli jakiejś
> > tabeli? Poza tym GUI i tak nie zastąpi dobrego opisu.
> Czego Ci nie wyświetli, motasz się. Rozpisz sobie to o czym mówisz na 
> kartce, bo głowa jest zawodna bez logicznego myślenia.
> 
> 
> -- 
> Artur

W dniu 05.10.2016 o 19:36, artiun pisze:
> Fajnie napisałeś. Dawno nie widziałem :) Z drugiej strony grupa jednak
> umiera, poziom spada :)To nie grupa od pytań po co jest w ogóle index.
> depesza dawno nie było :)

Tak jakoś wyszło, że wiedza jest dostępna na jedno zapytanie w google i 
mało kto musi się posiłkować grupą dyskusyjną. Te czasy minęły, gdy ktoś 
zapytał i chciał zaczekać chociaż te kilkanaście minut, dziś odpowiedź 
musi być już, zaraz, teraz. Szkoda, że mało kto już dzisiaj czyta 
dokumentację, ale co tam, postęp to postęp :-D

Pozdrawiam
Rony

W dniu 2016-10-05 o 23:24, M.M. pisze:
> On Wednesday, October 5, 2016 at 8:54:50 PM UTC+2, Ronald Kuczek wrote:
>> W dniu 04.10.2016 o 12:22, M.M. pisze:
>>>
>>> Profesjonalna i zarazem łopatologiczna dokumentacja odgrywa
>>> największą rolę w takich sytuacjach. GUI tylko ciut pomaga.
>>>
>> Niestety, niekiedy ta ostatnia jest niekiedy tylko marzeniem i trzeba
>> wyciągać wnioski na podstawie kodu/schematu.
> A to czasami jest niemożliwe.
Wszystko się da.

>
>
>> Zwłaszcza jeśli projekt
>> prowadziło ileś tam osób/firm, ktoś tam poległ po drodze i strzelił
>> focha z przytupem - czytaj nie odbiera telefonów i nie ma z kim pogadać
>> a jednak problem rozwiązać trzeba.
> To osobny problem. Przed takimi sytuacjami trzeba się zabezpieczyć, albo
> traktować jako wkalkulowane ryzyko. Generalnie o pracowników, wykonawców
> trzeba dbać, trzeba się zabezpieczyć dobrymi umowami korzystnymi dla
> obu stron, itd. Gdy jakiś czas temu miałem za zadanie zatrudnić/znaleźć
> zdolną osobę która nie ma wyjścia i musi szybko podjąć pracę nawet za
> wynagrodzenie poniżej średniej, to odetchnąłem z ulgą, gdy się nie udało.awsz
> Co bym miał po powiedzmy pół roku współpracy? W najlepszym razie, to co
> opisałeś wyżej, w najgorszym by mi jeszcze jakieś świnie na pożegnanie
> podłożył. Po pół roku bym był odpowiedzialny za coś w stylu: poszło
> 25tys i nikt nie umie kontynuować pracy. A i jeszcze jedno: nie warto
> większych projektów robić na łeb na szyję w takich warunkach że
> szkoda czasu na solidną dokumentację. Ale to wszystko, jak już napisałem,
> osobny problem.
Zawsze to mówię i robię. Spoko gościu, wygadałeś się... Teraz powoli - czego 
oczekujesz. Takie czasy, wszystkim się śpieszy :)
>
>
>> W sumie chyba wszyscy to mają -
>> najbardziej nienawidzę poprawiać po kimś spier*lonej roboty.
> To też osobny problem, schemat gui można wygenerować do spierdzielonej
> roboty i do dobrej.
>
Tego nie rozumiem (zdania).
Da się odwrócić, czasem jednak nie ma po co.
>> Na szczęście dotychczas trafiałem na projekty, w których przynajmniej
>> mam do dyspozycji zarówno schemat jak i kod źródłowy aplikacji
>> korzystających z bazy danych.
> Nie wiem czy bym się podjął bez powyższych. Kilka razy próbowałem i straciłem
> czas - w końcu i tak nie dałem rady poprawić spieprzonego projektu, a
> za czas, jaki poświęcilem na analizę i próby, nikt mi nie zapłacił. Chyba że
> na stawkę godzinową bez żadnej odpowiedzialności.
>
Podstawa to spokój. Robota nie ucieknie, a pomyśleć zawsze można.
>
> Pozdrawiam
>


-- 
Artur

W dniu 2016-10-05 o 20:47, Ronald Kuczek pisze:
> W dniu 04.10.2016 o 11:59, Czarek Grądys pisze:
>> Niby tak, ale kiedyś mając nóż na gardle i jakiś poważny problem
>> rzuciłem w kąt gui i konsolę używałem ;)
>> Mimo, że wcale dobrze struktury tej bazy nie znałem.
>>
>
> W takich przypadkach zrzucam pg_dumpem schemat do pliku i tak po prostu, jak
> ten dinozaur informatyki czytam skrypt.
>
:))))))))))


Ubawiłeś mnie.


-- 
Artur

W dniu 28.09.2016 o 18:51, Ronald Kuczek pisze:
[...]
Cześ,

W międzyczasie pojawił release. Ktoś słusznie zasugerował, że to była 
beta. Trochę racji miał. Zainstalowałem i jest trochę lepiej ale mimo 
wszystko PGAdmin4 jeśli chodzi o wydajność to nadal tragiczna pomyłka.

Pozdrawiam i dziękuję wszystkim za pomoc
Rony

On Wed, 28 Sep 2016 18:51:27 +0200, Ronald Kuczek wrote:

> Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na 
> dzień zmienić przyzwyczajenia.

http://fishcodelib.com/Database.htm

Takie coś jeszcze trafiłem, prosto z Chin, daj znać co warte jeśli się
pobawisz :-)

-- 
pozdrawiam
Roman Tyczka

On Tuesday, October 18, 2016 at 4:59:24 AM UTC-4, Roman Tyczka wrote:
> On Wed, 28 Sep 2016 18:51:27 +0200, Ronald Kuczek wrote:
> 
> > Chwilowo przesiadłem się na EMS PostgreSQL Lite ale ciężko z dnia na 
> > dzień zmienić przyzwyczajenia.
> 
> http://fishcodelib.com/Database.htm
> 
> Takie coś jeszcze trafiłem, prosto z Chin, daj znać co warte jeśli się
> pobawisz :-)
> 
> -- 
> pozdrawiam
> Roman Tyczka

W moim przypadku najlepsze efekty daje kombinacja PGAdmin3 (dla szybkiego podgladania struktury bazy danych i administracji i szybkich krotkich zapytan SQL) + JetBrains DataGrip (dla masywnych zapytan i skomplikwanych funkcji - JetBrains smart type code completion jest nie do pobicia).
Jesli ktos nie chce placic za DataGrip - mozna uzyc SQuirrel SQL - nie jest zly - ale niestety type ahead bardzo czesto gubi sie przy bardziej skomplikowanych zapytaniach.

--
pozdrowienia
Adam M.