Primary key nicht vorhanden

[bernhard_LA]

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.

[Jasocul]

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.

[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. :warn: Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...:zwinker:

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. :wink:

[Sinspin]

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.

[Uwe Raabe]

Zitat:

Zitat von bernhard_LA (Beitrag 1548629)

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.

[himitsu]

Zitat:

Zitat von haentschman (Beitrag 1548632)

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

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.

[Jasocul]

Zitat:

Zitat von haentschman (Beitrag 1548632)

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. :warn: Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...:zwinker:

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.

[TurboMagic]

Zitat:

Zitat von Jasocul (Beitrag 1548642)

Zitat:

Zitat von haentschman (Beitrag 1548632)

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. :warn: Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...:zwinker:

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.

[joachimd]

Zitat:

Zitat von TurboMagic (Beitrag 1548656)

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...

[TurboMagic]

Zitat:

Zitat von joachimd (Beitrag 1548661)

Zitat:

Zitat von TurboMagic (Beitrag 1548656)

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.

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1548668)

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 ;-)

Na ja, das kann bei Multi-User-Zugriff schon mal daneben gehen - es sei denn man legt einen Unique Key auf das entsprechende Feld.

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1548669)

Zitat:

Zitat von TurboMagic (Beitrag 1548668)

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 ;-)

Na ja, das kann bei Multi-User-Zugriff schon mal daneben gehen - es sei denn man legt einen Unique Key auf das entsprechende Feld.

Für den Multi User Zugriff gibt es eine Spalte mit dem Usernamen - jeder User sieht nur "seine" Eingaben. Angenommen, der eine gibt Ortsnamen in Norddeutschland ein und der andere in Süddeutschland, dann sind bei einem gemeinsamen Pool die zuletzt eingegebenen nicht zwingend die, die man haben wollte.

[bernhard_LA]

anbei die Fehlermeldung welche 2 User auf meiner DB nicht zulässt

( noch die alten SQL scripte , keine PK vorhanden )

[bernhard_LA]

Ich kann in meinem Code FireDAC und ADO Datenbank-Komponenten über eine Compiler Einstellung tauschen (Factory Pattern),
wird TADOQuery im Code eingebaut läuft alles prima, bei FireDAC bekomme ich obige Fehlermeldung.

Bin weiterhin für Inputs dankbar, will mir gerne die Option für bei DB Komponenten offenhalten, weil wenn's von WINx64 auf UNIX geht brauche ich ja FireDAC.

[Blup]

Wenn die Komponenten unbedingt einen Primärkey erfordern, warum nicht einfach einen PK für die betreffende Tabelle anlegen? Wenn sich kein eindeutiger natürlicher Schlüssel anbietet, einfach ein ID-Feld erzeugen.