[Osiris]

Tänk dig ett publiceringsverktyg med exempelvis följande sidmallar:

• Vanlig webbsida
• Kalender-info
• Länk-resurs
• Ärendehanterings-info
• Bloggpost
• etc etc

Bör man lägga alla sidtypers speciella egenskaper i samma tabell i databasen eller borde jag dela upp dem i egna tabeller beroende på sidtyp?

Det riskerar att bli säkert 50 fält i tabellen, men det kanske uppväger att ställa SQL-frågan mot flertalet unika tabeller?
Andra förslag?

[najk]

Mitt tips: Lägg en övergripande tabell och dela upp datat i flera tabeller beroende på typ. Tänk på vad som blir lättast att utöka med fler funktioner senare. Titta även på att slå ihop sökningar ur tabeller, typ join..

[Osiris]

Tack för input!

Är inne på detta. Tänkte ha en tabell vardera för exempelvis länkar, kalenderinlägg, foruminlägg, bilder i gallerier etc.

Samtidigt håller jag på och gör ett PageData-objekt som programmeringsmässigt ska innehålla alla egenskaper som respektive sidtyp ska kunna ha och då blir det lite skumt med antalet SQL-frågor som ställs vid kollektioner av sidor av olika sidtyper...

Är bekant med hur det ser ut i exempelvis EPiServer men så j-vla db-intresserad är jag inte så jag orkar reda ut den strukturen för att göra något liknande.

Tips?

[Conny Westh]

Normalisera tabellerna efter 3:e normalformen så löser sig detta med automatik, då får du bra struktur.

Dvs varje värde ska vara atomärt (odelbart) som förnamn, efternamn, postnr, postort m.m.

Sen ska du se till att varje atomärt värde endast är beroende av primärnyckelt, hela primärnyckeln och ingenting annat än primärnyckeln, då har du löst problemet.

[Osiris]

Det är ungefär vad jag gjort, men om man gör kollektioner av sidor som har olika sidtyper kan det bli massor med SQL-frågor. Eller?

[Conny Westh]

Ursprungligen postat av Osiris

Det är ungefär vad jag gjort, men om man gör kollektioner av sidor som har olika sidtyper kan det bli massor med SQL-frågor. Eller?

Du kan alltid göra en VIEW eller stored procedure om du vill göra komplexa SQL-frågor mot databasen, både VIEW och STORED PROCEDURE förkompileras när man sparar dem i databasen så de blir blixtsnabba om du har rätt optimerade index.

Dessutom blir de enklare att anropa.

Du kan ju bygga minst en VIEW för varje Page-typ som du vill ha...

[RickardP]

Du kan även ha en enkel tabell med sidmallstyper, sedan en tabell med inställningar av sidmallstyper där du har en kollumn som säger vilken sidmallstyp det är, en som säger vilken inställning det är och en som säger vilket värde inställningen har.

Inställningarna går också att ha en beskrivande tabell för enskilt.

Då kan man lägga in flera inställningar för sidmallstyperna utan att behöva editera tabellens struktur.

Kan se ut så här:

Sidmall
- ID
- Namn

Inställningar
- ID
- SidmallID
- EgenskapsID
- EgenskapsVärde

Egenskap
- ID
- Beskrivning


Något i den stilen fast då självklart på engelska borde fungera ganska bra, alla gemensamma kolumner kan dessutom då liga i Sidmall tabellen och endast dem som skiljer dem åt ligger i övriga.