akretschmer
Datenbank-Guru
- Beiträge
- 10.328
Datensatz mit neuer ID x-mal duplizieren
- Ersteller Teckler
- Erstellt am
Werbung:
castorp
Datenbank-Guru
- Beiträge
- 623
Genau, und dafür musst Du erstmal die gewünschte Anzahl von Datensätzen "generieren". Mit diesen generierten Datensätzen machst Du einen cross join mit dem zu kopierenden Datensatz und schon hast Du ihn mehrfach.
Wenn Du den 10 mal kopieren willst, dann musst Du
seq_1_to_10 verwenden
Code:
insert into meinetabelle (wert1, wert2, wert3, ....)
select wert1, wert2, wert3, ...
from meinetabelle
cross join seq_1_to_10
where id = <zureplizierendeID>Das setzt voraus, dass der Primärschlüssel über auto_increment automatisch erzeugt wird.
Teckler
Benutzer
- Beiträge
- 15
Da es in fast allen Foren mit "hat geklappt" endet aber fast nie die Lösung zu sehen ist mache ich hier die Ausnahme
Ablauf: Script in der Workbench ausführen, dabei soviele Zeilen wie nötig kopieren und gleich mit den richtigen Daten befüllen
Es wird die max ID gesucht, diese Zeile nach ID+1 kopiert und anschließend gleich korrigiert.. kann so oft gemacht werden wie nötig
In meinem Fall 14x
Ablauf: Script in der Workbench ausführen, dabei soviele Zeilen wie nötig kopieren und gleich mit den richtigen Daten befüllen
Es wird die max ID gesucht, diese Zeile nach ID+1 kopiert und anschließend gleich korrigiert.. kann so oft gemacht werden wie nötig
In meinem Fall 14x
Code:
INSERT INTO meinetabelle (id,feld1,feld2,feld3,feld4)
SELECT (select max(id)+1 FROM meinetabelle),feld1,feld2,feld3,feld4
FROM meinetabelle
WHERE Id in (select max(id) meinetabelle;
update meinetabelle
set feld2='loremipsum',feld3=4711
where id in (select max(id) meinetabelle);
..
Zuletzt bearbeitet:
dabadepdu
Datenbank-Guru
- Beiträge
- 1.702
Schön, dass Du Deine Lösung zeigst!
Und ich will gar nicht rum meckern, sondern das nur etwas einordnen für andere Leser.
Die Lösung skaliert nicht, könnte man vielleicht kurz sagen.
Variante: in der Zeit, wo das jetzt im Forum hin und her ging, hätte man das Doppelte oder Mehrfache von 14 Datensätzen als einzelne, manuelle Inserts eintippen können. Naheliegend, dass es dennoch keine Lösung für 1000e Datensätze ist.
Schade dabei, dass keiner der Vorschläge zum Zuge gekommen ist, obwohl sie alle nutzbar gewesen wären (Vlt. mit Ausnahmen, abhängig von Edition / Version).
Teckler
Benutzer
- Beiträge
- 15
was meinst Du damit genau ? Inserts ?
ist dafür auch nicht gedacht, künftig max ca 20 Wiederholungen
Kannst mir auch gerne sagen wie neu angelegte Zeile innerhalb der Wiederholung anschließend mit dem richtigen Wert befüllt werden soll ?
Zuletzt bearbeitet:
dabadepdu
Datenbank-Guru
- Beiträge
- 1.702
Was ich genau meine:
Statt 14 x Deine Lösung anzuwenden, schreibt man explizit:
Das dauert 3 Minuten oder so und wäre m.E. sogar wirklich angemessen für eine Handvoll Stammdaten. Den passenden Startwert für die ID "Sequenz" findet/ermittelt man durch eine simple Abfrage der Bestandsdaten.
Die Befüllung mit richtigen Werten erfolgt direkt im Insert, einfach etwas Tipparbeit. Wie gesagt, viel schneller, als das Gerödel hier im Forum.
1) Alternativ kann man (bis auf die eindeutige ID) erstmal alle Werte identisch einfüllen und im Frontend der Anwendung oder einem SQL Tool seiner Wahl die individuellen Daten eben drüber tippen.
Bei Stammdaten, so es wirklich welche sind, liegt es in der Natur der Sache, dass nicht alle Werte per SQL zu bestimmen sind. Sie sind halt individuell.
2) Man hat die wirklichen, individuellen Stammdaten (Rohdaten) bereits vorliegen (z.B. CSV), lädt diese per SQL aus einer Datei, versieht weitere Stammdatenfelder nach Bedarf mit konstanten Werten und vergibt eine fortlaufende ID, per SQL!
Statt 14 x Deine Lösung anzuwenden, schreibt man explizit:
Code:
INSERT INTO meinetabelle
(id,feld1,feld2,feld3,feld4)
values
(15,'fester Wert','loreipsum', 4711, 'anderer fester Wert'),
(16,'fester Wert','oreipsuml', 4713, 'anderer fester Wert'),
(17,'fester Wert','reipsumlo', 4713, 'anderer fester Wert'),
..
(29,'fester Wert','psumlorei', 4709, 'anderer fester Wert');Das dauert 3 Minuten oder so und wäre m.E. sogar wirklich angemessen für eine Handvoll Stammdaten. Den passenden Startwert für die ID "Sequenz" findet/ermittelt man durch eine simple Abfrage der Bestandsdaten.
Die Befüllung mit richtigen Werten erfolgt direkt im Insert, einfach etwas Tipparbeit. Wie gesagt, viel schneller, als das Gerödel hier im Forum.
1) Alternativ kann man (bis auf die eindeutige ID) erstmal alle Werte identisch einfüllen und im Frontend der Anwendung oder einem SQL Tool seiner Wahl die individuellen Daten eben drüber tippen.
Bei Stammdaten, so es wirklich welche sind, liegt es in der Natur der Sache, dass nicht alle Werte per SQL zu bestimmen sind. Sie sind halt individuell.
2) Man hat die wirklichen, individuellen Stammdaten (Rohdaten) bereits vorliegen (z.B. CSV), lädt diese per SQL aus einer Datei, versieht weitere Stammdatenfelder nach Bedarf mit konstanten Werten und vergibt eine fortlaufende ID, per SQL!
Teckler
Benutzer
- Beiträge
- 15
Danke .. jetzt hab ichs mit dem insert verstanden.
Funktioniert aber leider nur 1x und daher bei mir nicht.
Ich hab viele bereits angelegte Zeilen die ich jeweils 14x kopieren und anpassen muss.
Meine Lösung funktionert bestens.
Ich setz jeweils die zu verarbeitende Zeile nach unten und lasse es durchnudeln.. fertig
Nachtrag: eine Tabelle die gestern noch 400 Zeilen hatte hat jetzt über 1000 und ist damit fertig
Ich 2 Wochen gehts in die Konfiguratorproduktion damit.
Funktioniert aber leider nur 1x und daher bei mir nicht.
Ich hab viele bereits angelegte Zeilen die ich jeweils 14x kopieren und anpassen muss.
Meine Lösung funktionert bestens.
Ich setz jeweils die zu verarbeitende Zeile nach unten und lasse es durchnudeln.. fertig
Nachtrag: eine Tabelle die gestern noch 400 Zeilen hatte hat jetzt über 1000 und ist damit fertig
Ich 2 Wochen gehts in die Konfiguratorproduktion damit.
Zuletzt bearbeitet:
T
Thallius
Guest
Mich würde Echt mal der konkrete Einsatz dafür interessieren. Ich programmiere jetzt seit über 40 Jahren aber sowas kaputtes habe ich noch nie gebraucht…
akretschmer
Datenbank-Guru
- Beiträge
- 10.328
manchmal ist es besser, solche Dinge NICHT zu hinterfragen...
ukulele
Datenbank-Guru
- Beiträge
- 5.161
Der Thread fängt in vielerlei Hinsicht schon falsch an.
- SQL-Tabellen haben keinen Anfang und kein Ende.
- Primary Keys müssen nicht editierbar sein, auch nicht in Stammdaten-Tabellen.
- Wenn sich aus einer festen Menge an Datensätzen weitere Datensätze ableiten lassen, also "zusätzliche Zeilen" in der Tabelle, dann stimmt doch irgendwas mit dem DB Design nicht. Dann sind doch die Informationen redundant oder überflüssig.
- SQL-Tabellen haben keinen Anfang und kein Ende.
- Primary Keys müssen nicht editierbar sein, auch nicht in Stammdaten-Tabellen.
- Wenn sich aus einer festen Menge an Datensätzen weitere Datensätze ableiten lassen, also "zusätzliche Zeilen" in der Tabelle, dann stimmt doch irgendwas mit dem DB Design nicht. Dann sind doch die Informationen redundant oder überflüssig.
dabadepdu
Datenbank-Guru
- Beiträge
- 1.702
Ich finde nicht. Der Thread verläuft vor allem schräg, 3 bis 4 Varianten zur Lösung, aber es bleibt bei "ich mache es jetzt weiter manuell". Und "funktioniert nur 1x, also bei mir nicht" zeugt nicht von großer Änderungsbereitschaft oder Frustrationstoleranz.
Am Ende einfach ein mageres Ergebnis für mehrere gute Antworten.
Aber
Die anderen Einwände finde ich relativ "nerdig".
- ich würde sagen, jedes Kind würde nach dem Eintippen seines ersten Datensatzes sagen, das ist der Anfang. Ebenso beim -vorläufig- letzten.
.. kein Anfang und kein Ende.. Was nützen solche Anmerkungen ohne Erläuterung?
- Ich sehe aus den Angaben des TE nirgendwo, dass er editieren im Sinne von verbiegen möchte. Und nur das wäre nicht erstrebenswert oder sogar besser verboten. Tatsächlich erzeugt er aus Unwissen oder warum auch immer vorläufige Werte, die vor ihrem Einsatz einen finalen Wert erhalten. Natürlich ist das nicht elegant und wörtlich genommen verletzt das Editieren eines PK Faustregeln. Aber ein PK, der noch nie benutzt wurde, ist davon auch nicht betroffen.
- Ich sehe da nicht zwingend ein falsches Tabellendesign.
Es reicht eine x-beliebige Typentabelle in einem größeren System, die 5-10 Attribute hat und unterschiedliche Varianten dieser Attribute abbildet. M.E. vollkommen legitimes Design. Warum der TE das so mühsam befüllt erklärt sich daraus sogar zum Teil -auch wenn es nur meine Spekulation ist. Er nimmt einen möglichst ähnlichen, vorhandenen Typ als Grundlage für eine Befüllung mit einer nahe verwandten Attributmenge.
Werbung:
ukulele
Datenbank-Guru
- Beiträge
- 5.161
Es mag (gute) Gründe für das Anliegen geben und wir kennen nicht den Hintergrund aber einerseits Erfahrung andererseits die, ich nenne es jetzt mal unpräzisen Aussagen lassen mich vermuten das hier einfach die Grundidee nicht stimmt.
@Teckler kann gerne mal ein konkretes Fallbeispiel aufzeigen und sagen was im vorhanden Datensatz steht und welche Information er daraus ableitet um diese dann in weiteren Datensätzen in die Tabelle zu schreiben. Dann kann ich dir sagen warum ich das für falsch halte, wie ich es machen würde oder nehme alles zurück und versuche mich an einem funktionierenden Code zum einfügen der Zeilen.
@Teckler kann gerne mal ein konkretes Fallbeispiel aufzeigen und sagen was im vorhanden Datensatz steht und welche Information er daraus ableitet um diese dann in weiteren Datensätzen in die Tabelle zu schreiben. Dann kann ich dir sagen warum ich das für falsch halte, wie ich es machen würde oder nehme alles zurück und versuche mich an einem funktionierenden Code zum einfügen der Zeilen.
Ähnliche Themen
