Muss eine Datenbank einen Primary Key besitzen, um einen Multi-User- und parallelen Zugriff zu ermöglichen?


Ich habe eine entsprechende Fehlermeldung für meine Datenbank erhalten, die keinen Primary Key definiert hat.

Eine Datenbank hat keinen PK.
Vermutlich geht es nur um eine Tabelle innerhalb der Datenbank.

Um deine Frage in diesem Sinn zu beantworten:
Für Multi-User und/oder parallelen Zugriff ist ein PK für eine Tabelle nicht erforderlich.

Zitat:

Für Multi-User und/oder parallelen Zugriff ist ein PK für eine Tabelle nicht erforderlich.

...aber JEDE Tabelle muß grundsätzlich einen haben. Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...

Zitat:

Ich habe eine entsprechende Fehlermeldung für meine Datenbank erhalten, die keinen Primary Key definiert hat.

...kann aber auch sein, daß ein Update z.B. nicht ausgeführt werden kann, weil keine Eindeutigkeit besteht...oder so.

Das hängt sicherlich von der verwendeten DB ab ob ein Primary Key zwingend erforderlich ist. Generell halte ich es für ein fragwürdiges Design wenn Tabellen ohne Keys betrieben werden.
Interessant wäre mal ob es DB gibt die keine expliziten Keys brauchen sondern alle Felder in allen Kombinationen automatisch indexiert sind.

Hatte im Studium mal eine Firma besucht die sich auf "read as fast as you can" DB spezialisert haben.

Zitat von bernhard_LA:

Ich habe eine entsprechende Fehlermeldung für meine Datenbank erhalten, die keinen Primary Key definiert hat.

Kannst du das Szenario etwas genauer beschreiben? Ich weiß, dass FireDAC unter bestimmten Bedingungen einen PK voraussetzt.

Das lässt sich zwar dann auch umgehen, macht aber die bereits vehement geäußerte Forderung nach einen PK nicht weniger wichtig.

Es fördert allerdings das Verständnis für die Interna von FireDAC, wenn man die wirkliche Ursache ergründet.

Zitat von haentschman:

...aber JEDE Tabelle muß grundsätzlich einen haben. Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...

Müssen muß nichts.

Wenn kein Zugriff auf Einzelnes und Doppeltes egal und keine Sortierung nötig, wozu soll dann der Index gut sein?
z.B. einer LoggingTabelle, die schnell gefüllt werden muß, dann bremst der Index auch.

Zitat von haentschman:

Zitat:

Für Multi-User und/oder parallelen Zugriff ist ein PK für eine Tabelle nicht erforderlich.

...aber JEDE Tabelle muß grundsätzlich einen haben. Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...

Ich habe die Frage im Sinne des Problems beantwortet.
Und wie Himitsu bereits schrieb, ist auch bei gutem DB-Design nicht immer ein Key/Primary Key erfoderlich oder sinnvoll.

Zitat von Jasocul:

Zitat von haentschman:

Zitat:

Für Multi-User und/oder parallelen Zugriff ist ein PK für eine Tabelle nicht erforderlich.

...aber JEDE Tabelle muß grundsätzlich einen haben. Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...

Ich habe die Frage im Sinne des Problems beantwortet.
Und wie Himitsu bereits schrieb, ist auch bei gutem DB-Design nicht immer ein Key/Primary Key erfoderlich oder sinnvoll.

Richtig, da gebe ich euch recht. Gerade für Fälle wo jemand nur die zuletzt eingegebenen Ortsnamen oder so
in der DB speichern will um beim nächsten Aufruf des DIalogs gleich Vorschlagswerte für den Ort anzubieten
muss man keinen PK haben.

Aber meiner Meinung nach betrifft das so ca. <= 1% der Anwendungsfälle von Tabellen.

Zitat von TurboMagic:

Richtig, da gebe ich euch recht. Gerade für Fälle wo jemand nur die zuletzt eingegebenen Ortsnamen oder so
in der DB speichern will um beim nächsten Aufruf des DIalogs gleich Vorschlagswerte für den Ort anzubieten
muss man keinen PK haben.

...und spätestens bei der Löschung von Dubletten hast du wieder ein Problem...

Zitat von joachimd:

Zitat von TurboMagic:

Richtig, da gebe ich euch recht. Gerade für Fälle wo jemand nur die zuletzt eingegebenen Ortsnamen oder so
in der DB speichern will um beim nächsten Aufruf des DIalogs gleich Vorschlagswerte für den Ort anzubieten
muss man keinen PK haben.

...und spätestens bei der Löschung von Dubletten hast du wieder ein Problem...

Ja, aber: man baut so eine Lookup Liste ja auch so auf, dass es nicht zu Doubletten kommt
Vorher prüfen, ob der Vorschlagswert schon vorhanden ist und nur wenn nicht dann speichern

Wie gesagt: in > 99,5% der Fälle sollte man einen key haben.