SQL Hoe een recordset clonen?

[Joshuatree]

even een voorbeeld wat ik met deze vraag bedoel.
Stel iemand krijgt een tweeling Jip en Janneke.

Nu voer je voor Jip in de database al zijn gegevens in.
Zoals naw.
Relaties met oom en tantes.
stamboom gegevens.
enz..enz..

Nu wil je deze complete recordset (met al zijn relaties e.d.) weer gebruiken voor Janneke.
Dus eerst copieer/clone je Jip en dan hoef je alleen nog maar de naam aan te passen.

Ik heb al wat gekeken en kom uit op een cursor en scope-identity....
maar heeft iemand misschien een simpeler idee.

alvast bedankt.

[JJ93]

Als je zorgt dat je database structuur goed in elkaar zit kan je gewoon een nieuw persoon invoeren en daarna de relaties binnen een familie vastleggen. Dan kan je met een query de hele familiestamboom bepalen.

Wat je absoluut niet wilt is dubbele records. Je zult dus niet zo zeer moeten zoeken hoe je een record kan klonen, maar juist hoe je een correcte database structuur maakt voor een familiestamboom.

[Joshuatree]

@JJ93 Bedankt voor je antwoord. Ik snap je antwoord maar helaas heb ik niet zelf de db ontworpen.
Dus de vraag blijft. Het voorbeeld was alleen om duidelijk te maken waar ik naar op zoek ben:
clone van een recordset met al zijn relaties.

btw: het is op een ms. sql 2016 server

[Dido]

Joshuatree schreef op maandag 16 januari 2017 @ 12:16:
@JJ93 Bedankt voor je antwoord. Ik snap je antwoord maar helaas heb ik niet zelf de db ontworpen.
Dus de vraag blijft. Het voorbeeld was alleen om duidelijk te maken waar ik naar op zoek ben:
clone van een recordset met al zijn relaties.

btw: het is op een ms. sql 2016 server

In een relationele database wordt dat een uitdaging, omdat relaties als het goed is zijn vastgelegd met foreign keys die verwijzen naar een (unieke) primary key van de entiteit waar ze heen verwijzen.

Dat betekent dat als Jip het ID 1 krijgt, waarmee oom Jan (ID 10) een relatie heeft (1-10), je niet zomaar die relatie kunt clonen voor Janneke (ID 2). Je wilt namelijk helemaal niet het Oom-Neef record van Jip kopieren (want dat is 1-10), maar een nieuw record voor Janneke aanmaken (2-10).

Wie de database ook ontworpen heeft, zonder dat we meer weten van hoe die database eruit ziet blijft het gissen naar een efficiënte manier om dit aan te pakken.

[Montaner]

Lijkt me ook meer voor iets op applicatief niveau dan DB. Misschien dat je een view kan maken van de base table, waarbij je daarna een insert op de view kan doen met een insert from select.

[ Voor 5% gewijzigd door Montaner op 16-01-2017 13:35 ]

[Joshuatree]

@Dido ja dat klopt. Dat is de moeilijkheid.
Je wilt dus voor zowel Jip en Janneke hetzelfde resultaat alleen de recordsets hebben compleet andere ids...

@Montaner Is een optie maar het voordeel van op db niveau is de rollback etc..

tx in ieder geval voor het meedenken.
Ik weet nu in ieder geval dat het geen simpele oplossing wordt. :-)

[Freee!!]

Het gemakkelijkste is mogelijk om alle informatie van Jip uit alle tabellen naar nieuwe, tijdelijke tabellen te kopiëren, die aan te passen voor Janneke en dan de informatie terugdumpen.

Iets als:
CREATE TEMPTABLE1 AS (SELECT * FROM TABLE1 WHERE NAAM = "JIP") WITH DATA;
UPDATE TEMPTABLE1 SET NAAM = "JANNEKE", NUMMER = 2;
INSERT INTO TABLE1 (SELECT * FROM TEMPTABLE1);
DUMP TEMPTABLE1;

Dit is natuurlijk wel afhankelijk van de vraag of je database dit toestaat

[kwaakvaak_v2]

Joshuatree schreef op maandag 16 januari 2017 @ 14:22:
@Dido ja dat klopt. Dat is de moeilijkheid.

@Montaner Is een optie maar het voordeel van op db niveau is de rollback etc..

Dat kan toch op applicatie niveau ook?

code:

start transaction;
// bak logica om de velden te kopieerer.
insert data;
end transaction;

[Freee!!]

kwaakvaak_v2 schreef op maandag 16 januari 2017 @ 14:56:
[...]
Dat kan toch op applicatie niveau ook?

code:

start transaction;
// bak logica om de velden te kopieerer.
insert data;
end transaction;

Dat kan op sommige systemen, ik weet niet of het op alle kan. En voor de "end transaction" zou ik nog een "commit" (of een "rollback") geven, zonder "commit" volgt op alle systemen, die ik ken, een automatische rollback bij "end transaction".

[kwaakvaak_v2]

Mijn SQL taal was van het type pseudo code Maar idd een commit is handig, ging er vanuit dat die insert wel begrepen werd als insert + commit.

[Joshuatree]

Tx voor alle antwoorden.
Ik zal er eens 'in duiken'..

Applicatie is een SPA .. Angular2...

[markvt]

Met een tijdelijke tabel, onfhankelijk van de structuur van de tabel

TABEL1
KOLOM1 PK INT
KOLOM2 .. KOLOM999

code:

select * into #TABEL1 FROM TABEL1 
        where KOLOM1 = @origId

    update #TABEL1 set KOLOM1 = @nieuweId

    insert into TABEL1
        select * from #TABEL1

    drop table #TABEL1

[RobIII]

markvt schreef op vrijdag 20 januari 2017 @ 11:04:
Met een tijdelijke tabel, onfhankelijk van de structuur van de tabel

TABEL1
KOLOM1 PK INT
KOLOM2 .. KOLOM999

code:

select * into #TABEL1 FROM TABEL1 
        where KOLOM1 = @origId

    update #TABEL1 set KOLOM1 = @nieuweId

    insert into TABEL1
        select * from #TABEL1

    drop table #TABEL1

En hoe zitten daar relaties in verwerkt? (Een selectie van) records uit 1 tabel "clonen" is peanuts, zoals je al demonstreert. Maar zodra daar gerelateerde tabellen (en daar weer aan gerelateerde tabellen etc.) bij komen kijken zul je toch al verdomd gauw applicatie-specifieke/domein-specifieke clone-functies moeten gaan maken. Dat is inmiddels meer dan duidelijk gemaakt in dit topic (lees Dido in "SQL Hoe een recordset clonen?" bijvoorbeeld nog eens).

[ Voor 5% gewijzigd door RobIII op 20-01-2017 11:09 ]

[markvt]

Dat kan je ook voor alle andere gekoppelde tabellen uitvoeren.

Als je in TABEL1 nog een FK hebt naar een andere tabel, kopieer je de data uit die andere tabel en werk je daarna de FK in TABEL1 weer bij naar dat nieuwe record.

pseudo zou het er zo uitzien

kopieer tabel1
kopieer tabel2
werk link van tabel1 naar tabel2 bij
kopieer tabel3
werk link van tabel1 naar tabel3 bij

[RobIII]

markvt schreef op vrijdag 20 januari 2017 @ 11:22:
Dat kan je ook voor alle andere gekoppelde tabellen uitvoeren.

No shit
Dat was ook al lang verteld in dit topic Punt is dat je hier niet (makkelijk) een 'generieke' clone-functie voor kunt maken omdat het nogal afhankelijk is van wat jij nu even wegmoffelt onder "werk link van tabel1 naar tabel2 bij"; in sommige gevallen moet dat, in andere gevallen juist niet en dus heb je applicatie/domein-specifieke kennis/functionaliteit nodig om die clone-functie specifiek voor een bepaald "object" en diens hiërarchie te clonen. Maak je een 'generieke clone' functie (en ja, dat is best mogelijk...) dan heb je kans dat je bij 't clonen van een willekeurig record/object je halve DB kopieert en daarmee dubbele records (denormalisatie/redundantie) veroorzaakt die helemaal niet gewenst is.

[ Voor 16% gewijzigd door RobIII op 20-01-2017 11:44 ]