[Conny Westh]

Jag håller med Clarence i det mesta, jag anser dock inte att prestanda skulle vara ett problem (i de flesta fall). Sätter man rätt index så går detta blixtsnabbt.

Tabell: TBL_User
- PK_User
- Namn

IndexU1: PK_User
IndexU2: Namn


Tabell: TBL_Attribute
- PK_Attribute
- AttributeText
- AttributeType (Intressen, Livsstil m.m. kan även ligga i en egen tabell för att uppnå ännu högre grad av flexibilitet)

IndexA1: PK_Attribute
IndexA2: AttributeText



Tabell: TBL_UserAttribute
- FK_User -> TBL_User.PK_User
- FK_Attribute -> TBL_Attribute.FK_Attribute

IndexUA1: FK_User, FK_Attribute
IndexUA2: FK_Attribute, FK_User


PK => Primary Key
FK => Forreign Key

PK brukar ju alltid bli indexerat med automatik i relationsdatabaser, men det är vettigt att skapa kombinationsindex manuellt så man få upp prestanda ordentligt i databasen.

Det är väl ingen som använder ISAM längre då även MySQL har InnoDB idag med riktig relationshantering (även om InnoDB har vissa brister ännu, så är den betydligt flexiblare än ISAM).

Det här funkar alldeles utmärkt för binära egenskaper dvs Ja/Nej, Finns/Finns inte. Men man kan ju använda en Unsigned int av olika sort finns ju 16, 32, 64 bitars varianter och slå på/av en bit i taget för att spara minne, men det blir betydligt krångligare logik, men vid extremt stora databaser så kan det vara en väg att gå, även om jag i det längsta skulle undvika det om jag har krav på flexibilitet i attributfloran, det passar bättre nr man har fasta/förbestämda attribut.