Sitter och funderar lite på en sak som jag aldrig fått fram någon riktigt bra lösning på, så min fundering nu är hur gör DU?

Om jag har en tabell med t.ex. användare. Användaren kan tillhöra olika grupper... Det är ju enkelt om man har en begränsning att varje användare bara kan tillhöra EN grupp men om användaren ska ha möjlighet att registrera sig till flera grupper, hur designar du din databas då?

Såhär skulle en databas se ut om jag skulle göra den med möjligheten att bara ha med en grupp / användare, men hur skalll DU göra med flera, lägger ni flera id:s med en "separator" eller har du någon extra tabell som håller reda på grupperna? :

*** Users ***
ID (uniqueidentifier)
Username (nvarchar(16))
Password (nvarchar(16))
FullName (nvarchar(64))
GroupID (uniqueidentifier)

*** GROUPS ***
ID (uniqueidentifier)
Name (nvarchar(32))

*** Users ***
ID (uniqueidentifier)
Username (nvarchar(16))
Password (nvarchar(16))
FullName (nvarchar(64))

*** GROUPS ***
ID (uniqueidentifier)
Name (nvarchar(32))

*** Membership ***
UserID
GroupID

Hur gör du sen Per när du hämtar ut "Users", gör du en JOIN med Membership tabellen eller hämtar du ut den separat senare?

Japp,

Users JOIN Membership ON Users.ID=Memberships.UserID JOIN Groups ON Memberships.GroupID=Groups.ID

Förslag på en SP som hämtar alla användare som ingår i en grupp enligt ovanstående design :

CREATE PROCEDURE User_GetUsersByGroupID
    @GroupID    uniqueidentifier
AS
    SELECT * FROM Users WHERE [ID] IN 
          (SELECT UserID FROM MemberShip WHERE GroupID=@GroupID)
GO

CREATE PROCEDURE User_GetUsersByGroupID
    @GroupID    uniqueidentifier
AS
    SELECT * FROM Users
    JOIN Membership ON Users.ID=Membership.UserID 
    WHERE Membership.GroupID=@GroupID
GO

Hur fungerar det i praktiken med Group Tabellen?

Kan du förtydliga din fråga, Gerten (om den var riktad till mig vill säga :-)...

Du har ju tabell exemlet ovan:
*** Users ***
ID (uniqueidentifier)
Username (nvarchar(16))
Password (nvarchar(16))
FullName (nvarchar(64))

*** GROUPS ***
ID (uniqueidentifier)
Name (nvarchar(32))

*** Membership ***
UserID
GroupID

om man jämför det med min tråd nedanför denna. Så förstår jag inte relationen mellan group och Membership. Jämfört med min: http://www.pellesoft.se/communicate/forum/view.aspx?msgid=153388

Tack för det fina förslaget... :)

har du även ett "förslag" på en SP åt "andra hållet" dvs, hämta ut en användare samt alla grupper den tillhör, gärna så att den skriver ut namnen från tabellen Groups... ;)

Edit: Frågan är riktad mot Hultans SP

Det skulle väl i sådana fall bli så här :

CREATE PROCEDURE User_GetGroupsByUserID
    @UserID    uniqueidentifier
AS
    SELECT * FROM Groups WHERE [ID] IN 
          (SELECT GroupID FROM MemberShip WHERE UserID=@UserID)
GO

CREATE PROCEDURE User_GetGroupsByUserID
    @UserID    uniqueidentifier
AS
    select * from Groups
    JOIN Membership ON Groups.ID=Membership.GroupID
    WHERE Membership.UserID=@UserID
GO

<b>*** Membership ***
UserID
GroupID

om man jämför det med min tråd nedanför denna. Så förstår jag inte relationen mellan group och Membership.</b>

För varje medlem som är med i någon grupp, och för varje grupp som denne är medlem i, innehåller Membership en rad med användarens ID och gruppens ID.

Om vi t.ex. har tre grupper:
1. Alfa
2. Beta
3. Gamma
och fyra personer:
1. Adam - medlem i Alfa
2. Bertil - medlem i Beta och Gamma
3. Caesar - medlem i Alfa och Beta
4. David - medlem i Alfa och Gamma
så innehåller tabellen
UserID - GroupID - förklaring
1 - 1 - Adam med i Alfa
2 - 2 - Bertil med i Beta
2 - 3 - Bertil med i Gamma
3 - 1 - Caesar med i Alfa
3 - 2 - Caesar med i Beta
4 - 1 - David med i Alfa
4 - 3 - David med i Gamma

Gammal tråd, men jag fortsätter...

Kan man inte skippa "membership"-tabellen och JOINa mellan Users och Groups.

Varför gör man relationer på detta sätt?

<b>Kan man inte skippa "membership"-tabellen och JOINa mellan Users och Groups.</b>
Man kan, men det innebär ju stora begränsningar...

<b>Varför gör man relationer på detta sätt?</b>
För att det är dumt att inte göra det... och det är dumt på många olika sätt. T ex vill man inte bygga in begränsningar i databasen utifall det inte behövs. Säg at du har tre roller, medarbetare, chef, admin och med en lösning utan "menbership" så kan en användare endast tillhöra en grupp. Men har men designat ett system som använts ett tag för olika kunder så vet man att kravet på att en användare skall kunna vara admin OCH chef kommer att komma.

På första föreläsningen man går på om databasdesign så kommer något som kallas normaliseringsregler upp. Det är oftast MYCKET viktiga att följa (iaf upp till N3, resten brukar ge sig ändp), men undantag kan ske t ex pga prestanda skäl (i ett datawarehouse vill man inte behöva räkna ut värden på historisk data utan kan räkna ut denoch lagra i separat kolumn t ex).

Just frågor om användargrupper mm har varit uppe ett otal gånger och det finns mycket bra skrivet i de gammla trådarna.

Jag är mitt uppe i databasdesign av en site som är större än något jag någonsin gjort och givetvis vill jag att prestandan skall vara GRYM och så lite fel som möjligt skall uppstå någonstans på den framtida siten.

Tabellerna skall vara som följer:

Customers (Kunddata)
- ID
- surename
- lastname
- persnr
- address
- postalno
- city
- country
- savedcart (överflödigt?)
- measurements (detta är egentligen 20 fält med olika mått men skriver bara ett här)

Carts (sparade kundvagnar - tas bort efter slutförd beställning)
- ID
- CustomerID
- product1
- product2
- product3
...
- product10

Transactions (slutförda beställda)
- ID
- CustomerID
- transactiondate
- Status
- Message
- Orderdata (vilka produkter som beställts)
- DeliveryAddress1
- DeliveryAddress2
- DeliveryPostalno
- DeliveryCity
- DeliveryCountry


Och nu till det kluriga...
Det skall inte vara några specifika produkter utan mera produktgrupper med en massa tillval till.
Så här har jag skrivit ned på kladden nu:

Fabrics
- ID
- name
- description
- type
- group (productgroups.ID)

Productgroups
- ID
- Name
- Description
- Pocket (olika av tillval som produktgruppen skall ha, typ array)
- Extras (olika av tillval som produktgruppen skall ha, typ array)
- Fit (olika av tillval som produktgruppen skall ha, typ array)
- Image
- Image_thumb (eller om detta generas automatiskt, får se hur jag gör här)

--------------------------------------------------------------------------------

Skall jag använda relationstabeller någonstans, var och varför?

Andra tips vad som skall göras/ändras?

<b>Skall jag använda relationstabeller någonstans, var och varför?</b>

Det blir ett stort rungande JA!!! ;-)

Vi kan börja med din Cart tabell som inte verkar 100% genomtänkt. Tänk dig följande secenario: Jag är en potentiell kund kund och vill beställa varor av dig, närmare bestämt 11 stycken olika varor... Tyvär kan jag inte göra mitt köp hos dig eftersom du bara stödjer 10 varor(produkt1, produkt2...produkt10) och jan vänder mig till attt annat ställe. Just för därför vill man ha kopplingstabeller, för att kunna koppla flera produkter till en kundvagn.

Carta borde se ut såhär
Carts
* CartID
+ CustomerID

och en kopplingstabell som ser ut så här:
CartProducts
* Cart
* ProductID
- lite annat tjafs som tex antal(längd, vikt) mm

* = primärnyckel
+ = främmande nyckel
- = attribut


Vilka relationer som bör finnas brukar ge sig kanska snabbt om man ritar upp databasdesignen. Tumregel: alla lösningar som heter produkt1, produkt2, produkt3 osv eller moms1, moms2, moms3 osv är en dålig lösning. T ex vad händer den dag du skall sälja systemet utomlands och de har fler än tre momsatser? Att då svara "Jo, vi har en tokbra produkt men vi kan inte sälja den till er utan att göra stora förändringar.." håller inte (jobbade en gång med en produkt där det fanns moms1 till moms5 och de tyckte att de hade tagit till ordentligt, det jobbiga kom med en stor kund som var tvungen att ha stöd för nio momssatser).


Frågor:
Customer:
* vad skall savedcart göra? Visa vilken cart en användare ha? Det finns ju allaredan i carttabellen så precis som du anar är den överflödig
* measurements. Kan vara ide att lägga det som kopplingstabell beroende på hur det är tänk att användas.

Nä, måste jobba oxå... ;-)


Edit:
Productgroups
- Pocket (olika av tillval som produktgruppen skall ha, typ array)
- Extras (olika av tillval som produktgruppen skall ha, typ array)
- Fit (olika av tillval som produktgruppen skall ha, typ array)
beroende på hur dessa ät tänkte att funger kanske man skall bryta ut dem i en tabell där alla extras listas och sedan ha en kopplingstabbell mot Productgroups. Samma gäller för Pocket och Fit.

Nä, måste verkligen jobba oxå... ;-)

hehe, finns inte så många produkter, om man inte vill beställa flera av samma produkt, men då produkterna är ganska dyra så vill man nog inte göra detta :D
Men det är lika bra att ta det säkra före det osäkra
CartProducts (table) kör jag på!

sälja systemet kommer med säkerhet INTE hända, däremot att vi kanske lanserar webbshopen i andra länder, men antagligen kommer alla produkter ha moms inkluderat i produkterna och fraktkostnad (vi kör postförskott endast nu i detta skede). Då är det lättare att justera med priser och sånt eftersom alla produkter kommer ha samma momssats (25%)



Productgroups - det skall bara vara 2-4 tillval för varje (extras, pocket, Fit), kan vara en idé att göra en kopplingstabell, tror det blir smidigare med administrering av produkterna (produktgrupperna)

Savedcart - överflödig, jo misstänkte detta.

<b>Gus - you the man!</b>

Det börjar bli något nu :)


Customers (Kunddata)
- ID
- surename
- lastname
- persnr
- address
- postalno
- city
- country
- password
- Member_since
- measurements (detta är egentligen 20 fält med olika mått men skriver bara ett här)

MemberValidation
- ValidationKey (genererad)
- CustomerID

Carts
- CartID
- CustomerID
- TransactionID (om beställning utförd)

CartProducts
- Cart
- ProductID
- ProductExtra
- ProductFit
- ProductPocket
<b>är osäker på de tillvalen som användaren skall välja till. Vilka tillval som finns är ju beroende på produktgruppen (productgroups), göra en till tabell?</b>


Transactions (slutförd beställning)
- ID
- CustomerID
- transactiondate
- Status
- Message
- Totalcost
- Deliverycost
- CartID
- DeliveryAddress1
- DeliveryAddress2
- DeliveryPostalno
- DeliveryCity
- DeliveryCountry

Deliverypricing (om land inte finns, fraktfritt)
- DeliveryCountry
- Pris

Fabrics
- ID
- name
- description
- type
- productgroup (productgroups.ID)

Productgroups
- ID
- Name
- Description
- Price
- Image
(- Image_thumb )

ProductExtras
- ID
- ProductgroupsID
- Name (Pocket, Extras, Fit)
- Choice (olika tillval beroende på produktgrupp)


<b>Angående fabrics...</b>
en fabric-typ kan tillhöra flera produkter/grupper, skall väl ha en relationstabell här också?!

Fabricsproductgroups
- fabricID
- productgroupID

<b>Vad tror Gus om detta?</b>

Nu har jag rört till det...


<b>fabrics (olika tygsorter)
ID name description fabricstype</b>
1 Blå manchester Ett fint tyg med skön struktur. 1
2 Rutigt Blå med vita ränder 3
3 Randigt Kritstreckrandigt 2
4 Himmelsblå skjorttyg Snygg himmelsblått tyg för skjortor 4
5 Marinblå skjorttyg NULL 4


<b>fabricproductgroups (vilka tyger som tillhör vilka produkter (produktgrupper))
FabricsID ProductgroupsID</b>
1 1
2 1
3 1
4 2
5 2



<b>fabrictypes (mönster eller typ av tyger)
ID name</b>
1 Manchester
2 Randigt
3 Rutigt
4 Skjorttyger
5 Siden


<b>
productgroups (de olika produkterna (produktgrupper))
ID Name Description Price</b>
1 Kostym En kostym i valfritt tyg ur sortimentet. 1998
2 Skjorta En skjorta i valfritt tyg ur sortimentet. 498
3 Kavaj Om du inte behöver några kostymbyxor till. 1199
4 Byxor Om du inte behöver en kavaj, 799


Och vad vill jag med detta egenligen?

Hmm, Jag ville ha ut alla skjortor och de tyger som är kopplade till skjortor.


testade lite med detta, men den fick fnatt och jag fick ut allt 4 ggr

"SELECT Productgroups.Name, Productgroups.Description, (
Fabrics.name
), Fabrics.description
FROM Productgroups, Fabrics, Fabrictypes, Fabricsproductgroups
WHERE Fabrictypes.ID =4
AND Productgroups.ID =2"

(fråga borttagen så den var mer SQL relaterad)

... raderad