[Database] Reacties met meerdere foreign keys en...

[TangLeFuzZ]

Hey,

Ik zit nu al een tijdje in dubio over het volgende (het is iets vrij simpels, maar ik ben er zelf nog steeds niet 100% over uit).

Stel ik heb een aantal verschillende onderdelen op mijn site waar op gereageerd kan worden:

- Artikelen
- Agenda Items
- Dossiers

Ik wil al mijn reacties in 1 tabel hebben, een voorbeeld van hoe een simpele reacties tabel er uit zou kunnen zien is:

- id
- reactie
- artikel_id
- agenda_id
- dossier_id

Dit vind ik zelf alleen geen nette manier, omdat er nu altijd maar 1 van de 3 foreign keys gevuld is. Het liefst zie ik 1 foreign key:

- id
- reactie
- item_id

En dan een extra 'items' tabel:

- id
- itemid
- itemtype ("agenda", "artikel" of "dossier")

Maar ook dat vind ik weer niet zo'n hele nette oplossing, en hij zal wat zwaarder zijn dan oplossing 1.
Wat is volgens jullie de beste manier om zoiets aan te pakken?

Verder zit ik nog met het volgende;

stel ik heb een tabel met een paar miljoen postings... die groter en groter aan het worden is. Zou het dan niet beter zijn om bijvoorbeeld met archief tabellen te werken, waar oudere postings in komen te staan? Dus bijvoorbeeld elk jaar een nieuwe postings tabel... qua snelheid zou dat wel mooi werken, maar ik vraag me af of zoiets wel in een nette structuur te verwerken is...

[NMe]

Database ontwerpvragen mogen in Software Engineering & Architecture.

Ik zou persoonlijk denk ik kiezen voor je eerste optie, waarbij dus altijd 2 van de 3 velden leeg blijven. Dat betekent inderdaad wat redundantie, maar het maakt je queries wel een stukje lichter, wat voor websites altijd wel mooi is.

Wat betreft archieftabellen: waarom zou je dat doen? In welke zin wordt de zaak daar sneller van volgens jou?

PRG>>SEA

[Tukk]

-NMe- schreef op zaterdag 11 maart 2006 @ 14:49:
Database ontwerpvragen mogen in Software Engineering & Architecture.

Ik zou persoonlijk denk ik kiezen voor je eerste optie, waarbij dus altijd 2 van de 3 velden leeg blijven. Dat betekent inderdaad wat redundantie, maar het maakt je queries wel een stukje lichter, wat voor websites altijd wel mooi is.

Wat betreft archieftabellen: waarom zou je dat doen? In welke zin wordt de zaak daar sneller van volgens jou?

PRG>>SEA

Als je een BTREE index op de kolom itemtpye zet zal de query IMHO geen negatieve invloed hebben, je krijgt dan snel een filtering op het type reactie, daarentegen zou ik toch kiezen voor een andere optie.

Wat gaat er fout bij het volgende?

Tabel : Reacties
• id
• reactie
• item_type
• item_id

Als je maar drie types van reactie hebt kun je daar een BTREE index op zetten, de filtering is dan erg vlot (m.b.v. een view mischien). En dan heb je de tabel zoals je hem verder wil hebben.

[ Voor 5% gewijzigd door Tukk op 11-03-2006 15:12 ]

[T-MOB]

-NMe- schreef op zaterdag 11 maart 2006 @ 14:49:
Database ontwerpvragen mogen in Software Engineering & Architecture.

Ik zou persoonlijk denk ik kiezen voor je eerste optie, waarbij dus altijd 2 van de 3 velden leeg blijven. Dat betekent inderdaad wat redundantie, maar het maakt je queries wel een stukje lichter, wat voor websites altijd wel mooi is.

Nadeel van zo'n oplossing is dat ie niet schaalbaar is. Wat als er straks nieuwsitems bij gaan komen, of recepten, etc. Je blijft kolommen toevoegen. Mocht je zoiets willen om een JOIN te voorkomen dan zou ik persoonlijk voor een ENUM veld gaan ipv meerdere kolommen met bitfields. Dat is minder redundant en je hoeft de betekenis van je data niet uit kolomnamen af te leiden.

[MicroWhale]

tabel:
item_id
item_type

(waar itemtype == (evt. afdwingen in extra tabel met restricties op item_type)
reactie
agenda
artikel
dossier)

per type een tabel:
item_id foreign & primary
...
...
...


op deze manier heeft elk type zijn eigen data-model en kun je een vrij aantal velden aan dat type toevoegen.

[ Voor 23% gewijzigd door MicroWhale op 12-03-2006 12:00 ]