Jag arbetar på ett användargränssnitt till en webbshop där det finns en produkt tabell och en artikel tabell

produkt tabell

p_id int
p_namn varchar
p_bild char
p_pris smallmoney
p_nyhet bit

artikel tabell

a_id int
p_id int
a_artikelnr char
a_alternativ char
a_pris smallmoney
a_vikt int



Hur kan jag enklast se till att hålla relationen mellan dessa tabeller, ett alternativ är att vid INSERT på produkt tabell erhålla det sista värdet som sattes in och föra in det i p_id i artikel tabell eller så tänkte jag höra med er om det går att köra en SP "INSERT" i produkt tabell och sedan i samma SP "INSERT" artikel tabell.


Kom gärna med förslag, tack påförhand

Ja, du kan skapa en procedur som gör en insert i varje tabell. Men som jag sagt tidigare, om dessa tabeller egentligen representerar (olika sidor av) samma entitet bör de antagligen ligga i samma entitet. Eller för att uttrycka mig annorlunda, om det ska finnas ett 1:1 förhållande mellan entiteterna så bör de antagligen representeras med enbart en tabell.

Hej Christoffer.

Jag vet att du berättat om detta tidigare.

Men det är så att produkt tabellen som sagt står i 1:1 relation till artikel tabellen, men känner att det är smidigare och inte så krävande om jag delar upp det på 2 tabeller.

produkt tabell

p_id p_namn p_bild
1 kalle kalle.jpg


artikel tabell

a_id p_id a_artnr a_alternativ
1 1 5455 15hg
2 1 4544 20hg
3 1 4654 25 hg


Men anser du att alla dessa fält skall ligga i samma tabell?

>Men anser du att alla dessa fält skall ligga i samma tabell?

Tja, det är som sagt alltid svårt att ge råd om design om man inte känner till hela bilden. Exemplen du ger i tabellerna ser ju inte direkt ut att ha något med varandra att göra, och de är ju inte heller i ett 1:1 förhållande utan 1:n. Och då ska de förstås inte ligga i en och samma tabell.

Och då är som sagt svaret på originalfrågan ja, du kan skapa en procedur som först lägger in en rad i produkt-tabellen och sedan en rad i artikel-tabellen. Jag rekommenderar normalt inte att man använder en trigger för att lösa det. Dock beror det faktiskt lite på exakt vad du vill lösa, alltså vilken relation tabellerna ska ha till varandra. Ska det vara 1:1 eller 1:n, och tillåter den att det finns produkter utan artiklar som är relaterade till dem?

Relationen mellan dessa tabeller ligger ju i nyckeln p_id, och nej det måste finnas minst en artikel kopplade till produkten.

Vad är skillnaden mellan 1:1 och 1:n?


Hur skullen en sådan SP "insert" kunna se ut för både produkt samt artikel?

Det viktigaste är att erhålla @@identity från produkt tabellen för att sätta in i artikel tabellen.:

Så här kan du göra i det enkla fallet (med reservation för "dina" datatyper). Förutsätter oxå automatisk räknare på id-fälten:

<code>
CREATE PROCEDURE [dbo].[spInsert]
@namn varchar(50),
@bild varchar(50),
@artnr int,
@alternativ varchar(50)
AS
DECLARE @prodid int

INSERT produkt VALUES(@namn, @bild)
SET @prodid = @@IDENTITY

INSERT artikel VALUES(@prodid, @artnr, @alternativ)
GO
</code>

Detta funkar bra för en 1:1-relation. Det är förmodligen inte det du vill göra i detta fall. Det verkar som du har en 1:N-relation, dvs en produkt kan förekomma på fler artiklar (låter lite underligt i mina öron, men jag kan ju inte din verksamhet).

Detta ställer dig inför ett mindre arkitekturproblem. Förmodligen vill du kunna lägga in en produkt och dess tillhörande artiklar i samma transaktion. I ditt exempel ovan alltså "Kalle" i produkt-tabellen och hans tre artiklar i artikel-tabellen i samma transaktion. Ur användarens synvinkel i samma "klick" i gränssnittet.

Jag skulle lösa detta genom att göra en SP för varje tabell och låta den första för produkt-tabellen returnera @@IDENTITY som endera en ut- eller returparameter. Denna måste sedan tas hand om av din anropande kod som sedan skickar den vidare till artikelns SP. Sedan måste din kod också ta hand om att hantera transaktionen, så att du kan göra Rollback om något går snett i exekveringen.

Jag antar att du utvecklar uteslutande i Ms-miljö. Du kan hantera transaktioner mha COM+ som kodmässigt är enkelt och konfigurerbart, men skapar dig lite admin vid installation. Du kan oxå hantera transaktioner programmatiskt mha objekt i ADO, men du får då koda lite mer.

//good luck

Hej Anders Larsson.


Vad det gäller produkt coh artikel tabellen så är det ju att en produkt är en artikel men den artikeln kan ju ha flera artikelnr dvs, olika strl, färg, m.m.


Jag kan inte förstå varför detta upplägg är fel, skulle jag ha allt i en tabell så skulle det innebära en massa onödig information som förekommer flera gånger, som produktnamn, bild m.m. för att sedan köra en DISTINCT i Select-satsen.

Nu har jag bara en uppsättning av produktnamn, bild, nyhet m.m. i en tabell
när användaren funnit en intressant produkt så klickar han på produkten och får då se alternativen "artiklar" köper det alternativet som passar bäst.

Kom gärna med förslag, jag håller på att slutar SNUSA och känner mig jävligt groggy och kanske tänker fel.

Kristian, jag tror inte det är något fel i den design du presenterat. Jag hade tidigare uppfattat att dessa tabeller skulle ha ett 1:1 förhållande, dvs för varje rad i produkt måste det finnas en (och endast en) rad i artikel. Men så är ju tydligen inte fallet utan det är en vanlig 1:n relation som gäller. Då är din design helt korrekt.

Sen är då frågan om det är så att det måste finnas minst en rad i artikel för varje produkt. Om det är en regel som du måste implementera så är det en trigger som gäller. Alternativet är att din applikation styr det, antingen med en procedur eller på annat vis, men då är det inte databasintegritet som styr det. Men frågan är alltså om det är en regel, eller ett 'arbetssätt' du beskriver. Man måste skilja på datat och de regler som hanterar dess integritet, mot applikationen (eller applikationerna) som ska använda datat.

Hej Christoffer.

-Men frågan är alltså om det är en regel, eller ett 'arbetssätt' du beskriver. Man måste skilja på datat och de regler som hanterar dess integritet, mot applikationen (eller applikationerna) som ska använda datat.

Jag vet ju inte ifall jag missuppfattar dig nu, men det är ju snarare en regel att det måste förekomma minst en artikel kopplat till produkten, då vill jag på ett enkelt sätt lägga till en produkt och en artikel samtidigt, och på så sätt få en insert i dessa på tabeller.

Först blir det att lägga till i produkt tabellen för att erhålla @@identity, för att i samma skede lägga till i artikel tebellen med informationen om artikeln

Jag vet inte om det går att lägga till allt detta i en och samma SP, koden jag fick ovan har jag inte fått att fungera.

Kodexemplet fungerar under givna förutsättningar. Det jag menar med att den endast fungerar för 1:1-relation är att den skapar en ny produkt för varje artikel. Du kan aldrig koppla på fler artikelnr till samma övergripande produkt med denna procedur. Är det detta du vill åstadkomma?

Hej Anders

Det viktigaste för mig är att insert kommandot för i en produkt och en artikel i ett skede.

Tips 1:

Ange vilka fält du vill stoppa in värdena i:

INSERT INTO produkt (namn, bild) VALUES (@namn, @bild)

Det gör att fråga blir mindre känslig för förändringar i databasen.

Tips 2:

Använd scope_identity() istället för @@identity. Skillnaden märks visserligen bara om man har insert i en trigger på tabellen, då ger @@identity id för posten som skapades i triggern istället.