Archiv verlassen und diese Seite im Standarddesign anzeigen : SQL: Wie Tabellenwert erhöhen ohne AutoIncrement
Hallo, und zwar muss ich für eine Übung eine Tabelle mit Kunden um einen neuen Kunden erweitern. Hierbei soll die aktuell höchste Kundennummer in der DB ermittelt werden, um 1 erhöht werden und dann zusammen mit weiteren Werten in die Tabelle geschrieben werden.
Ich bekomme das aber ums verrecken nicht hin. Mit Java könnte man eine Variable deklarieren, ihr den Wert übergeben und dann im INSERT Statement die Variable übergeben. Aber mit reiner SQL Syntax bekomme ich das nicht gebacken. Bin jetzt bei: "INSERT INTO KUNDE (KNR)
SELECT MAX(KNR)+1 FROM KUNDE" damit habe ich zwar die Kundennummer erhöht, aber in den anderen Spalten wie Name, Adresse etc. stehen keine Werte und ich kann auch keine eintragen.
Also wäre super wenn da jemand einen Vorschlag für mich hätte.
Danke und Grüße
Jörg
Du solltest in deinem INSERT-Statement eben noch die anderen Felder übergeben.
Geht ja eben nicht. Wenn ich
z. B. INSERT INTO KUNDE (KNR,'Schneider', 'Bahnhofsstrasse')
SELECT MAX(KNR)+1 FROM KUNDE eingebe gibt es eine Fehlermeldung zurück, oder habe ich dich jetzt falsch verstanden?
http://www.mckoi.com/database/SQLSyntax.html#12
Sollte helfen :)
Marscel
2008-11-06, 19:34:10
Sub-Query?
rotalever
2008-11-06, 20:06:48
Warum darf man da keine unique-ids mit AutoIncrement verwenden? Eine Datenbank benutzt man doch schließlich, um sich das Leben leichter zu machen.
Weil Professoren den Studenten das Leben schwer machen wollen ;-)
Ist natürlich praktisch gesehen völlig sinnlos.
INSERT INTO KUNDE (KNR, Name, Adresse) SELECT MAX(KNR)+1 , 'Schneider', 'Bahnhofsstrasse' FROM KUNDE
Funktioniert natürlich nur, wenn schon mindestens eine KNR vorhanden ist. Ich hoffe, das ist es, was du mit deinem Beispiel bezwecktest. Wenn du aber die KNR von 'Schneider' an der 'Bahnhofsstrasse' hochsetzen wolltest, also von einem bereits exisiterenden Eintrag, würde das anders funktionieren (UPDATE-Statement).
Allgemein: Anhand deiner Beispielabfrage von oben (INSERT INTO KUNDE (KNR,'Schneider', 'Bahnhofsstrasse') SELECT MAX(KNR)+1 FROM KUNDE) würde ich sagen, du solltest dir die Funktionsweise von SQL oder sogar Datenbanken etwas genauer ansehen.
rotalever
2008-11-06, 21:19:48
Weil Professoren den Studenten das Leben schwer machen wollen ;-)
Ist natürlich praktisch gesehen völlig sinnlos.
Ist denn dann auch sichergestellt, dass bei 2 gleichzeitigen Requests auch beide unterschiedliche IDs bekommen?
Sephiroth
2008-11-06, 22:17:57
Ist denn dann auch sichergestellt, dass bei 2 gleichzeitigen Requests auch beide unterschiedliche IDs bekommen?
Wenn es jeweils nur ein Query ist, dann dürfte es gehen. Sind es aber immer zwei (erst select und dann ein insert/update), dann nur wenn ein exklusiver read-lock gesetzt wird.
MySQL lässt beispielsweise keine konkurierende INSERT...SELECT Statements zu.
To ensure that the binary log can be used to re-create the original tables, MySQL does not allow concurrent inserts for INSERT ... SELECT statements.
Das ist was ich mit "einem Query" meinte.
p.s.
http://forum.de.selfhtml.org/archiv/2006/2/t122957/#m791332
Hallo, erstmal danke für die zahlreichen Antworten!
@samm Die Syntax meines INSERT Befehls ist natürlich völliger Schrott, kommt davon wenn man zu lange vor der Kiste sitzt ;-)
Auf jeden Fall hat das geklappt, Danke an alle und Grüße
PS ging natürlich darum, einen weiteren Kunden hinzuzufügen, also den Zähler raufsetzen und neue Daten dazu.
Senior Sanchez
2008-11-06, 23:35:12
Warum darf man da keine unique-ids mit AutoIncrement verwenden? Eine Datenbank benutzt man doch schließlich, um sich das Leben leichter zu machen.
Soweit ich weiß ist AutoIncrement kein SQL-Standard und von daher stark datenbankabhängig. MySQL kann es, aber intern wird das auch nur umgesetzt auf Trigger und irgendwelche Folgen, wie man es sonst auch machen müsste.
Die geschachtelten Statements, also mit dieser sub-query, sind da denke ich am Besten.
Shink
2008-11-07, 12:02:44
Soweit ich weiß ist AutoIncrement kein SQL-Standard und von daher stark datenbankabhängig. MySQL kann es, aber intern wird das auch nur umgesetzt auf Trigger und irgendwelche Folgen, wie man es sonst auch machen müsste.
Stimmt, so gut wie jede Datenbank hat da etwas aber es sieht überall anders aus.
Ich finde aber nicht dass man da wirklich drum herum kommt. Wenn dann müsste man den höchsten Wert in eine andere Tabelle schreiben, sonst würden z.B. die Kundennummern wiederverwendet werden wenn mal die höchsten gelöscht werden und beim ersten Einfügen würds auch nicht gehen.
rotalever
2008-11-07, 12:33:03
Soweit ich weiß ist AutoIncrement kein SQL-Standard und von daher stark datenbankabhängig. MySQL kann es, aber intern wird das auch nur umgesetzt auf Trigger und irgendwelche Folgen, wie man es sonst auch machen müsste.
Die geschachtelten Statements, also mit dieser sub-query, sind da denke ich am Besten.
Das stimmt schon, dass jede Datenbank das etwas anders macht, aber das ist z.B. bei diesem Autoincrement nur geringfügig. Bei anderen Datenbanksystemen steht dann da halt ein anderes Key-Wort beim Erstellen der Tabelle.
Senior Sanchez
2008-11-07, 17:24:40
Das stimmt schon, dass jede Datenbank das etwas anders macht, aber das ist z.B. bei diesem Autoincrement nur geringfügig. Bei anderen Datenbanksystemen steht dann da halt ein anderes Key-Wort beim Erstellen der Tabelle.
Japs, klar :)
Aber stell dir mal vor, du schreibst ne Applikation die per Datenbankschnittstelle (lass es JDBC oder whatever sein) auch Relationen definieren können soll und somit SQL als DDL (Data Definition Language) nutzt.
Wenn du in solche Applikationen jetzt Datenbankabhängig wirst, kannst du ein und denselben Code für jedes mögliche Datenbankmanagementsystem implementieren.
rotalever
2008-11-07, 18:08:40
Japs, klar :)
Aber stell dir mal vor, du schreibst ne Applikation die per Datenbankschnittstelle (lass es JDBC oder whatever sein) auch Relationen definieren können soll und somit SQL als DDL (Data Definition Language) nutzt.
Wenn du in solche Applikationen jetzt Datenbankabhängig wirst, kannst du ein und denselben Code für jedes mögliche Datenbankmanagementsystem implementieren.
Okay. Das ist wahr.
Japs, klar :)
Wenn du in solche Applikationen jetzt Datenbankabhängig wirst, kannst du ein und denselben Code für jedes mögliche Datenbankmanagementsystem implementieren.So ist es meiner Erfahrung nach in der Realität aber auch. MS SQL, Oracle, DB2, MySQL... Oft brauchst du leicht geänderte Syntax, damit es funktioniert wie es soll, da kommst um die Mehrfachimplementation gewisser SQL Statements nicht herum. Für den Benutzer nur halb so schlimm, wenn man einfach eine Konfigurationsdatei hat, wo er das DBMS eintragen kann ;)
Senior Sanchez
2008-11-07, 20:53:04
So ist es meiner Erfahrung nach in der Realität aber auch. MS SQL, Oracle, DB2, MySQL... Oft brauchst du leicht geänderte Syntax, damit es funktioniert wie es soll, da kommst um die Mehrfachimplementation gewisser SQL Statements nicht herum. Für den Benutzer nur halb so schlimm, wenn man einfach eine Konfigurationsdatei hat, wo er das DBMS eintragen kann ;)
Naja, aber die Hersteller der bekannten Systeme sagen doch eigentlich, dass sie den SQL-99 Standard mittlerweile implementieren und dazu muss doch auch die definierte Syntax eingehalten werden. Oder gibts da immer noch Lücken?
Dinge die natürlich darüber hinaus gehen, dass ist DBMS-spezifisch, logisch, kann ja jeder machen wie er will.
Aber das in der Praxis vieles anders gemacht wird, als in der Theorie, das habe ich auch schon gemerkt. ;-)
Ich habe letztes Semester ja Datenbankenimplementierungstechniken gehört und was da für abgefahrene Datenstrukturen waren, wow, nicht schlecht. Wenn man dann aber mal sieht, was die großen DBMS erst unterstützen, da bekommste nen richtigen Praxisschock. Dafür sind sie aber zum Beispiel bei anderen Geschichten wieder irre gut (Optimierer, Caching-Routinen), da sie darüber ja auch nicht plaudern.
daflow
2008-11-08, 10:17:01
Naja, aber die Hersteller der bekannten Systeme sagen doch eigentlich, dass sie den SQL-99 Standard mittlerweile implementieren und dazu muss doch auch die definierte Syntax eingehalten werden. Oder gibts da immer noch Lücken?
Dinge die natürlich darüber hinaus gehen, dass ist DBMS-spezifisch, logisch, kann ja jeder machen wie er will.
Aber das in der Praxis vieles anders gemacht wird, als in der Theorie, das habe ich auch schon gemerkt. ;-)
Ich habe letztes Semester ja Datenbankenimplementierungstechniken gehört und was da für abgefahrene Datenstrukturen waren, wow, nicht schlecht. Wenn man dann aber mal sieht, was die großen DBMS erst unterstützen, da bekommste nen richtiges Praxisschock. Dafür sind sie aber zum Beispiel bei anderen Geschichten wieder irre gut (Optimierer, Caching-Routinen), da sie darüber ja auch nicht plaudern.
Ja, wie du schon sagst. Jedes DBMS bietet Dinge darüber hinaus... und zwar (je nach DBMS) gewaltig mehr... und wenn das DB-Design nicht gerade nur aus 3 Tabellen besteht und man den ein oder andere komplexen SQL mehr benötigt ist man Heilfroh über das "darüberhinaus" im sql Umfang (Funktionen, Prozeduren, Systemtabellen, Datentypen(und das fängt bei den simplen an!), Indextypen...). Weiterhin haste Eigenheiten in den DBMS wie:
- Was beinhaltet die Datenbank
- Was ist eine Instanz
- Was ist ein Schema
- Gibt es/welche Systemdatenbanken / was steht in welcher...
- Wie funktioniert das Berechtigungssystem
...
Hm, was gibt's denn da für "Datenbankimlementierungstechniken" (=Umsetzung der Modellierung?). Welche nicht umsetzbar sind in DB2, Oracle, Ms-sql, Mysql...? Bin da bisher noch nie in Verlegenheit gekommen, daß ich irgendwas modelliert hab, was sich nicht implementieren lies :redface:
Senior Sanchez
2008-11-08, 12:05:44
Ja, wie du schon sagst. Jedes DBMS bietet Dinge darüber hinaus... und zwar (je nach DBMS) gewaltig mehr... und wenn das DB-Design nicht gerade nur aus 3 Tabellen besteht und man den ein oder andere komplexen SQL mehr benötigt ist man Heilfroh über das "darüberhinaus" im sql Umfang (Funktionen, Prozeduren, Systemtabellen, Datentypen(und das fängt bei den simplen an!), Indextypen...). Weiterhin haste Eigenheiten in den DBMS wie:
- Was beinhaltet die Datenbank
- Was ist eine Instanz
- Was ist ein Schema
- Gibt es/welche Systemdatenbanken / was steht in welcher...
- Wie funktioniert das Berechtigungssystem
...
Hm, was gibt's denn da für "Datenbankimlementierungstechniken" (=Umsetzung der Modellierung?). Welche nicht umsetzbar sind in DB2, Oracle, Ms-sql, Mysql...? Bin da bisher noch nie in Verlegenheit gekommen, daß ich irgendwas modelliert hab, was sich nicht implementieren lies :redface:
Datenbanken 1 hat sich bei uns mit den grundsätzlichen Dingen beschäftigt, also was eine Datenbank ist, wie man sie modelliert, SQL, Relationenalgebra, ER-Modellierung, Transaktionen, Tupelkalkül usw. Halt eben die ganzen Grundlagen.
Bei Datenbanken 2 (oder Datenbankimplementierungstechniken) geht es darum, wie so ein DBMS funktioniert. Also angefangen von der 5-Schichten-Architektur mit der unteren Hardwareebene (RAID-Level, Backups usw.) bis hin zur Anfragenbearbeitung in der obersten Schicht.
Dazwischen findest du dann Dinge, wie man Daten in Datenbanken speichern kann, was beim klassischen B-Baum, dem Arbeitstier unter den Strukturen, los geht, dann über Erweiterungen wie B* und B#, verschiedene Hashing-Verfahren bis hin zu mehrdimensionalen Strukturen wie Grid Files, R-Bäume bzw. R+-Bäume, KdB-Bäume, mehrdimensionales Hashing usw. endet. Weiterhin werden dann noch Zugriffsstrukturen behandelt, also Indexe, der Seitenmechanismus bei DBMS und noch einiges mehr.
Enden tut das dann damit, wie Anfragen optimiert werden, also angefangen von Optimierungen auf Basis der Relationen (richtige Join-Reihenfolge, Vorziehen von Selektionen, Einfügen von Projektionen, Pipelining) als auch kostenbasierte Abschätzungen mit Histogrammen.
Das war insgesamt ein ziemlich cooles Fach, da es viel von DB 1 enthalten hat, aber auch Rechnersysteme und Algorithmen und Datenstrukturen. Die Quintessenz war aber, dass alle großen DBMS sich größtenteils auf den B-Baum (eher B*) und Hashing-Verfahren stützen. Irgendwelche abgefahrenen, mehrdimensionalen Verfahren werden kaum benutzt, aber dafür sind die Caching- und Optimierungsalgorithmen einfach der Wahnsinn. Ich hatte das schon mal gelesen, aber das wurde auch da noch mal bestätigt, dass die richtig guten DBMS wie z.B. die Oracles (ok, manche Releases sind Mist *g*) es schaffen, dank exzellenter Seitenersetzungsstrategien, dass über 95 % der Anfragen im schnellen Cache, also RAM, landen. Ich meine, bei RAM-Größen im zweistelligen GB-Bereich mag das nach keinem Kunststück aussehen, aber wenn die DBs dann im Terabyte- oder gar Petabyte-Bereich liegen, find ich so etwas absolut beeindruckend.
Eventuell höre ich mir ja noch die Veranstaltungen Transaktionsmanagement und Datawarehouse-Technologies an.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.