pgAdmin III alternatíva (jobb nincs, de javítgatják)

Adatbázis: SQL, XML DB

Sziasztok.

Egy project-ben elkövettem azt a hibát, hogy postgresql választottam adatbázis kezelőnek. (Megtetézve azzal, hogy kihasználom az enyhén szólva is átgondolatlan/kidolgozatlan fícsöreit is. Valószínűleg ez az igazi hiba, nem maga a postgresql.)
Ebbe a csőbe már bementem, nem igazán tudok rajta változtatni.
Amíg nincsenek készen az adatmanipuláló GUI-k, addig elég sokat kell matatni az adatbázist, jobb híján a pgAdmin III-mal.
Régóta keresek valamilyen alternatívát a pgAdmin III-ra, linux alá, de nem igazán találok. Nehezen tudom elhinni, hogy semmilyen más GUI nincs Linux alá, csak ez a hihetetlenül kényelmetlen bug halmaz.
(Mondjuk simán megkaphatná az ISO minősítést, mert ha kiakad valamitől, azt következetesen teszi, ha véletlenül van frissítés, utána is.)

  • 11037 megtekintés

( shark | 2013. 03. 24., v – 11:20 )

OFF
Én is szemezgetek a postgres-szel, mely funkcióival mi a baj?

Az öröklés egy olyan kiegészítése, amit (nem saját ötlet alapján) elég rendesen kihasználok. Sajnos ezt sem én sem a prostgresql fejlesztői nem gondolták végig. Az egész öröklés átgondolatlan, kidolgozatlan és befejezetlen, valamint gondolom nem véletlenül szinte senki sem használja.
Az elején az adattáblákat sémákba csoportosítottam, erről is hamar kiderült, hogy a sémákat jobb kerülni.
Az extra adattípusok kezelése is elég nagy szívás pl. Qt-ben.
Az egyetlen admin GUI-val (pgAdmin III) képtelen vagyok megbarátkozni, a leg utálatosabb GUI amivel valaha találkoztam, azon túl, hogy tele van hibával.
Nem akarlak lebeszélni a használatáról, de az extrák kihasználását ezerszer gondold meg.

Azért a schema támogatás ne legyen már olyan hú de nagy igény... Attól, hogy a MySQL-ben gyakorlatilag a schema és a DB szintje össze van mosva, attól még elég sok minden egyéb támogatja a schemakat.

Nekem inkább itt úgy tűnik, hogy nem a PostgreSQL-lel van gondod, hanem a hozzá kapcsolódó eszközök gyökérségével.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Elmondanád, hogy pontosan mi is a bajod az öröklődéssel?

Az állításod, hogy szinte senki sem használja az öröklődést
nem állja meg a helyét, nagyon sokan használják, mert egy "pont"
után csak azzal tudod optimalizálni a műveleteket és az adatbázis
szerkezetet.

Az sem állja meg a helyét, hogy átgondolatlan és kidolgozatlan..
bár nyilván fejleszthetnének rajta.. még.

Ne vedd zokon, de én azt látom, hogy kezdő szinten mozogsz ami a
postgres-t illeti.. (a GUI-s használat is erre vall) és lehet, hogy
fikázás helyett érdemes lenne kérdezned fórumokon ha valamit nem értesz,
nem tudod, hogyan kell megcsinálni.

Egyrészt a fejlesztő(k) (ill. a dokumentáció írója) tesz egy olyan megjegyzést, hogy ez egy nem befejezett dolog, és majd egyszer (ezt a 8.x-ben írták, de a 9.x-ben még nem jött el az a majd egyszer).
Konkrétan ami nem tetszik (ez itt vélemény lesz, és tényleg nem vagyok profi adatbázis zsonglőr):
Ha "a"-ból öröklődik "b", akkor nem öröklődnek a szabályok, "b"-ben minden szabályt, és kulcsot újra kell definiálni, nincs biztosítva, hogy az "a"-ban lévő egyedi kulcs "a"-ban és "b"-ben is egyedi legyen. Öröklődnek viszont a DEFAULT értékek oda-vissza, vagyis "b"-ben megváltoztatva megváltozik "a"-ban is.
Nem tudok olyan távoli kulcsot definiálni, ami távoli kulcs "a"-ra és "b"-re is.
A fenti tulajdonságok miatt írhatok egy rahedli triggert, ami idő, és sok-sok hibalehetőség.
Lehet, hogy a fenti tulajdonságok logikusak, de ezt nem látom be, és az általam modellezett valóság szelet, amit bele akartam tuszkolni az adatbázisba, sok szempontból fordított logikát kívánt.
Esetleg mondhatnál példát (ha van publikus) az öröklés kihasználására, had tanuljak (már amennyiben ez cél). Arra ügyesen rámutattál, hogy pancser vagyok, de mit lehet tudni, hátha nem reménytelen eset, így akár érvelhetnél amellett is, hogy az öröklés miért jó úgy, ahogy megcsinálták. (Link is jó lesz.)

Amit az egyedi kulcsnál írtál, nehéz tudom értelmezni.. amennyiben örököltetsz, akkor érdemes csak a parent táblánál megadnod az index-eket és primary kulcsokat, már csak azért is, mert lekérdezéskor a postgres nem használja a child táblákon létrehozott index-eket (Ez relatíve egy hiba lehet..). Azonkívül lehet szintén nem jól értelemeztelek.. de egy kulcs mező elég a tábla szerkezetben (parent-child), elég csak a child táblában felvenni a kulcs mezőt, sőt nem is célszerű a parent-ben.

Nem használok se távoli kulcsot, se triggert sehol.. mert sok esetben csak fölösleges overhead, ill. komoly probléma a hordozhatóság és particionálás/klaszterezés szempontjából mind a kettő.. és megmondom őszintén nem tudom, hogy mik a buktatóik öröklődés esetén.

Bocsánat, nem pancsereztelek le.. és meg is értelek, nekem akkor volt ilyen élményem mikor MS-SQL szervert kellett használnom.

CREATE TABLE statikus_adatok (nem, vagy nagyon ritkán módosulnak)
(
insert ,
id ,
topic
);

CREATE TABLE statikus_nagy_adat ( > 8196 || postgresql & fájlrendszer block méret )
(
adat
);

CREATE TABLE dinamikus_adatok (gyakori módosítás UPDATE ONLY utasítással)
(
status1 ,
status2
)
INHERITS ( statikus_adatok, statikus_nagy_adat );
--
ALTER TABLE dinamikus_adatok ADD CONSTRAINT id_ PRIMARY KEY ( id );
--
CREATE INDEX topic_ ON dinamikus_adatok ( topic );
...

Nem mondtam, hogy teljesen jól van megcsinálva az öröklődés, van pár hibája (lásd index),
de sok helyen használják, mert nincs más.

Szerintem az a gondja az öröklődéssel, hogy egészen másra akarta használni, mint amire kitalálta. Ha jól sejtem, itt bejátszik még ORM és minden egyéb agysérülés, amivel megpróbálja összehozni a két egymással köszönőviszonyban nem lévő koncepciót (OOP vs relációs adatbáziskezelés).

Na azt megértem, hogy abból megy a szipiszopi.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem biztos, hogy értem, mit akarsz mondani, de ha méltó vagyok esetleg arra, hogy valaki legalább utal rá, hogy mire is jó akkor a psql-ben az öröklés, ha az OOP-hez semmi köze? Ez tényleg érdekelne, szívesen tanulnék a hup szakértőktől (de önismereti továbbképzést inkább nem kérnék :).
Egyébként nem ezzel van a szopás, az API-mban és trigger függvényekkel jórészt megoldottam az örökléssel kapcsolatos problémáimat (ez már múlt idejű szopás). A (jelen idejű) szopás - most már bátran ki merem jelenteni - a hihetetlenül szar (legalábbis adat manipulációra teljesen alkalmatlan) pgAdmin III-al van, aminél ráadásul nincs jobb.

Szerintem a postgreSQL öröklésnek leginkább a táblapartícionálásnál van értelme, bár még így is eléggé esetlen...

"szopás - most már bátran ki merem jelenteni - a hihetetlenül szar (legalábbis adat manipulációra teljesen alkalmatlan) pgAdmin III-al van, aminél ráadásul nincs jobb."

Azért elhangzott itt már pár alternatíva. Azokat megnézted?

Igen megnéztem egy párat.
Ezek egy része nem alternatíva, azzal nem érek semmit, ha olyan programot használok, ami nem tartalmazza azokat a lehetőségeket, amit a kifogásolt program ugyan tartalmaz, csak nem működik.
Másik része még azt is feltételezi, hogy az adatbázisomat majd vele fogom létrehozni, úgy ahogyan azt ő elképzelte. Én a meglévő adatbázisomban szeretnék matatni, nem pedig elölről kezdeni mindent egy másik koncepció alapján.
phppgadmin pont annyira kényelmes, mint a pgAdmin III, ráadásul webszerver PHP is kéne feltenni az SQL szerver mellé, és nem igazán bízom benne, hogy abban menni fog minden.
Windows only programot nem szívesen használok Linux alól (egyet kipróbáltam, abban implementálták a pgAdmin III egyes bugjait is lsd.: kiabálós hozzászólásom).
A ODBC-s, jDBC-s ill. java-s verziók kipróbálását hanyagolnám. Nem hiszem, hogy túl sokra mennék velük a postgreSQL-es extrákkal.

Mint már írták, táblaparticionálás, amennyire én tudom. A doksiban is inkább ilyet említenek példának (capitalok elkülönítése a "sima" városoktól - bár tény, hogy elég szűkre veszi), meg amennyire láttam cikkeket erről a funkcióról. Igazából egy helyen nem láttam még példának az OOP nyelvbeli osztálymodellel való megfeleltetést, de gyanítom azért, mert nem a relációs adatbázis-kezelők részéről van törekvés az ORM-re, hanem az OOP nyelvekről. (Szvsz téves koncepció, de mindegy).

Ui.: nem veszel te egy kicsit sok mindent magadra?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ami probléma, hogy a legtöbben az öröklődés szóra rögtön objektum orientáltságra
asszociálnak, pedig semmi köze hozzá.. de gondolom valahogy nevezni kellett a "gyereket".

Egyáltalán nem téves koncepció, jó pár RDMS-ben (pl. Oracle) van "öröklődés", és valóban
arra való, hogy egy táblát szegmentálj, hogy optimalizálni tudd az adatszerkezetet, az SQL
és IO műveleteket, stb.

"Ami probléma, hogy a legtöbben az öröklődés szóra rögtön objektum orientáltságra asszociálna"
Sőt a postgreSQL dokumentációjának az írója is pont erre asszociál, ha esetleg a kedves olvasónak ez nem jutott volna eszébe. A "5.8. Inheritance" címszó alatt még utalás sincs a particionálásra, hacsak az nem, hogy a következő címszó a particionálás. Van egy másik címszó a "3.6. Inheritance" itt még az sem igaz, hogy a közelben lenne szó particionálásról.
Én némi ellentmondást vélek felfedezni a doksi és a Te értekezésed között, már ha mindkettőt sikerült felfognom.
Egyébként ha az ember fia C++-ban ír programot, és relációs adatbázist kezel, akkor az eleve rossz koncepció. Ebben az esetben azoknál az adattábláknál, amiknek a rekordjai létező dolgokat vagy fogalmakat reprezentálnak 1-1 megfeleltetést csinálok azon C++ objektumokkal, amik ugyanezeket a dolgokat vagy fogalmakat reprezentálják. Ezen objektum pároknál kézenfekvő volt ugyan azt az öröklési vonalat implementálni az adatbázisban és a programban is. És igen a postgreSQL-ben az öröklés működése nem igazán ezt támogatja, de nem is tesz keresztbe (nekem hiányosnak tűnik az implementáció, mintha nem tudták volna eldönteni melyik koncepciót támogassák).

Bocsánat, azt kell mondanom igazad/igazatok van..
.. én csak azt tudom mondani a tapasztalatom alapján, hogy akármi is
volt a cél a Postgres-nél a table inheritance-val (direkt nem írok öröklődést),
a legfontosabbak azok az előnyök amiket fentebb már leírtam.

Amiért írtam amit írtam, mert megmondom őszintén, én soha nem asszociáltam
OOP-re az "inheritance" kapcsán, de alapvetőn végül is igazatok van, arra hajaznak
azt ezt megvalósító adatbázis-kezelők, aztán valakinek van vagy ideje és utána olvas,
vagy nincs és jön a cimbi, Torkos Borz.

Ennyi.. én már lerágtam minden csontot a témáról.

( tovis v | 2013. 03. 24., v – 14:05 )

sqlmaestro? Nem látom van-e Linux verzió, de simán elfutkározhat emulátor alól.

* Én egy indián vagyok. Minden indián hazudik.

( gyrgyvrs | 2013. 03. 24., v – 16:39 )

Nézted már a ezt az oldalt?
Amúgy replication az MSSQL-el összehasonlítva szerinted milyen a PostgreSQL-ben?

( jailhouse v | 2013. 03. 24., v – 17:29 )

Mi a baj a PostgreSQL-el?

----------------------------
Előnevelt csirke kapható!

( saxus | 2013. 03. 24., v – 18:36 )

pgAdminnál nem nagyon tudok jobbat PostgreSQL-hez. Mi az, ami igazán hiányzik belőle?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Csak néhány apróság.
Máig nem jöttem rá (igaz nem sokat kísérleteztem) hogyan lehet egy táblában több sort kijelölni, és például egynél több sort törölni.
Ha egy sort törlök, arra még nem volt precedens, hogy utána nem szált volna el.
Nem jelzi a NULL értékű mezőt.
Tábla megjelenítésénél az oszlopok méretezése minden, csak nem intelligens.
Ha egy nagy (sok mezőt tartalmazó) táblát megjelenítek, akkor az utolsó oszlopot csak akkor lehet átméretezni, hogy lássam rendesen mi van benne, ha akkorára nyitom az ablakot, hogy az nagyobb legyen mint a táblázat, és ez elég gáz ha ez a méret többszöröse a képernyőnek.
Lehet rendezni oszlop szerint, de valljuk be ennél van kényelmesebb megoldás is, mondjuk egy kattintás.
A szűrési feltételek megadására is láttam már barátságosabb megoldást.
Ha nem szabályosan lépek ki - mivel szokása kiakadni, ez elő szokott fordulni - nem jegyzi meg a szerver kapcsolatokat. A következő induláskor ott virítanak a már törölt kapcsolatok, és az aktuális meg sehol. Ezeket direkt menteni vagy nem lehet, vagy nem tudom hogy hol.
Van egy pár szép nagy függvényem. A functions alatt össze vannak hányva a contrib és a saját függvények, amit semmiképpen nem neveznék kényelmesnek.
Ha hiba van egy függvényben, akkor megkapom, hogy hanyadik sorban van a hiba, de ha csak a függvény definíciót nézem meg, akkor nincs sorszámozás, az editor ablakba ugyan vannak sorszámok, de az nem azonos a hiba üzenetbeli sorszámmal, mindig úgy kell számolgatni, hogy hol is a hiba.
Linux-ban két módszer van a copy-paste használatára, a csak egérgombokkal működő a pgAdmin III-ban valamiért nem működik.
Stb...
Stb...

Mondjuk a hibák egy részénél lehet ott a gond, hogy én általában mindig a queryt szerkesztem és nem a GUI-val játszadozok.

"Ha nem szabályosan lépek ki - mivel szokása kiakadni, ez elő szokott fordulni - nem jegyzi meg a szerver kapcsolatokat. "

Ez fura, ilyen nekem soha nem volt.

"A functions alatt össze vannak hányva a contrib és a saját függvények, amit semmiképpen nem neveznék kényelmesnek."

Detto, nálam mindig egy pg_catalog-ban van benne a gyári.

"Ha hiba van egy függvényben, akkor megkapom, hogy hanyadik sorban van a hiba, de ha csak a függvény definíciót nézem meg, akkor nincs sorszámozás, az editor ablakba ugyan vannak sorszámok, de az nem azonos a hiba üzenetbeli sorszámmal, mindig úgy kell számolgatni, hogy hol is a hiba"

Debugger?

"Linux"

Mondjuk számomra a Linux meg a GUI együtt az elfogadhatatlan egyveleg, OSX-en, Windowson nem volt másolással gond.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egy minőséginek titulált programban, ha benne van egy lehetőség, akkor talán elvárható, hogy működjön is.
Jelenleg fejlesztés alatt áll mind az adatbázis, mind a program ami kezeli ill. karbantartja.
Fejlesztéskor előfordul, hogy ezt azt át kell írni az adatbázisban, pl. most is újra generáltam a scriptekből az egész adatbázist, és elfelejtettem egy mező értéket átírni a scriptben, az aplikáció persze dobott egy hátast. Nekem ne mondja senki, hogy egy 22 rekordot tartalmazó táblában egy tömb típusú mezőhöz hozzáírni egy lefelejtett tömb elemet nem egy működőképes és kényelmesnek titulált GUI-val a legegyszerűbb kb. két kattintással (a fölötte lévő tömböt kellet volna bemásolni ide is).
A csudálatos és kényelmes pgAdmin III erre a műveletre Ubuntu 12.04 alatt lefagy.
A windows-os verzió szintén lefagy. Kíváncsiságból kipróbáltam a windows-on futó kereskedelmi, nem ingyenes igaz demó SQL Manager for PostgreSQL (EMS) programot, EZ UGYAN ÚGY LEFAGY !!!!!! eme ördögtől való műveletre. Ha ez nem szánalmas akkor semmi.

Általában kerülöm a tömb típusú mezők használatát, de néha jól jön, ha már van olyan. Olyat nem csináltam, hogy tömb elem relációban is részt vesz, de a minket körülvevő világ túl változatos ahhoz, hogy kijelentsük ennek semmilyen körülmények között nem lehet értelme.
Ha annyira ördögtől való a tömb típus, hogy erre teljesen érthető a pgAdmin III kiakadása, akkor talán a postgreSQL-be sem kellett volna beletenni, és ebben az esetben én sem használnám.

"Máig nem jöttem rá (igaz nem sokat kísérleteztem) hogyan lehet egy táblában több sort kijelölni, és például egynél több sort törölni."

Egér nyomva tartása mellett ki kell jelölni az egész törlendő tartományt, nem elég csak pl. egy attribútumot.

"Van egy pár szép nagy függvényem. A functions alatt össze vannak hányva a contrib és a saját függvények, amit semmiképpen nem neveznék kényelmesnek."

Én sémázva alakítottam ki az adatbázissémát, és így csak az adott séma függvényeit listázza ki. A többi függvény a pg_catalog alatt van.

Köszi, a kijelölés tényleg megy, ahogy Te mondod. Én mindig a kattint a kijelölendő elejére, shift-et lenyom és kattint a végére módszert próbáltam, arra viszont olyan idióta módon reagál, hogy elment a kedvem a próbálgatásoktól.
A sémákat az API-m ugyan támogatja, de próbálkoztam néhány tervező programmal, és azok egyike sem támogatta a sémát, így mindent a public-ba tettem. Mondjuk az öröklődés (csak szerintem szar) megvalósítása miatt egyik tervező program sem használható az adatbázisomhoz, így akár sémázhatnék is, de már nincs kedvem átírni az adatbázist.

Igen, lényegében erről van szó.
Idéznék a postgresql doksijából (http://www.postgresql.org/docs/9.1/static/tutorial-inheritance.html a cím utáni első mondat):
"Inheritance is a concept from object-oriented databases. It opens up interesting new possibilities of database design."
Ezek szerint az "object-oriented" teljesen mást jelent programozáskor, és adatbázis kezeléskor? OOP-ben elég öreg motoros vagyok, adatbázis kezelésben viszont nem.
És újra leírom: Az öröklődéssel kapcsolatos szívásoknak nagyjából vége, az adatbázis szerkezete közel végleges, és az API-ban is lekezelem az eddig felmerült nyűgöket. Lehet, hogy félreértettem a postgresql koncepcióját, de azt nem látom, hogy az adott feladatot hogyan lehetett volna lényegesen jobban megoldani (már ami meg van oldva).

Inkább úgy fogalmaznék, hogy az ORM egyik tévképzete az, hogy az adattáblák rekordjai és az objektumok 1=1 kapcsolatban reprezentálhatóak. Ld.

[/code]class Bar {}

class Foo
{
public Bar[] Bars { get; set;
}[/code]

Ilyen az SQL-ben nincs, ezt kapcsolótáblával vagy a "bars" táblában egy "fooid" mezővel + külső kulccsal oldjuk meg. (Attól függ mi a cél).

"Ezek szerint az "object-oriented" teljesen mást jelent programozáskor, és adatbázis kezeléskor? "

Amennyire én tudom nem totálisan mást (mert az öröklődés fogalma az OOP-ből ered), de más a célja. De OODBMS-ek kapcsán nekem sincs elég ismeretem. Mindenesetre nem jutott volna eszembe erre használni az öröklődést már csak azért se, mert abból fájó pontok tudnak lenni, ha 1-1-ben próbálom megvalósítani mindkét helyen a modellem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igaz, hogy alkalmazom az 1-1 megfeleltetést, de csak akkor ha van értelme.
Ahol nincs ennek értelme, ott nem görcsölök az 1-1 megfeleltetéssel.
Van egy bázis objektumom, ami ezt az 1-1 megfeleltetést végzi (kiszedi az adatbázisból a tábla tulajdonságait, és ez alapján képez interfész az adatbázis, és az API megfeleltetett objektumai között), de vannak kapcsoló tábláim is, amikre eszembe se jutott ezt alkalmazni, mert nem lehet.
És van egy jó pár objektum ami egyáltalán nem illeszthető ebbe az 1-1 megfeleltetős koncepcióba. Feladatokat próbálok megoldani/kódolni, nem pedig ugyanazt a kaptafát rákalapálni mindenre.
A postgresql doksiból én azt olvastam ki, hogy erre is jó lesz, persze az ördög mindig a részletekben van. És tulajdonképpen jó lett erre is, csak amiatt a fránya részletek miatt, nem lett túl szép.

( jsaak | 2013. 03. 24., v – 20:06 )

tudom gui-t keresel nem cli-t
de a helyedben inkabb megtanulnam a cli-t hasznalni
ott működni fog minden, és meglepően hatékony tudsz lenni egy idő után

Tulajdonképpen egyet is érthetnék, de jelenleg eléggé el vagyok havazva a project-el, és ilyenkor egy kényelmes, kézre álló eszköz igen jól jönne.
Vegyesen szeretem használni a GUI-t és a CLI-t, van amit GUI-ban rémálom megcsinálni, van amit pedig abban egyszerűbb. Ha egy rekordot törölni akarok, azt azért egy-két kattintással jobb a GUI-ban.
Mondjuk, ha ugyanolyan lenne egy SQL parancsot, vagy ne adj isten függvényt begépelni mint pl. a qtcreatorban kódolni, akkor az kényelmes és kézreálló lenne, de egy notepad kaliberű szerkesztő minden csak nem kényelmes.
Persze lehet hogy csak elkényelmesedtem, írtam én programot vagy 30 évvel ezelőtt is, pedig akkor ilyenekről még álmodni sem lehetett.

( pityulaman1983 v | 2013. 03. 25., h – 10:40 )

Eléggé offtopic, de fontos lehet.
Sok olyan alkalmazás van, ami az adatbáziskezelő-rendszerek használóinak életét hivatott megkönnyíteni, code completionnel, syntax highlighttal, miegyébbel.
Viszont a lapozható resultset nevű featurerel vigyázni kell. Ezt több programnál láttam default settingként. Ami a gond vele, hogy amikor lefut a lekérdezésed, akkor mintha sleepre tenné X rekord után.
SQL Serverben a következőképp néz ki az egyik alkalmazás által futtatott lekérdezés:

SET FMTONLY OFF;
SET NO_BROWSETABLE ON;
SELECT mezo1, mezo2, ... , mezon FROM database.schema.table;
SET NO_BROWSETABLE OFF;

Ennek pedig az az eredménye, hogy amíg be nem zártad az alkalmazásban a fület, addig a table nevű tábla lockolva van írásra (persze SQL Serverben használhatsz table hint-ot, de pl MySQL-ben nem). Mindemellett nyilván azt írja a szoftver, hogy Query completed, pedig igazából nem. Szóval telepítés után mindenki jól bogarássza át a beállításokat és inkább limit és top utasításokkal limitálja le a rekordok számát.

-----------
"640GB sokmindenre elég"

( szipka | 2013. 03. 26., k – 09:26 )

Nekem az egészből az jött le, hogy hiányos adatbázis ismeretek, és a dokumentáció félreértelmezése alapján, arra használsz valamit amire nem való, és szidod a rendszert, meg az eszközt, hogy nem működik rendesen amire te szeretnéd. És ahelyett hogy dobnád az eredeti hibás elképzelést, mindenféle eszközt keresel ami ideiglenesen áthidalja a problémád. Nem tudom kinek készíted a szoftware-t, de csak sajnálni tudom, a végeredmény nem lehet jó. Ha már olyan régen a szakmában vagy akkor tudhatnád, hogy minden dokumentáció hazudik, csak az az igaz amit kipróbáltál, és az se mindig, ezért kell készíteni prototípusokat amiben leegyszerűsítve leteszteled a funkciókat. És nem szabad semmihez sem ragaszkodni, bátran ki kell dobni ami ami nem megfelelő. Ami csak félig jó az nem jó, mert a jövőben pont arra a felére lesz szükség ami nem működik.

Azért, ha elolvasnád és felfognád a leírtakat, akkor nem biztos hogy ez jönne le.
Itt ugye két dolog van:
Az táblák öröklődése, és az OOP kapcsolata, amit többek szerint félreértettem és amire a postgreSQL dokumentációja is utal (nem arra utal, hogy félreértettem, hanem arra, amit én is gondoltam). Az erre vonatkozó pampogásomat (igaz így konkrétan ezt eddig nem írtam le) de visszavontam. A postgreSQL implementációja olyan amilyen, én meg erre használtam, a végeredményt nem ismered, talán nem kéne véleményezni sem (nem említettél látnoki képességeket a profilodban, ha mégis lenne, akkor bocs).
A másik dolog - a gyengébbek kedvéért a címben is szerepel - az, hogy a pgAdmin III használhatatlan, BUGOS, KIAKAD, LEFAGY. Nem azért mert én hülye vagyok és félreértettem valamit, hanem mert szarul írták meg.
Teccik érteni ?? Az égadta de világon semmi köze ahhoz, hogy félreétettem-e valamit vagy sem.
Persze, lehet hogy tényleg Én vagyok a mesüge, és valahol a doksiban leírták, hogy ha a pgAdmin III-ban törlök egy rekordot, akkor teljesen normális hogy kiakad, és ez nem hiba, hanem fícsőr. Ugyanígy csak pedagógiai jelleggel szál el ha tömb típusú elemet próbálok módosítani. A kijelölések körüli néhány furcsaság pedig valójában intelligencia teszt, amin ráadásul megbuktam.

Milyen verziójú pgAdmin III-at használsz? Win 7-en kipróbáltam az 1.14.2-őt és ezzel GUI-ból lehet szerkeszteni array típusú mezőket is. Ha valamit elrontottam, akkor hibaüzenetet adott, nem omlott össze.

Egyébként nem lehetséges, hogy a "lefagyások" oka a tranzakciókezelésből származó lock?

Amit aktívan használ(nék) az 1.14.0, és Ubuntu 12.04.2, megnéztem, és semmilyen frissítés nincs postgresSQL-el kapcsolatban.
Kollégám egy kliens programot reszel a rendszerhez, windows 7 alatt, nála a pgAdmin III verziója 1.14.3.
Nem próbáltunk ki mindent, ami az enyémet kiakasztja, de a tömb típusú mező módosítása mindkettőnél kiakadást okozott, sőt az EMS hasonló programja is lefagyott erre.
Kollégám ép most töltötte le a Win-es 1.16.1-es verziót, átment az első teszten.
Akkor szidjam inkább az Ubuntu-t ?

UI.: Frissítettem az Ubuntu alatt is, 1.16.1-ben eddig nem jelentkeznek az 1.14.x hibái, még a kijelölésnél sincs meg a fentebb említett intelligencia teszt. Szóval akkor inkább az Ubuntu szívatott, egyetlen mentsége, hogy nem támogatottnak jelöli. Mondjuk szeretni ezután sem fogom, de a lényeg, hogy így legalább használható.

UI2: A link a frissítéshez, ha valaki szintén Ubuntu-t használna: http://www.postgresql.org/download/linux/ubuntu/

OK. Igazat kell adjak.
De azért Ubuntuék is be...ják, hogy a hivatalos repóba nem tudnak évekig frissíteni egy bugos programot.
Ja, és a Postgres-is, mert a Windows-hoz adott legfrissebb fullos csomagjukba szintén egy régi bugos komponenst raknak.
És így születnek a "legendák" arról, hogy ez vagy az a program szar. Nem szar az csak már megint belefejlesztettek egy kis intelligencia tesztet. Azért valljuk be őszintén ezekre a tesztekre nem mindig vagyunk vevők.

( csfeco | 2013. 07. 25., cs – 10:30 )

ÁÁÁÁÁÁÁÁ !!!
Ma, ahelyett, hogy begépeltem volna egy SQL UPDATE utasítást, ami kevesebb mint száz leütés, már megint arra vetemedtem, hogy egy rekordot a tábla nézetben próbáltam meg módosítani. Először nem értettem, hogy lehetek olyan "ügyes", hogy ötödször is elírom a mező tartalmát. Hát nem én cseszem el, hanem a mező szerkesztésénél hibásan pozicionálja a kurzort. Egy karakterrel előbbit töröl, vagy szúr be.
Nem, nem régi szar verziót használok, hanem egy friss szar verziót.