Alternative zu LibreOffice Base als FrontEnd

Ich hatte versucht LibreOffice Base als FrontEnd für eine PostgreSQL-DB zur Dateneingabe zu nutzen.

Scheinbar ist LO aber schon damit überfordert Felder mit dem Datentyp “oid” automatisch zu befüllen.
Ich meine dieser Datentyp spricht ja für sich selbst. Es sollte klar sein, was damit geschehen soll. Wahrscheinlich stelle ich es mir auch zu einfach vor.

Gibt es ein anderes FrontEnd, dass für eine gute Zusammenarbeit mit PostgreSQL bekannt ist?

Oder habt ihr n Tip, wie ihr eigenen oid-Datentypen (als PrimaryKey) im FrontEnd handhabt?

Dein Frontend scheint das anders zu sehen.

Gibt es ein anderes FrontEnd, dass für eine gute Zusammenarbeit mit PostgreSQL bekannt ist?

Was möchtest du denn tun? Bei mir funktioniert auch Access wunderbar.

Oder habt ihr n Tip, wie ihr eigenen oid-Datentypen (als PrimaryKey) im FrontEnd handhabt?

[/quote]er
Ich würde sie anders nennen. Wie sieht der Datentyp überhaupt aus?

Gruß Uwe

Du weisst aber schon, dass oids seit Version 7.irgendwas deprecated sind? Warum verwendest Du die, und nicht eine “serial” oder “integer” Spalte?

Vor 1-2 Tagen war es doch nch PGAdmin. Oder? Was ist damit?

Scheinbar ist LO aber schon damit überfordert Felder mit dem Datentyp “oid” automatisch zu befüllen.

Das ist auch nicht dessen Aufgabe, weil das KANN es gar nicht. Davon abgesehen ist OID seit zig Jahren deprecated.

Ich meine dieser Datentyp spricht ja für sich selbst. Es sollte klar sein, was damit geschehen soll. Wahrscheinlich stelle ich es mir auch zu einfach vor.

Gibt es ein anderes FrontEnd, dass für eine gute Zusammenarbeit mit PostgreSQL bekannt ist?

psql, das CLI.

Oder habt ihr n Tip, wie ihr eigenen oid-Datentypen (als PrimaryKey) im FrontEnd handhabt?

Ja. Weglassen. Hatten wir aber auch schon.

“oid” musst du schon spezifizieren. Die Antwort zu diesem Thema in einem anderen Thread bezog ich auf das Konzept der internen (von PostgreSQL selbst erstellten und) verwendeten OIDs - solche mit “WITH OID” erzeugte.
Das dies auch für den Datentyp “oid” gilt, war mir nicht bewusst. Die Doku sagt nach meinem Englischverständnis auch nicht, dass es deprecated sei.

Was ist den der aktuelle (also in 9.4) empfohlene Datentyp für die Erzeugung eigener(!) Identifikations-Felder (aka PrimaryKey, oid, id, DingsBums, …) ?
Wichtig dabei ist natürlich auch, dass diese Felder automatisch inkrementiert werden, ohne dass irgendein User sie explizit befüllen müsste.

Das ich die PostgreSQL-internen OIDs nicht verwenden soll, hab ich verstanden.

pgAdmin hatte ich als FrontEnd für Managment-Aufgaben verstanden. Kann man damit etwa auch “hübsche” Formulare zur Dateneingabe erzeugen? Das war mir entgangen. Bisher kenne ich dort nur die klassische Tabellen-artige Dateneingabe.

Vielleicht gibt es hier Mißverständnisse weil ich den Begriff “OID” verwende. Komme nun mal aus der Objektorientierung und entwickle meine Datenmodelle aus dieser Perspektive.
Ok, nennen wir es besser PrimaryKey?

Was ist der empfohlene Weg (z.B. Datentyp), um in einer PostgreSQL-Tabelle ein PK-Feld anzulegen.
Wie ich aus einem oder mehrern Feldern einen PK mit einem CONSTRAINT mache, ist mir natürlich klar. Aber wie müssen die Felder beschaffen sein?

Tabellen mit LibreOffice oder auch Access füllen als “PrimaryKey” markierte Felder automatisch. Das tun sie auch bei der Dateneingabe über ein Formular. Den PK kann ich aus dem Formular rauslassen, jedoch wird er im Hintergrund automatisch erzeugt und mit abgespeichert.

Wenn LO das mit eigenen Tabellen kann, muss es das doch auch mit Fremdtabellen machen können. DIe Frage ist, welche Vorraussetzungen dafür gegeben sein müssen.

Die üblichen halt.

Libre office und Access füllen das auch nur automatisch wenn es entsprechend als ‘AUTO’ angelegt ist. Mehrspaltige PKs werden auch nicht automatisch gefüllt, wie auch, wenn die einzelnen Spalten nicht unique sein müssen. Unter Postgres macht das der Datentyp serial. Das erzeugt eine Integer-Sequence, die dann beim Insert hochgezählt wird. Die genaue Funktion kannst du dir im pgAdmin in der Spaltendefinition ansehen.
Gruß Uwe

Dickes Danke! “serial” lösst das Problem und auch LO kapiert es dann.

Aber nochmal ne Rückfrage: Hier wurde (nach meinem Verständnis) behauptet der Datentyp “oid” sei deprecated. In der 9.4er Doku ist dazu aber nix zu lesen. Wie ist da also nun der Stand?

btw: Baut jemand sein PostgreSQL zufällig selbst? Gibt es nen switch/build-option mit der man den ganzen post-9.4.-deprecated-Rattenschwanz abschneiden kann - also ohne deprecated Sachen bauen, so dass einer wie ich nicht gleich in die “Falle” läuft.

Du kannst mit configure Features und Packages an- und ausschalten.

Gruß Uwe

OID gibt es schon noch, jede Tabelle hat z.B. eine, wichtige Systemtabellen haben eine OID, z.B. pg_class. Man verwendet nur keine OID in jeder Tabelle für jeden Record.

Sorry, das ist schon wieder zu unspezifisch. Beziehst du dich auf das Konzept der internen-OIDs (WITH_OID), das Konzept der (z.B. von mir) expliziert angelegten oids (im Sinne von PrimaryKeys) oder auf den Datentyp “oid”?

Ganz spezifisch ist das hier erklärt: http://www.postgresql.org/docs/9.4/interactive/datatype-oid.html

Die Seite habe ich selbst schon verlinkt. Hier ist kein Wort von “deprecated” zu lesen.

Dann nehme http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html und erfreue Dich an:

“The use of OIDs in user tables is considered deprecated, so most installations should leave this variable disabled. Applications that require OIDs for a particular table should specify WITH OIDS when creating the table. This variable can be enabled for compatibility with old applications that do not follow this behavior.”

Das bezieht sich einzig und alleine auf das Konzept der internen von PostgreSQL selbst erzeugten OIDs.
Hier steht nix über den Datentyp “oid” oder selbst-erzeugte Felder im Sinne einer Identifikation bzw. PrimaryKeys.

Ja, und?

Was genau ist jetzt Dein Problem?

Willst Dich jetzt weiter zum Mops machen? Das Konzept, OID’s zu verwenden, ist schlicht und einfach deprecated. Alternativen wurden Dir genannt.

Sein Problem ist, das er etwas ‘OID’ nennt was im Sinne von pg kein ‘OID’ ist sondern ein banaler Primary Key. Wie ich in meinem ersten Post schon erwähnte, ist die Namenswahl verwirrend. qed.

Gruß Uwe