[Database-design] Koppeling verschillende typen data

[McVirusS]

Situatie: Ik heb een website met daarop een aantal "teasers", deze teasers kunnen linken naar 3 verschillende soorten pagina's:

* Keiharde (externe) URL
* Voorgedefineerde URL (url naar onderdeel van de website, komt uit een losse tabel)
* een CMS Pagina

Teasers worden aangemaakt via het CMS. Aan een teaser kunnen meerder URL's gekoppelt worden (op basis van datum, morgen kan er bijvoorbeeld andere pagina gelinkt worden dan vandaag). Hoe zou jij dit koppelen in de database?

Ik had samen met een collega al 2 opties bedacht maar heb bij alle 2 een beetje het gevoel dat het een te ranzige oplossing is.

Optie 1:
-----------------------------------------------------------------------------
Teasers
-------
Teasers_id
Titel

Soort
-------
Soort_id
Soort

Koppel
-------
Teasers_id
Soort_id
Datum
Koppeldata

------------------------------------------
In de soort tabel komen de 3 verschillende soorten links te staan (voordeel is uitbreidbaarheid). In het veld koppel.koppeldata staat naar gelang de soort het id van CMS pagina, keiharde URL of id van voorgedefineerde tabel.
-----------------------------------------------------------------------------

Optie 2:
-----------------------------------------------------------------------------
Teasers
-------
Teasers_id
Titel

Koppel
-------
Teasers_id
URL
pagina_id
cmspagina_id
datum

------------------------------------------
Gewoon een koppeltabel waar keihard de verschillende types in staan gedefineert, nadeel is dat dit absoluut niet dynamisch is en dat je een hoop NULL velden krijgt in de database.
-----------------------------------------------------------------------------

Ik kon geen 3e mogelijkheid bedenken en nadeel is dat je de relaties eigenlijk bij beide varianten alleen in de code kan leggen en niet in de Query.

Snap je het probleem en heb je een betere oplossing?

(Tabelnamen en dergelijke zijn fictief en dienen slechts als voorbeeld).

[McVirusS]

Pelle kwam nog met een 3e oplossing; optie 1 maar dan in de soorttabel een "URL-prefix" zetten zodat je in de code geen rare dingen meer hoeft te doen om juiste URL te krijgen en toch dynamisch blijft.

[gorgi_19]

ff denken...
1 teaser heeft per definitie:
- teaserID
- titel
- beschrijving
- plaatje

Indien 1 van deze verschillen, zijn het meerdere teasers, in mijn opzicht.

Dan de beschikbaarheid..
ID
TeaserID
Datum
Lokatie

---
In lokatie zou ik dan zelf of het paginaID, of de interne URL, of externe URL neerzetten. Door middel van een functie zou ik dan de juiste 'output' genereren.

[Pelle]

Precies.. en toch eigenwijs zijn en een topic openen... tsss

[gorgi_19]

Pelle schreef op 06 May 2003 @ 17:03:
Precies.. en toch eigenwijs zijn en een topic openen... tsss

Tsk.. En mij voor jan met de korte achternaam ongeveer dezelfde optie laten bedenken..

[McVirusS]

Gorgi: dat is toch min of meer mijn optie 1?

[gorgi_19]

McVirusS schreef op 06 May 2003 @ 17:05:
Gorgi: dat is toch min of meer mijn optie 1?

Ik heb er iig 1 tabel uitgesloopt.. Volgens mij lijkt hij meer op optie 2

[ACM]

Ik voel eigenlijk wel wat voor jouw optie 2.

Dat velden NULL kunnen zijn is opzich natuurlijk niet erg. Het leuke daarvan is dat je je data zo terug kan krijgen:

code:

CASE 
   WHEN url NOT IS NULL 
      THEN url 
   ELSE WHEN pagina_id NOT IS NULL 
      THEN 'paginaprefix' || pagina_id
   ELSE WHEN cms_id NOT IS NULL
      THEN 'cms_prefix' || cms_id
   ELSE
       'invalid url url'
END
AS full_url

Scheelt je weer gedoe in je code

Eenzelfde variant op je eerste tabel of gorgi's versie kan trouwens ook wel, 't nadeel is alleen dat je ofwel te veel data opslaat (steeds weer die prefix) of dat je een veld een foutief type moet geven, omdat het zowel integers als characters moet kunnen bevatten.