Gelöst Wieso tpk Tabelle für primary keys? - Datenbank Design

[Tobi_G]

Hallo liebe Leute,

wie der Titel schon beschreibt arbeite ich momentan mit den stored procedures der Datenbank und versuche meine Importe direkt damit zu machen.
(Ich weiß, bevor es jemand wiederholt: Böse, Aus, schlechte Idee!, aber es eigenet sich gerade gut für das Problem das ich habe und ich bin auch vorsichtig und mache immer Backups).

Bei einem normalen Import der Ameise habe ich mit dem SQL Profiler die SQL Statements mitgeschnitten und darin des öfteren den Aufruf der SP "spGetandUpdatePK" gesehen, was scheinbar nichts anderes tut als in der Tabelle "tpk" den Zahlenwert des nächsten primary Keys zurückzuliefern und diesen zu inkrementieren. Meine Frage an dieser Stelle ist: Wozu macht man das? Wäre es nicht viel einfacher und logischer die Tabellen mit einem normalen "auto inkrement" anzulegen?
Wenn man dann den PK für diesen Eintrag benötigt kann man doch das gleiche select auf diese Tabelle machen anstatt die tpk zu fragen? Führt diese doppelte Buchführung des PK nicht auch zu Problemen? Redundanzen sollte man doch vermeiden oder nicht?

Falls ich die Frage in einem falschen Teil des Forums gestellt habe, dann tut es mir leid, ist erst mein zweiter Post hier.

Wünsche allen noch schöne Tage und einen guten Rutsch ins Neue Jahr.

TG

 

[MartinK]

Das ganze ist aus historischen Gründen gewachsen. Bei allen neueren Tabellen verwenden wir tPk seit einigen Jahren nicht mehr. Grundsätzlich sollte aber wenn man auf eine tPk Tabelle stößt der Weg über die SP gegangen werden weil diese eine exklusive Sperre setzt und damit verhindert dass man fehlerhafte Werte in den Pk schreibt.

 

[Tobi_G]

Das ganze ist aus historischen Gründen gewachsen. Bei allen neueren Tabellen verwenden wir tPk seit einigen Jahren nicht mehr. Grundsätzlich sollte aber wenn man auf eine tPk Tabelle stößt der Weg über die SP gegangen werden weil diese eine exklusive Sperre setzt und damit verhindert dass man fehlerhafte Werte in den Pk schreibt.

Zuerst mal die wichtigste Frage: Gibt es einen einfachen Weg die PKs auf 1 zurückzusetzen?
Ein update für die tabelle tpk (set nummer = 1) scheint nicht die ganze Lösung zu sein.
In einer der stored procedures bin ich über den aufruf "scope identity" gestoßen der anscheinend für den gesamten aufruf den zuletzt benutzen primary Key zurückliefert und da scheint es noch ein paar mehr Tabellen zu geben.
Wenn ich bei all diesen Tabellen die Werte lösche und den tpk auf 1 setze habe ich dann alle voraussetzungen um neue Kunden oder Aufträge anzulegen mit primary key beginnend bei 1? Muss ich rein theoretisch den tpk überhaupt anfassen wenn ich jeden Kunden oder Auftrag selbst anlege üder die Datenbank? (Natürlich wäre das empfehlenswert die Tabelle mitzupflegen aber ich würde gern wissen ob das zwingend notwendig ist weil ein anderer Teil darauf zugreift außer die Bereiche die Kunden / Auftrage neu anlegen)


Dann nochmal die Frage: Gibt es designtechnisch Argumente für das benutzen der tpk Tabelle? Oder würdet ihr das bei einer kompletten Neuprogrammierung weglassen? Gilt das selbe auch für "tlaufendeNummern"?
Und wie sieht das best practice für den Anwendungsfall eigentlich aus? So wie ich gesagt hatte "auto increment"?

Sorry für so viele Anfängerfragen im Bereich Datenbanken.
Und allen die das Lesen nochmal ein Frohes neues Jahr

TG

 

[Stetto]

Hi,

wie Martin schon schrieb, handelt es sich um eine historische Tabelle. Alle neuen Projekte "Auftrag 2.0", "Rechnung 2.0", "Kunde 2.0" etc. verwenden diese Tabelle nicht mehr.

Die tPK wird in naher Zukunft also komplett entfallen und wird nicht weiter genutzt werden.

Ansonsten die Stored Procedures verwenden, um noch mit Version 1.5 und älter einen Auftrag oder ähnliches anzulegen oder verändern.

Falls es eine sehr umfangreiche Eigenentwicklung wird, kann ich nur dringend empfehlen, auf die Version 1.6 zu warten, sonst werden ihr voraussichtlich noch einmal komplett von vorne beginnen.

 

[Tobi_G]

Hi,

wie Martin schon schrieb, handelt es sich um eine historische Tabelle. Alle neuen Projekte "Auftrag 2.0", "Rechnung 2.0", "Kunde 2.0" etc. verwenden diese Tabelle nicht mehr.

Die tPK wird in naher Zukunft also komplett entfallen und wird nicht weiter genutzt werden.

Ansonsten die Stored Procedures verwenden, um noch mit Version 1.5 und älter einen Auftrag oder ähnliches anzulegen oder verändern.

Falls es eine sehr umfangreiche Eigenentwicklung wird, kann ich nur dringend empfehlen, auf die Version 1.6 zu warten, sonst werden ihr voraussichtlich noch einmal komplett von vorne beginnen.

Danke Stephan für deine Antwort,

die Anwendung ist nicht besonders groß, daher sollte es eigentlich kein Problem sein sie auf die neue Version anzupassen, vor allem die Vergehensweise jetzt klar ist.

Ich verwende auch die stored procedures, die ich über SQL Profiler mitgeschnitten habe bei einem Import der Ameise.

Natürlich würde ich gerne noch mehr wissen dazu, aber ich weiß deine Zeit ist begrenzt und ihr müsst auch nicht jedes Geschäftsgeheimnis ausplaudern ^^

Daher, danke nochmal für den Hinweis, ich werde Version 1.6 im Auge behalten.

Viele Grüße

TG

 

[Stetto]

Och, schau mal bei GitHub oder auch wawi-db.jtl-software.de - wir haben gar nicht so viele Geheimnisse. Primary Keys, so wie sie heute genutzt werden, gab es damals schlicht noch nicht. Es hat keinen besonders klugen Hintergrund, wieso es diese PK-Tabelle gibt.

 

[Marc Völker]

Vielleicht noch als Kurze Anmerkung. Die Tabelle tLaufendeNummer, wird es natürlich weiterhin geben, da es sich dabei ja auch um Künstliche Nummern handelt. Wie eben Auftragsnummern etc. Aber auch für diese gibt es eine Stored Procedure, und bitte diese nutzen.

Wie Stephan schon schrieb, wird sich mit der 1.6 sehr viel im Bereich Auftrag ändern. Es gibt komplett neue Tabellen, mit teilweise anderer Struktur, und auch andere Zugriffs Schichten, um Daten in diese hinein zu bekommen.

 

[Tobi_G]

Vielleicht noch als Kurze Anmerkung. Die Tabelle tLaufendeNummer, wird es natürlich weiterhin geben, da es sich dabei ja auch um Künstliche Nummern handelt. Wie eben Auftragsnummern etc. Aber auch für diese gibt es eine Stored Procedure, und bitte diese nutzen.

Wie Stephan schon schrieb, wird sich mit der 1.6 sehr viel im Bereich Auftrag ändern. Es gibt komplett neue Tabellen, mit teilweise anderer Struktur, und auch andere Zugriffs Schichten, um Daten in diese hinein zu bekommen.

Ich benutze auch für alle Aufrufe bei denen ich eine stored procedure mit dem Profiler mitgeschnitten habe die jeweilige sp. Aber danke nochmal für den Hinweis. Das Konzept ist jetzt auch klar und bei Änderungen kann ich das nun leicht anpassen. Viele Grüße TG