pgAdmin - read only weg machen OHNE PK

Guten Tag,

ich wollte seit 7 Stunden einen Eintrag einfügen und Selektieren, ging aber nicht da alle columns read-only waren bis ich germerkt habe dass ich ein Primary Key hinzufügen muss. Was mache ich wenn ich kein Primary Key nutzen möchte sondern Index? Dann wird mir wieder Read Only angezeigt. Hat jemand Erfahrung damit? Wäre wirklich dankbar für eure Hilfe

Ich weiß nicht genau was eine “read-only” Spalte sein soll. Aber Du kannst problemlos UPDATEs, INSERTs oder DELETEs ohne primary key machen.

create table foo (id integer, some_data text);

insert into foo values (42, 'bla');

update foo 
  set some_data = 'The answer'
where id = 42;

Was genau ist die Fehlermeldung die Du bekommst, wenn Du ein DML Statement laufen lässt?

Ja ich selber kann querys machen, aber wenn ich per backend ein INSERT sende, passiert nichts und es kommt keine Fehlermeldung. Read Only heißt dass man die Tabelle nur lesen kann mehr nicht. Bzw man kann kein Eintrag einfügen oder updaten

Dann ist das ein Fehler Deines Backends - dann musst im Code des Backends suchen warum der INSERT scheitert.

Tabellen sind nur dann “read-only” wenn der Datebankbenutzer nicht die notwendigen Rechte hat - eine andere Definition von “read-only” gibt es in der Datenbank nicht. Wenn Du manuell INSERT oder UPDATE machen kannst, Dein Backend aber nicht, dann verwendet Dein Backend vielleicht einen anderen Datenbankbenutzer der nicht die notwendigen Rechte hat (aber dann müsste es eigentlich eine Fehlermeldung geben)

Wenn Du Tools verwendest die das anders sehen, dann musst Du im Handbuch des Tools nachsehen, warum es eine Tabelle (oder Spalte) als read-only ansieht.

ich vermute das Problem im Backend, manche lassen editieren nur bei vorhandensein eines PK zu.

In meinem PG Admin Dashboard steht doch explizit das der Column Read Only ist, und wenn ich ein PK einfüge, steht da nicht mehr Read Only wie kann das jetzt am Backend liegen? Mir gehts nicht darum das er im backend kein Eintrag machen kann sondern eher warum da read only steht wenn ich kein Primary key einfüge.

Ach so, es geht um pgAdmin.

Ich verwende pgAdmin nicht, aber ich vermute es liegt daran, dass ein UPDATE oder DELETE Befehl nun mal eine WHERE Bedingung benötigt um den Datensatz eindeutig zu identifizieren. Ohne PK kann pgAdmin aber nicht wissen, welche Spalten das sein sollen und raten wäre auch eine dumme Idee.

Aber eine Tabelle ohne Primärschlüssel macht sowieso nicht wirklich Sinn - es sei denn mal will ausschließlich INSERTs und SELECTs (auf alle Datensätze) machen.

Warum definierst Du nicht einfach einen passenden Primärschlüssel?

Ich sage dir gerne Warum ich einen Primarschlüssel nicht definiere bzw nicht bei allen Tabellen.

Nehmen wir an ich habe eine Tabelle Domain und Domain_Check.

Tabelle Domain hat ein Primary Key mit dem Feld Domain_id.

So jetzt erstellen wir die Tabelle Domain_check und speichern die Domain_id und ein Boolean Wert true oder false (ob der check bestanden ist ) in die Felder rein.

Jetzt brauche ich bei Domain Check kein Primary key da die Domain ID öfters vorkommt und ich keine Felder erstellen möchte die ich nicht brauche (Wie jetzt in meinem Fall muss ich unnötig ein Feld mit der id erstellen und ein PK schlüssel einfügen) was sinnlos ist und die Performance schlechter macht da ich die Tabelle nicht brauche aber ohne PK geht es ja leider nicht. Hoffe du hast mich verstanden^^

Hmm, eine Tabelle in dieser Art:

domain_id | passed
----------+-------
        1 | true  
        1 | false 
        1 | true  
        1 | true  
        1 | true  
        1 | false 
        2 | true  
        2 | true  
        2 | true  
        2 | true  
        2 | false 
        2 | false 

sieht für mich merkwürdig aus. Unterm Strich weiß ich dann dass der Check mal erfolgreich ist und mal scheiter.

Und wie willst Du da einen einzelnen Datensatz ändern? Selbst wenn Du in der WHERE Bedingung domain_id und passed verwendest, würde es immer noch mehrere Datensätze ändern - und genau deswegen unterstützt das pgAdmin auch nicht.

Ich würde erwarten, dass es noch zusätzliche Spalten gibt, z.B. das Datum an dem der Check stattgefunden hat, oder eine Auftrags- oder Vorgangsnummer oder etwas ähnliches.

In dem Fall würde ich z.B. die Vorgangsnummer als weitere Spalte aufnehmen, und dann wäre der Primärschlüssel (domain_id, operation_id).

Aber ich hatte ja schon gesagt, dass in wenigen Fällen (z.B. bei “INSERT only” Tabellen) ein Primärschlüssel nicht unbedingt notwendig ist. In dem Fall musst Du halt damit leben, dass man einen bestimmten (einzelnen) Datensatz nicht mehr direkt ändern kann. Aber wenn man das machen muss, dann ist es eigentlich keine “INSERT only” Tabelle mehr.

generell solltest Du IMMER einen PK definieren. Bestimmte Features, die Du vielleicht mal später brauchst, erfordern einen. Logical Replication z.B. wird sehr unangenehm, wenn keiner verfügbar ist. Das Platz- / Performanceargument ist eher schmarrn hier.

Dein Client macht wahrscheinlich ein ‘select … for update’, um den Datensatz zu locken. Daher braucht es einen PK.