Sql Abfrage

hustbaer

secondsun schrieb:

Egal wie eindeutig eine Kombination aus zwei Spalten ist, es ist ratsam immer eine ID Spalte zu beginn hinzuzufügen, welche automatisch hochgezählt wird.

nein

Wieso nicht?

tntnet

wieso nicht? schrieb:

Wieso nicht?

Die Frage ist falsch gestellt. Es wurde eine Empfehlung ohne Begründung ausgesprochen. Wir sollten erst mal anfangen zu fragen, wieso eine ID vergeben werden soll.

Und wenn jemand anderer Meinung ist, dann sollte man den anderen nicht "in die Fresse schlagen". Das ist unverschämt. Ich bitte doch um einen gepflegteren Umgangston. Auch wenn das im Forum eher ein Ruf in die Nacht ist .

hustbaer

wieso nicht? schrieb:

Wieso nicht?

Weil es halt einfach nicht wahr ist. Echt, wie blöd kann man eigentlich sein?

Du kannst nicht einfach sowas behaupten (sowas was man im Englischen nen "positive claim" nennt), und dann "wieso nicht" fragen wenn jemand sagt er glaubt es nicht. Die Beweislast liegt bei dir.

Soviel zum Thema kaputte Logik.

Was die Fachliche Ebene angeht: auch da hast du nicht Recht. Bevor du deinen Standpunkt nicht argumentierst interessiert es mich aber echt genau gar nicht dir hier vorzubeten wieso.

Ich habe nichts mit secondsun zu tun. Ich bin einfach nur aus zufall drüber gestolpert und habe mich gefragt was dagegen spricht einfach jedem Datensatz eine ID zu geben.

Die Beweislast liegt bei dir.

Wieso liegt die Beweislast bei mir?
Wie kommst du darauf, dass ich Sachen beweisen muss, die anderen in den Raum werfen?

Was die Fachliche Ebene angeht: auch da hast du nicht Recht. Bevor du deinen Standpunkt nicht argumentierst interessiert es mich aber echt genau gar nicht dir hier vorzubeten wieso.

Sehr freundlich. Ich hab dir nichts getan, wollte bloß wissen was dagegen spricht einfach immer eine ID zu haben, muss aber erst anderer Leute aussagen beweisen, bevor ich eine Antwort wert bin.

tntnet

Wieso nicht? schrieb:

Sehr freundlich. Ich hab dir nichts getan, wollte bloß wissen was dagegen spricht einfach immer eine ID zu haben, muss aber erst anderer Leute aussagen beweisen, bevor ich eine Antwort wert bin.

Ich glaube, Du hast da was falsch verstanden. Du musst gar nichts beweisen.

Es geht eigentlich nicht darum, ob eine ID sinnvoll ist oder nicht. Man kann eine ID gut begründen. Es spricht also nichts dagegen, immer eine ID zu vergeben. Aber es ist nicht falsch, es anders zu machen. Und schon gar nicht sinnvol, jemanden "in die Fresse zu schlagen", wenn er es anders macht.

Was erwartest Du jetzt? Wir können ja nicht dagegen argumentieren, warum eine ID sinnvoll ist, weil es ja das durchaus sein kann. Es ist halt eine Designentscheidung. Wenn ich mich für ein rotes Auto entscheide, ist es nicht falsch, wenn jemand anders ein blaues will.

Ich glaube, Du hast da was falsch verstanden.

Ich hatte das Nein von hustbear schon so verstanden, dass es gute Gründe gibt nicht immer eine ID zu vergeben. Und die hätte ich halt gern erfahren, da ich selbst immer eine GUID verwende, auch wenn ich sie eigentlich garnicht bräuchte.

DocShoe

Weil du damit für etwas bezahlst, was du möglicherweise überhaupt nicht brauchst. So eine ID macht auch nur dann Sinn, wenn die Spalte indiziert wird, und wenn du eine Tabelle mit Schlüssel/Wertepaaren hast, wobei der Schlüssel als Index benutzt werden kann brauchst du die ID nicht mehr. Und bei Tabellen mit wenigen Spalten erzeugt der Index einen relativ großen Overhead.

hustbaer

Wieso nicht? schrieb:

Ich habe nichts mit secondsun zu tun.

Sorry. Dann liegt der Fall anders.
Mein Fehler.

Wieso nicht? schrieb:

Ich bin einfach nur aus zufall drüber gestolpert und habe mich gefragt was dagegen spricht einfach jedem Datensatz eine ID zu geben.

Selbst wenn nichts dagegen sprechen würde, wäre das nicht gleichbedeutend mit "man muss es immer machen, sonst ist man doof".

Davon abgesehen...

Nachteile die mir spontan einfallen:
* Performance: Durch den zusätzlichen Unique-Key ist ein weiterer Index nötig. Der muss gepflegt werden.
* Platzverbrauch: Die zusätzliche Spalte braucht Platz, doppelt durch den dafür nötigen zusätzlichen Index.
* Verwirrend: Wenn ein Datensatz schon eine eindeutige ID hat (die vielleicht nicht fortlaufend vergeben wird und u.U. auch eine "Bedeutung" hat - z.B. Kundennummer), kann es verwirrend sein noch eine zusätzliche Surrogate-Key Spalte zu haben.

Natürlich gibt es auch Vorteile, das sollte klar sein.

Speziell bei Tabellen die bloss eine N-zu-N Verknüpfung zwischen zwei anderen Tabellen herstellen, halte ich es nicht für nötig und nur manchmal für sinnvoll einen zusätzlichen Surrogate-Key zu vergeben. Schliesslich bestehen diese Tabellen NUR aus Foreign-Key Spalten die gemeinsam eben den Primary-Key der Verknüpfungs-Tabelle bilden.

Bengo

secondsun schrieb:

Ich würde dir ja schon was auf die Fresse schlagen, weil du keine ID in deiner Tabelle vergibst:-P Egal wie eindeutig eine Kombination aus zwei Spalten ist, es ist ratsam immer eine ID Spalte zu beginn hinzuzufügen, welche automatisch hochgezählt wird. Tut nicht weh und ich bezweifel, dass du du Platzprobleme bekommen wirst;-)

Jede Tabelle braucht einen Primary key (oder was äquivalentes) und der kann zumindestens bei mysql auch aus 2 spalten bestehen.
Mehr nicht!

DocShoe

Bengo schrieb:

Jede Tabelle braucht einen Primary key (oder was äquivalentes) und der kann zumindestens bei mysql auch aus 2 spalten bestehen.
Mehr nicht!

Nein, braucht sie nicht. Es sogar können alle Einträge einer Tabelle gleich und damit nicht mehr unterscheidbar sein, wenn der Anwendungsfall so ein Szenario zulässt. Gut, mir fällt jetzt kein Anwendungsfall ein, aber technisch braucht eine Tabelle keinen eindeutigen Identifikator für eine Zeile. Intern vielleicht, aber nicht zwingend für den db Benutzer.

Wieso nicht? schrieb:

Ich bin einfach nur aus zufall drüber gestolpert und habe mich gefragt was dagegen spricht einfach jedem Datensatz eine ID zu geben.

Selbst wenn nichts dagegen sprechen würde, wäre das nicht gleichbedeutend mit "man muss es immer machen, sonst ist man doof".
-> Das stimmt natürlich

Davon abgesehen...

Nachteile die mir spontan einfallen:
* Performance: Durch den zusätzlichen Unique-Key ist ein weiterer Index nötig. Der muss gepflegt werden.
-> Wird für einen Unique key immer ein Index angelegt?
* Platzverbrauch: Die zusätzliche Spalte braucht Platz, doppelt durch den dafür nötigen zusätzlichen Index.
-> Meine DBs sind immer eher klein. Einige 10k Einträge. Hab mir da noch nie wirklich gedanken drüber gemacht. Würde man das bei so kleinen DBs schon merken?
* Verwirrend: Wenn ein Datensatz schon eine eindeutige ID hat (die vielleicht nicht fortlaufend vergeben wird und u.U. auch eine "Bedeutung" hat - z.B. Kundennummer), kann es verwirrend sein noch eine zusätzliche Surrogate-Key Spalte zu haben.
-> Die GUID übersieht man nach ner Zeit eh einfach. Ist fast gefährlich. Verwirrt dann eher wenn es fehlt. Liegt vermutlich an der gewohnheit. Ich hab "damals" in der Ausbildung gelernt, das man Nutzdaten von "Datenbankdaten" trennen sollte. Also für PK und FK immer eigene IDs (nur für die DB -> JOINs etc) und Nutzdaten dann seperat. Vor allem habe ich gelernt, dass man sich auch wenn es nahe liegt nicht dazu verleiten lassen soll Kundennummern zu nehmen, weil GUIDs und IDs viel schneller durchsucht werden könne weil sie HEX bzw int werte sind. Vermutlich ist das einfach viel zu allgemein als Aussage.

Natürlich gibt es auch Vorteile, das sollte klar sein.
**-> Jetzt wo du die Nachteile genannt hast sehe ich keine Vorteile mehr. Was wäre denn ein wirklicher Vorteil bei einer ID in einer Tabelle die N-zu-N beziehungen herstellt.
**
Speziell bei Tabellen die bloss eine N-zu-N Verknüpfung zwischen zwei anderen Tabellen herstellen, halte ich es nicht für nötig und nur manchmal für sinnvoll einen zusätzlichen Surrogate-Key zu vergeben. Schliesslich bestehen diese Tabellen NUR aus Foreign-Key Spalten die gemeinsam eben den Primary-Key der Verknüpfungs-Tabelle bilden.
-> Schon traurig dass ich das noch nie hinterfragt habe. Ich hab in N-zu-N Tabellen einfach immer eine ID hinzugefügt weil es halt alle immer so gemacht haben.

Wenn ich die anderen Threads so überfliege (und diesen),hab ich das gefühl 2,5 Jahre Ausbildung waren für n Ar***. Wo habt ihr das alles gelernt? In der Uni?

Bengo

DocShoe schrieb:

Bengo schrieb:

Jede Tabelle braucht einen Primary key (oder was äquivalentes) und der kann zumindestens bei mysql auch aus 2 spalten bestehen.
Mehr nicht!

Nein, braucht sie nicht. Es sogar können alle Einträge einer Tabelle gleich und damit nicht mehr unterscheidbar sein, wenn der Anwendungsfall so ein Szenario zulässt. Gut, mir fällt jetzt kein Anwendungsfall ein, aber technisch braucht eine Tabelle keinen eindeutigen Identifikator für eine Zeile. Intern vielleicht, aber nicht zwingend für den db Benutzer.

Alle mir bekannten Datenbanksysteme geben dann Warnungen aus, und ich bin nicht der Typ von Programmierer, der Warnungen einfach mal ignoriert, weil er meint, dass er gerade was ganz tolles macht.

hustbaer

Wieso nicht? schrieb:

-> Wird für einen Unique key immer ein Index angelegt?

Die DBMS die ich kenne machen das so, ja. Ich wüsste auch keinen anderen Weg die "uniqueness" der Werte zu prüfen/erzwingen. Ausser natürlich jedes mal nen Table-Scan zu machen - was aber denke ich ganz klar die NOCH viel schlechtere Lösung ist.

Wieso nicht? schrieb:

-> Meine DBs sind immer eher klein. Einige 10k Einträge. Hab mir da noch nie wirklich gedanken drüber gemacht. Würde man das bei so kleinen DBs schon merken?

Wenn ich mal von einer einfachen N-zu-N Tabelle ausgehe, und davon dass der Surrogate-Key gleich gross ist wie jeder der beiden Foreign-Keys, dann wird die Row dadurch um 50% grösser. Entsprechend wird auch der Platzverbrauch der Tabelle um 50% anwachsen. Wie viele Einträge die Tabelle hat ist dabei (fast) egal. (fast: Wenn sie bloss ein paar 2, 3 Einträge hat, dann macht es vermutlich genau gar keinen Unterschied, da die komplette Tabelle dann in eine einzige Page passt. Und da Pages nicht zwischen Tabellen "geteilt" werden, bleibt der Platzverbrauch dann in beiden Fällen gleich.)

Dann hat man bei ner einfachen N-zu-N Tabelle natürlich noch nen Index auf die beiden Foreign-Keys zusammen. Den braucht man trotz Surrogate-Key weiterhin, da man ja trotzdem sicherstellen muss dass nicht doppelte Links eingetragen werden. Und zu diesem gesellt sich dann eben noch der Index für den Surrogate-Key dazu. Auch hier ist die Schätzung "+50%" vermutlich nicht weit daneben.

Wieso nicht? schrieb:

-> Die GUID übersieht man nach ner Zeit eh einfach. Ist fast gefährlich. Verwirrt dann eher wenn es fehlt. Liegt vermutlich an der gewohnheit.

**
Ja, ist vermutlich Gewohnheitssache. WENN man es konsequent durchzieht, dann ist es vermutlich auch nicht verwirrend. Zumindest nicht für Leute die das Projekt schon etwas kennen. Da haste wohl Recht.

Wieso nicht? schrieb:

Ich hab "damals" in der Ausbildung gelernt, das man Nutzdaten von "Datenbankdaten" trennen sollte. Also für PK und FK immer eigene IDs (nur für die DB -> JOINs etc) und Nutzdaten dann seperat. Vor allem habe ich gelernt, dass man sich auch wenn es nahe liegt nicht dazu verleiten lassen soll Kundennummern zu nehmen, weil GUIDs und IDs viel schneller durchsucht werden könne weil sie HEX bzw int werte sind. Vermutlich ist das einfach viel zu allgemein als Aussage.

**
Das kommt immer drauf an.
Wenn die Kundennummer ein int (4 Byte) ist, dann kann man die 4x schneller durchsuchen als GUIDs (16 Byte). Auch die Indexe sind dann nur 1/4 so gross.
Wenn die Kundennummer dagegen ein varchar oder sowas ist, dann kann es (vergleichsweise) übel langsam werden.

Ich würde aber auch nicht sagen dass man, wenn die Kundennummer z.B. ein einfacher int ist, man immer diese als Primary-Key verwenden sollte. Das Thema ist einfach zu komplex um so allgemeine Empfehlungen zu geben.

Wieso nicht? schrieb:

-> Jetzt wo du die Nachteile genannt hast sehe ich keine Vorteile mehr. Was wäre denn ein wirklicher Vorteil bei einer ID in einer Tabelle die N-zu-N beziehungen herstellt.

Bei einfachen N-zu-N Tabellen gibt es mMn. nicht sehr viele schwerwiegende Vorteile.
Was mir einfällt:
* Konvention/Einheitlichkeit. Wenn der ganze Rest der DB einen Surrogate-Key in *jeder* Tabelle hat, dann erwartet man vermutlich auch in N-zu-N Tabellen einen solchen.
* Kompatibilität mit Frameworks/Hilfsfunktionen die nur 1-Spaltige Primary-Keys verstehen.
Uff. Weiss jemand noch weitere?

Wieso nicht? schrieb:

Wenn ich die anderen Threads so überfliege (und diesen),hab ich das gefühl 2,5 Jahre Ausbildung waren für n Ar***. Wo habt ihr das alles gelernt? In der Uni?

Nö, in > 15 Jahren Arbeiten als Software-Entwickler