Jag håller på med en sida där jag lägger in en webbutik, men jag kan inte fixa till databasen så jag får det bra. Hoppas nån kan hjälpa mej med det, jag beskriver härnedan hur det skavara.

Det är en firma som trycker på kläder, samt säljer kläder, det ska även vara möjligt att ladda upp egna bilder mm för tryck, de kommer eventuellt att säljamer saker i framtiden.

Vi börjar med trycken. På detaljsidan ska det visas minst en bild på trycket, info om trycket, pris antal i lager, sen ska det också vara möjligt att välja vilken typ av plagg man vill ha trycket på typ t-shirt, hood mm. När man ändrar plagg ska det ändras information om plagget och priset ska också ändras. Man ska också kunnavälja färg och storlek på plagget. Detta vet jag hur jag ska fixa.

För plaggen skadt på detaljsidan visas den vanliga information färg, storlek, pris. denna är ju inget svår, detsamma gäller ju om de ska sälja andra produkter i framtiden.

För tryck som kan laddas upp har jag byggt en funktion för uppladdning mm som fungerar som den ska. Även här ska man kunna välja färg och allt det på plagget man ska ha trycket på.

Det jag har förklarat hitttills fixar jag själv, problemet kommer med databasen, hur löser jag det? Här kommer några krav.

- Man måste kunna se hur många plagg det är kvar av en viss färg och en viss storlek.
- Manmåste alltså kunnase att det finns tre svarta t-shirt med storleken XXL eller fem vita hood i storleken S. Ni fattar nog hur jag menar.
- Orderhistorik
- Spara korg

Mina funderingar har varit att jag har följande tabeller.
TRYCK
-----------------------
tryckID
Allt om trycken

PLAGG
---------------------
plaggID
isPrintable bit

EGNATRYCK
------------------------
egnaTryckID

FÄRG
----------------------
färgID

STL
---------------------
stlID

INSTOCK
----------------------
plaggID
färgID
stlID
quantity

Nu har jag bara tagit med det jag tror är viktigt. Detta borde väl fungera? hur löser jagdetta i ordrar? Det blir väl problem eftersom de olika grejerna inte har samma egenskaper. Jag kommer att visadom i olika user controls på detaljsidan. Jag menar trycket har ju ingen färg eller storlek som plaggen osv. Jag ska använda MSSQL Server 2005.

Jag har lite kommentarer:

1) Tryck: Jag skulle föreslå ett prisfält där också (som är 0 som standard) så att man kan låta vissa tryck vara dyrare (för att man t.ex. har licenserat trycket eller liknande, antingen som procentsats eller bara att addera på priset)

2) Jag skulle inte separera tryck och egna tryck, bara ha någon form av kolumn extra för om trycket är standard eller inte. Kommer bara bli krånglig databas och knöl-kod annars

3) På "instock" skulle jag lägga till en kolumn "tryckid", som kan vara null. Tänkbart är ju att vissa tryck är extra populära och trycks upp som batcher - ett visst tryck och en viss tröja skulle ju då kunna finnas i lager, även om alla andra tryck på exakt samma tröja inte går att få.. Eller vice versa. På alla tröjor som är otrycka är givetvis värdet null.

4) På färg saknas någon info om vad färgen heter, samt t.ex. en hexadecimalkod, eller cmyk-kod (jag föreslår det senare, samt sedan konvertering runtime till hex-kod för att t.ex. kunna visa på hemsidan)

5) Storlek, lägg till fält för vad storleken heter (samt gärna lite fält för ungefärliga mått, är alltid trevligt när man beställer; en medium kan vara alltifrån small till large ;) )

I orders blir det inte så krånligt: Ha exakt samma fält som i instock där för varje orderrad. Hur du vill hantera lagersaldot vet jag inte, ett förslag är att ha dels det faktiska antalet orört tills ordern är packad i "instock", och sedan ha två fält för antalet på varje orderrad - ett fält för antalet beställda, och ett fält för antalet packade. Om man vill veta lagersaldor så är det bara att subtrahera "instock-quantity" med "orderrad-quantity_reserved" minus "orderrad-quantity-shipped" för alla orderrader som stämmer överrens med alla id:s i "instock", samt inte är makulerade (om du har en sådan funktion)

Hm, mycket funderingar, men något kanske var vettigt?

Hej Oskar!
Tackar för dina synpunkter, jag ska sätta mig med detta imorron. Jag kommer nog att återkomma med mer frågor då.

Nu kommer det några frågor om detta:) Jag har försökt tänkt till lite nu

Jag har en tabel products med följande fält:
productID,
productName,
productNumber,
productDesc,
price,
inDate,
catPromotion,
depPromotion

Skulle jag inte kunna lägga till lite fält i denna som tillåts vara null? Då skulle jag ju kunna ha kläder i denna tabell också? Blir det helt fel att göra så? Egentligen är det ju bara några fält som behövs extra.

toPrint BIT = Om det är ett tryckbart plagg.
colorID
sizeID
manifactureID

På detta sätt kan jag ju ha i stort sett vilka produkter som helst i tabellen och då räcker det ju att ha en tabell till produkterna.

Det är nog en avvägning. Om du enbart kommer sälja "vanliga" saker samt tröjjor så skulle det väl vara fullt rimligt, dock.. Problemet är om du efter ett tag kommer på ytterligare en typ av produkter som behöver specialfält. Och ytterligare en. Och ytterligare än. Om du redan nu vet av att det kommer bli på det viset så skulle jag nog föreslå att du lägger de generiska fälten i produkttabellen, och sedan skapar en tabell för varje typ av "specialprodukter" där den extra informationen finns, samt en nyckel till produkttabellen. Sedan ett fält i produkttabellen så man vet vilken typ av produkt det är frågan om (null om standardprodukt.)

(Du vill nog inte bara mata på med specialfält i all oändlighet, de tar både plats och prestanda. Med min lösning så slipper du de problemen. Glöm inte index)

Hej Oskar!
Du menar att jag har en tabell för det som är gementsamt för alla produkter typ namn, pris, id osv?
Sen har jag en tabell där jag lägger in "specialfälten" typ färg, storlek osv? Det är ju smartare än min idé. Det där med index minns jag inte, måste kolla på det igen.

Typ så, men i ditt fall, med bara "vanliga" och "tröjjor" så kanske det är overkill med mitt förslag, men jag vet å andra sidan inte vad du har tänkt att sälja härnäst ;)

Det vet inte jag heller, jag går på ditt förslag. Har skissat lite på det och jag tycker det verkar vara bra. Jag misstänker att jag får återkomma med SQL-frågorna så jag sätter inte tråden som löst ännu.

Jag har nu två tabeller products och productDetails. Sen har jag en del kopplingstabeller med färg osv. Nu försöker jag hämta ut det som finns i products och productDetails, den jag har nu fungerar bra om produkten finns med i båda tabellerna. Det är ju inte säkert att den kommer att göra det, en del produkter kommer ju bara att finnas i products.

Så jag vill att den hämtar allt i products även om det inte finns nåt i productDetails.

<code>
ALTER PROCEDURE getProductDetails2
@prodID INT
AS
SELECT prod.productName, color.color, s.size
FROM products AS prod

LEFT JOIN productDetails AS pd
ON prod.productID = pd.productID AND pd.productID = @prodID

INNER JOIN [size] AS s
ON s.sizeID = pd.sizeID

INNER JOIN color
ON color.colorID = pd.colorID

WHERE prod.productID = @prodID
</code>

Hämtar bara namnet från products för att det skabli mer överskådligt.

------------------EDIT------------------
La till WHERE hade missat den när jag kopierade in det.

Jaglöste det med denna

<code>
ALTER PROCEDURE getProductDetails2
@prodID INT
AS
SELECT prod.productName, color.color, s.size, pp.picPath
FROM products AS prod

FULL JOIN productDetails AS pd
ON pd.productID = @prodID

LEFT JOIN [size] AS s
ON s.sizeID = pd.sizeID

LEFT JOIN color
ON color.colorID = pd.colorID

LEFT JOIN prodPics AS pp
ON pp.prodID = @prodID

WHERE prod.productID = @prodID
</code>

Jag hade inte löst den som jag trodde. Den ser ut så här:
<code>
ALTER PROCEDURE getProductDetails
@prodID INT,
@sizeID INT = NULL,
@colorID INT = NULL
AS
SELECT prod.productID, prod.manifactureID, prod.productName, prod.productNumber,
prod.productDesc, prod.price, prod.inDate, prod.onCatalogPromotion,
prod.onDepartmentPromotion, color.color, s.size, pp.picPath, c.category,
d.departName, q.quantity
FROM products AS prod

FULL JOIN productDetails AS pd
ON pd.productID = @prodID

INNER JOIN productCategory AS pc
ON prod.productID = pc.productID

INNER JOIN categories AS c
ON pc.categoryID = c.categoryID

INNER JOIN department AS d
ON c.departmentID = d.departmentID

-- Den här blir det fel på....
FULL JOIN quantity AS q
ON q.prodID = prod.productID AND q.colorID = @colorID AND q.sizeID = @colorID

LEFT JOIN [size] AS s
ON s.sizeID = pd.sizeID

LEFT JOIN color
ON color.colorID = pd.colorID

LEFT JOIN prodPics AS pp
ON pp.prodID = @prodID

WHERE prod.productID = @prodID
</code>
Problemet är att jag får inte ut antalet hur jag än skriver om colorID och/sizeID är null. Jagmåste tillåta null där eftersom alla produkter inte har sizeID eller colorID. Det jagvill är alltså att få "quantity" även om det inte finns något colorID eller sizeID

Jag måste väl kunna skippa tabellen quantity helt och lägga in antalet i productDetails? I den blir det ju ändå en rad för varje färg och storlek.

F*n vad detta skulle vara besvärligt.

quantity? vad är det för tabell?

btw, varför "productdetails"? när du börjar sälja mössor, blir den tabellen "productdetails2" då? :)

Hur som haver, sizeId=colorId känns inte riktigt rätt?

Såg att jag hade skrivit fel där, men det vill inte fungera ändå.

Tabellerna jag har är products, i den lagras namn, beskrivning, pris allt som alla produkter har. Sen har jag productDetails, i den lagras storlek, färg och antal. Skulle de senare sälja något annat som behöver något mer fält är det ju rätt enkelt att lägga in det i productdetails.

Jag hade en tabell till quantity, men där var jag ju också tvungen att lagra colorID och sizeID till varje produkt som har fler storlekar och färger.

Jag har fått det att fungera med följande SP
<code>
ALTER PROC getProductDetails
@prodID INT,
@colorID INT = null,
@sizeID INT = null
AS
IF(@colorID is null AND @sizeID is null)BEGIN
SELECT productDetails.quantity, products.productName, null AS 'colorID', null AS 'sizeID'
FROM productDetails

INNER JOIN products
ON productDetails.productID = @prodID

WHERE products.productID = @prodID
END

IF(@colorID is null AND @sizeID is not null)BEGIN
SELECT productDetails.quantity, products.productName, sizes.size
FROM productDetails

INNER JOIN products
ON productDetails.productID = @prodID

INNER JOIN [size] AS sizes
ON @sizeID = sizes.sizeID AND productDetails.sizeID = sizes.sizeID

WHERE products.productID = @prodID
END

IF(@colorID is not null AND @sizeID is null)BEGIN
SELECT productDetails.quantity, products.productName, color.color
FROM productDetails

INNER JOIN products
ON productDetails.productID = @prodID

INNER JOIN color
ON @colorID = color.colorID AND productDetails.colorID = color.colorID

WHERE products.productID = @prodID
END

ELSE BEGIN
SELECT productDetails.quantity, products.productName, sizes.size, color.color
FROM productDetails

INNER JOIN products
ON productDetails.productID = @prodID

INNER JOIN [size] AS sizes
ON @sizeID = sizes.sizeID AND productDetails.sizeID = sizes.sizeID

INNER JOIN color
ON @colorID = color.colorID AND productDetails.colorID = color.colorID

WHERE products.productID = @prodID
END
</code>
Är det helt fel att lösa det så? Eller är jag helt fel ute med tabellerna?

> Skulle de senare sälja något annat som behöver något mer fält är det ju rätt enkelt att lägga in det i productdetails.

Du förlorar ungefär hela vitsen med att dela i två tabeller då. Samt att det kommer nog bli rätt rörigt..

Hur som haver, titta på ifnull()-funktionen, du lär kunna korta ner den där koden så du slipper skriva nästan samma sak flera gånger.

Ska kolla på den.

jag förstår inte hur jag ska göra tabellerna om jag inte ska göra så här. Skulle du kunna ge mej ett lite exempel?

Alltså, istället för productDetails så har du shirtDetails. Och sen när du börjat sälja pizza så har du pizzaDetails. Typ så :) Alternativet är t.ex. en stor, fet text-kolumn direkt i produkterna där du kan stoppa in xml. Fast det är inte särskilt trevligt att ställa sql-frågor mot :)

Ahh, nu börjar nog poletten ramla ner:) inte dåligt efter nån vecka haha.

Jag tror jag förstår hur du menar nu. Låt säga att jag döper den till shirtDetails, då måste jag väl kunna ha andra typer av kläder i den också, typ byxor osv?

Hm.. Jadu, clothesDetails? Så vansinnigt många mått kan det väl inte vara på ett normalt klädesplagg? Annars borde du kunna göra något stort matrisliknande monster, fast det vete sjutton om jag rekommenderar..

Hur mycket som går att kombinera är ju en avvägning; hur många tabeller? Hur stora tabeller? Hur går det att knacka kod för det sedan? osv. osv.

Nä, det är det ju inte, det är ju oftast bara från s - xxxl eller byxstorlekar nu har jag inte i huvudet hur de ser ut. Jag testar att lägga in det i en tabell.

Jag skulle ha skrivit detta igår men glömde det.

Jaghar fått ett annat problem. Jag vet inte riktigt hur jag ska lösa det när jag lägger in kläder. Varje färg och storlek ska ju in. På sidan jag ska sätta in det från har jag både färg och storlek i varsin listbox där man kan välja fler alternativ.

Men hur löser man det med antal av varje storlek och färg? Är ju lite trist om man måste lägga in varje var för sig. har man från S - XXL så blir det ju 5 st sen har man kanske fem färger också, då blir det ju 25 insättningar för varje plagg.

Har du nån lösning på det?

Jag fick en liten tanke.. Istället för en vanlig listbox, ta en multiselect-listbox (någon egenskap i html, kommer inte ihåg.) Sedan markerar man helt enkelt alla storlekar och färger, och kör. I koden skulle jag lösa det ungefär som såhär:

Varje "egenskap" på plagget (sizeid, colorid etc) ska hanteras som en _array_. Sedan gör du bara som så att du loopar lite lagom nästlat (foreach(sizeid) { foreach(colorid) {insert_into_db();} } typ :)

Det borde vara rätt enkelt, sålänge som du inte har problemet att det är olika antal av varje, eller liknande problem.. :P Om det är det så får du hitta på något annat spännande, typ rita upp en matris (alla storlekar * alla färger) med textrutor, borde gå bra sålänge det bara är två egenskaper som ska ha flera värden (sedan blir det fler dimensioner än två, å sålänge du inte planerar att bestycka klientens dator med hologram så avråder jag ifrån det ;) )

Det var typ så jag hade tänkt mej men var osäker på hur det skulle gå med antal. Jag har nu frågat och jag kan sätta antalet till noll när man lägger in en produkt.

hehe misstänker att det kommer att bli kul att få den nästlade loopen att fungera:(

F*n
Började med SQLen, men märkte att det blir problem med en gång. Jaghade tänkt det så här.

Lägga in det i produktdatabasen, returnera produktID, detta är ju ingen problem.
- Sen tänkte jag köra nåt i stil med
- foreach(Item item in lbSize)
{
foreach(Item item in lbColor)
{
insert.size
insert.color
}
}

Problemen är dessa:
Hur ska jag veta var det ska in i clothesDetails? Jag har ju productID men det kommer ju att finnas på massor av ställen. När jag har satt in storleken och ska sätta färgen blir det ju problem, då ska ju den raden uppdateras. Då vet jag ju inte vilken rad som ska ändras:( Jag menar produktID och sizeID kommer ju att vara lika många som det finns storlekar och då kommer jag ju att ändra alla till en och samma färg.

Hm, har du flera clothesID på en productID? Jag tänkte mig en 1:1 relation mellan products-tabellen och clothes-tabellen, annars kommer det nog bli knöligt att göra orders känner jag på mig..? Och all annan kod för övrigt

Jo det blir ju så.

I produkttabellen lägger jag in en t-shirt och i clothesDetail blir det ju det produktid tillsammans med storlekarna och färgerna:

products
productID manifactureID catID name prodDesc price
-----------------------------------------------------------------------
45 4 3 T-shrt Snygg.... 19

clothesDetail
prodID colorID sizeID toPrint quantity
----------------------------------------------------
45 2 3 True 3
45 5 4 True 8
45 2 1 True 2

Ja du förstår nog hur jag har gjort det.

Har inte alla fält med nu.