[Darkmagic]

Hej,

Skulle någon vilja hjälpa mig som inte är så duktig på databaser om vilket man bör göra i följande läge:

Vi har ett användarsystem där vi har grupper och en användare kan tillhöra flera grupper och sedan i sin tur så kan alla moduler dela sin data till grupper.

Exempel:
Användare -> tillhör grupp 1-3 + 5.
Dokument1 delas till grupp 1 + 4.
Formulär1 delas till grupp 2 + 5
och låt säga att vi har 10 andra moduler som har denna rättighets struktur.

Nu till frågan så har vi en tabell som innehåller Groups.

Efter det så har vi 2 sätt att gå det ena är att vi skapar en generisk tabell som heter något med GroupRights som ser ut såhär:

PK ObjectId (int) - Denna innehåller Idt från ObjectTypes tabell (exempel UserID om ObjectType är User)
PK GroupId (int) FK till Id i Groups tabellen
PK ObjectType (int) - Denna anger om det är en användare/dokument/formulär etc etc..

Vi kan också bygga det såhär:

UsersToGroups tabell
PK UserId - FK till Users.Id
PK GroupId - FK till Groups.Id

DocumentsToGroups tabell
PK DocumentId - FK till Documents.Id
PK GroupId - FK till Groups.Id

etc etc...

Vad skulle ni säga är bäst?
Vad är pros/cons?

-Jag kan ha gjort stora fel här, jag är som sagt inte så värst bra på databaser.

Tacksam för svar

[Conny Westh]

För att uppnå en hyfsat flexibel modell bör du göra ungefär så här:

Du har en tabell för USER och en för GROUP och en tabell för RESOURCE.


För att koppla ihop USER och GROUP så att du får en många-till-många-relation behöver du ha en "länktabell" mellan de två låt oss kalla den USERGROUP.

Tabellen USER har en PK som vi kallas USERPK och GROUP har en PK som vi kan kalla GROUPPK.

Tabellen USERGROUP behöver då ha två kolumner som vi kan kalla för USERFK och GROUPFK (eftersom de är främmande nycklar ii USERGROUP som pekar på PK i USER respektive GROUP:

USER:
- USERPK (PK1)

GROUP:
- GROUPPK (PK1)

USERGROUP:
- USERFK (PK1)(FK1) -> USER.USERPK
- GROUPFK (PK2)(FK2) -> GROUP.GROUPPK

RESOURCETYPE:
- RESOURCETYPEPK (PK1)



RESOURCE:
- RESOURCEPK (PK1)
- RESOURCETYPEFK (FK1) -> RESOURCETYPE.RESOURCETYPEPK


USERGROUPRESOURCE:
- USERFK (PK1)(FK1) -> USERGROUP.USERFK
- GROUPFK (PK2)(FK2) -> USERGROUP.GROUPFK
- RESOURCEFK (PK3)(FK3) -> RESOURCE.RESOURCEPK


Sen behöver du komplettera med eventuella databärande kolumner, jag har bara lagt upp de som är primärnycklar och främmande nycklar.

RESOURCETYPE skulle då kunna vara Dokument eller Formulär som rena tupler, men här går det ju att variera sig en del, om man vill ha hårdare styrning av egenskaper så kanske egna tabeller för Dokument respektive Formulär är på sin plats.

Men väljer man att lägga till Dokument och Formulär i stället för RESOURCETYPE så bör de peka på RESOURCE, annars får man en massa duplicerad funktionalitet i databasen.

Om Dokument och Fformulärhar egna unika egenskaper som behöver lagras så kan det vara att föredra att skapa egna tabeller för dem.

Men det här är bara idéer och uppslag då jag inte vet exakt hur du ska använda systemet och då finns det flera avvägningar man får göra innan man hittar en optimal struktur.

[Darkmagic]

Tack så mycket för detta svar!

En liten fråga angående prestanda, vilket är generellt bäst ut prestanda synvinkel? Att ha separata tabeller som binder varje modul eller att ha en generisk tabell med ResourceType?

Om det är skillnader hur stora är de då?

[Conny Westh]

Ursprungligen postat av Darkmagic

Tack så mycket för detta svar!

En liten fråga angående prestanda, vilket är generellt bäst ut prestanda synvinkel? Att ha separata tabeller som binder varje modul eller att ha en generisk tabell med ResourceType?

Om det är skillnader hur stora är de då?

Skillnaderna i prestanda rör sig om nanosekunder (i västa fall millisekunder) så det kan du lugnt strunta i tills du får gigantiska databaser (då går affärerna nog så bra så du har råd att hyra in någon som optimerar åt dig).

Men så här i början behöver du inte fundera så hiskeligt mycket på prestanda, tänk på att bygga en normaliserad struktur i första hand med naturliga primärnycklar, Främmande nycklar och lämpliga index så kommer du klara dig rätt bra.

Se till att ha flera lämpliga index för de kolumner du använder i Joinar och WHERE-satser.

Om du upplever problem med prestanda i enskilda frågor så får vi kika på det när problemet uppstår, men spendera din tid på att bygga en bra normaliserad struktur i databasen och ett effektivt och enkelt användargränssnitt utan en massa krusiduller i första hand.

[Darkmagic]

Tack så mycket för hjälpen! Jag har fått lite mer klarhet i hur jag ska göra

[Clarence]

Vill också instämma i Connys förslag.

Det enda negativa du har i prestanda-synpunkt är många foreign keys och det blir endast aktuellt att se över om du når en väldigt hög write ratio - vilket inte alls är normalt i en sån typ av applikation.

Sen kan det ur prestandasynpunkt finnas anledningar att spara denormaliserad data ... men det beror till 100% av din applikations användning av datan medans strukturen som här ges är en sund normaliserad modell att utgå ifrån oavsett andra parametrar.