[database] nog verder normaliseren?

[Nielsz]

Ik dus oa nieuwsitems brengen, en daar op kunnen reageren.
Maar niet alleen nieuwsitems, maar ook shortnieuws, columns, reviews noem maar op.
Deze hebben allemaal een aantal gemeenschappelijke velden (submittedBy,submittedDate,Title) enzo.

Nu dus de vraag, hoe ga ik het doen?

a) een aparte tabel maken voor elk item.
b) 1 table maken met alle gemeenschappelijke velden, en daarachter een rij velden "var1 var2 var3" noem maar op. (waar var1 in shortnieuws staat voor url, en in review voor een plaatje oid)
c) 1 table maken met alle gemeenschappelijke velden, met een aparte tabel erbij:

extra:
====
itemid
countid
varname
varvalue

Waar je dus een mysql_fetch_row() moet gebruiken om alle gegevens over dat topic binnen te halen.


Voor welke keuze zouden jullie gaan

[Verwijderd]

kun je wat duidelijker zijn in je vraagstelling?
ik zal wel wat proberen...

een tabel met daarin alle gemeenschappelijke velden en voor alle afwijkende velden (die bijvoorbeeld alleen bij een review voorkomen) een aparte tabel die gekoppeld is middels een foreign key(id van het record in de eerste tabel) aan het item in de eerste tabel.
in de eerste tabel zet je dan een extra kolom neer met daarin een categorieaanduiding(review, nieuws, enz..) zodat je van ieder record in de eerste tabel weet in welke andere tabel je moet kijken voor de info die er nog bij hoort..

is misschien een beetje vaag wat ik nu zeg maar ik weet 't zou gauw niet anders op te schrijven

[Nielsz]

Ok

nieuws: submittedBy,submittedWhen,PostedBy,Title,Url,UrlName,Picture,inleiding,text,conclusie

shortnieuws:
submittedBy,submittedWhen,PostedBy,Title,Url,UrlName,text

column
submittedBy,submittedWhen,PostedBy,Title,text,plaatje

Zoals je ziet is een groot deel gewoon hetzelfde.
nu kan ik
a) 3 tabellen aanmaken: nieuws,shortnieuws & column
b) 1 table maken met submittedBy,submittedWhen,PostedBy,Title, en daarachter field1 field2 field3 field4.

c) 1 maintable bouwen, met alleen de submittedBy,submittedWhen,PostedBy,Title, en dan een extratable, met dingen die jij net vertelde. Waar dus alleen maar instaat:
itemid - variabelenaam - variabeleinhoud:
12 - url - www.blaat.nl?id=2134
12 - urlname - blaat.nl
12 - plaatje - /blaat.gif

Snappie?

[wasigh]

waar heb je die gemeenschappelijke data voor nodig? wil je daar op kunnen selecteren ofzo?

Die data hoort bij een item, dus opslaan bij het item is dan logischer. Je hebt geen kans op dat je data dubbel opslaat dus hoef je dat niet uit te normalizeren.

Gewoon voor elk item een aparte tabel dus.

[Nielsz]

Op zondag 23 december 2001 16:04 schreef wasigh het volgende:
waar heb je die gemeenschappelijke data voor nodig? wil je daar op kunnen selecteren ofzo?

Die data hoort bij een item, dus opslaan bij het item is dan logischer. Je hebt geen kans op dat je data dubbel opslaat dus hoef je dat niet uit te normalizeren.

Gewoon voor elk item een aparte tabel dus.

Feit is dat ik dan niet op 1 id kan identifien: iow: als ik show.php?id=12 doe kan ik niet eerst een nieuws krijgen, en met show.php?id=13 een shortnieuws krijgen. Ik heb dus meerdere dezelfde id's waar ik niet blij mee ben.

[wasigh]

Op zondag 23 december 2001 16:08 schreef Nielsz het volgende:

[..]

Feit is dat ik dan niet op 1 id kan identifien: iow: als ik show.php?id=12 doe kan ik niet eerst een nieuws krijgen, en met show.php?id=13 een shortnieuws krijgen. Ik heb dus meerdere dezelfde id's waar ik niet blij mee ben.

Ok, dat is een goede reden


Maar dat is op te lossen met een extra parameter meegeven aan je php..


Je zou ook een koppelingstabel kunnen gebruiken
met
[id]
[type]
[item-id]

en aan de hand van een php vertaal slag de goede db query-en maar erg netjes is dat niet..

* wasigh is heftig aan het denken.

[Nielsz]

Nopesz
En ik moet in mijn reactietable aangeven wat voor type het is. Anders krijg ik van ?id=12 de reacties van shortnieuws ertussen enzo

[Verwijderd]

Maar dat is op te lossen met een extra parameter meegeven aan je php..

waarom kan dat niet? gewoon show.php?soort=short&id=13

gaat toch perfect? voor alles een aparte record en voor elke soort een aparte table...

[Nielsz]

Op zondag 23 december 2001 16:19 schreef Jppr het volgende:

[..]

waarom kan dat niet? gewoon show.php?soort=short&id=13

gaat toch perfect? voor alles een aparte record en voor elke soort een aparte table...

Jij vind voor elk soort nieuws een aparte tabel perfect? Ik niet iig. In principe is het verschil tussen nieuws en shortnieuws alleen maar dat er een plaatje bij nieuws zit en bij shortnieuws niet (zum beispiel)

[Verwijderd]

Kan je niet gewoon 1 tabel aanmaken, met daarin:
type,submittedBy,submittedWhen,PostedBy,Title,Url,UrlName,Picture,inleiding,text,conclusie,plaatje

Dan heb je toch alles in 1 tabel, en verschillende recordnummers.
Je kunt de record indentificeren aan de hand van type, en alle benodigde variabelen staan er ook in, degene die je niet nodig hebt, die vul je gewoon niet in, of bedoelde je dit niet??

[Nielsz]

Maar bij review heb ik bv 3 plaatjes. Moet ik dan 3 keer een plaatjesveld erin zetten, die helemaal niet gebruikt worden met nieuws en shortnieuws

[wasigh]

Op zondag 23 december 2001 16:57 schreef Nielsz het volgende:
Maar bij review heb ik bv 3 plaatjes. Moet ik dan 3 keer een plaatjesveld erin zetten, die helemaal niet gebruikt worden met nieuws en shortnieuws

nee dan normalizeer je dat naar een image tabel en een image_newspost koppelings tabel

[Nielsz]

Op zondag 23 december 2001 17:04 schreef wasigh het volgende:

[..]

nee dan normalizeer je dat naar een image tabel en een image_newspost koppelings tabel

en dan moet ik dat ook doen met de andere dingen (zoals inleiding, conclusie (die heb ik ook niet overal).
Dat houd dus in dat die methode die ik hierboven al beschreef ongeveer hetzelfde is

[Verwijderd]

yep

[Johannes]

Op zondag 23 december 2001 17:11 schreef Nielsz het volgende:

[..]


en dan moet ik dat ook doen met de andere dingen (zoals inleiding, conclusie (die heb ik ook niet overal).
Dat houd dus in dat die methode die ik hierboven al beschreef ongeveer hetzelfde is

Voor dingen die niet meerdere malen kunnen voorkomen(zoals inleiding en conclusie), kun je ook gewoon het veld '' of NULL laten zijn(zit wel verschil tussen). En waarom speciaal voor plaatjes een aparte tabel? De [img]-tags kun je toch ook gewoon gebruiken?
Ik vraag me af of er dan nog wel zoveel verschil zit tussen nieuws, reviews, etc.

[dusty]

We gaan even wat brandhout op deze thread gooien ( en of we wat mensen kunnen vangen )

elke tabel lijkt in wezen op elkaar.
[primary key]
[data kolom]
[eventueel meer data kolommen]

Dus zou je ook in principe ALLES in een tabel kunnen zetten. Door gebruik te maken van 1 tabel.


[ObjectID, OrderID,] (PK)
ValueID

De ObjectID en OrderID is een unieke sleutel,

Waar de OrderID de "volgorde" van de velden aangeeft,
En waar OrderID = 0 geef je aan welke type je object is.

Nou komt natuurlijk de vraag waarom los je het dan niet op deze manier op?

[Verwijderd]

Op zondag 23 december 2001 23:10 schreef dusty het volgende:
We gaan even wat brandhout op deze thread gooien ( en of we wat mensen kunnen vangen )

elke tabel lijkt in wezen op elkaar.
[primary key]
[data kolom]
[eventueel meer data kolommen]

Dus zou je ook in principe ALLES in een tabel kunnen zetten. Door gebruik te maken van 1 tabel.


[ObjectID, OrderID,] (PK)
ValueID

De ObjectID en OrderID is een unieke sleutel,

Waar de OrderID de "volgorde" van de velden aangeeft,
En waar OrderID = 0 geef je aan welke type je object is.

Nou komt natuurlijk de vraag waarom los je het dan niet op deze manier op?

Je hebt er een gevangen
ik zou het niet op jouw manier doen omdat je dan een grotere kans hebt om een rotzooi te maken van je database... een voordeel van het (zoveel mogelijk) normaliseren is het uitsluiten van dubbbele gegevens en het 'gescheiden' opslaan van de gegevens en zo meer overzicht te bewaren.

ff als voorbeeld:
je hebt een database met daarin gegevens over huurwoningen met de bijbehorende eigenaar.
iedere woning heeft een adres in een bepaalde plaats, ook de eigenaar heeft een adres. op zich kun je dit gerust in één tabel mikken maar, wanneer bijvoorbeeld een eigenaar, die meerdere huizen bezit, verhuist moet er een adreswijziging doorgevoerd worden. als die woningeigenaar dan toevallig 50 woningen bezit om te verhuren, moeten al die 50 woningen voorzien worden van een nieuw eigenaarsadres... have fun!
dus:
krijg je alweer 2 tabellen:
tabel WONINGEN en tabel EIGENAAR
en in dit voorbeeld gaat het zelfs nog verder
zoals plaatsnamen, straatnamen, huurder gegevens enz...

zo bekijk ik dit verhaal ongeveer.

[mvdejong]

Hoe ik het zou doen :

Item = ItemNum, ItemSoort, SubMittedBy, SubmittedWhen, PostedBy, Title, Url, UrlName

ItemNum, de primary key, is een unieke integer binnen de item-tabel.
ItemSoort geeft dan aan of het nieuws, shortnieuws, column, enz., is.

Picture = ItemNum, PictureNum, ...
Inleiding = ItemNum, InleidingNum, ...
Text = ItemNum, TextNum, ...
Conclusie = ItemNum, ConclusieNum, ...

PictureNum enz. zijn volgnummers (1,2,3,...) binnen ItemNum. Je kunt ze eventueel weglaten als het logisch is dat er van dat soort altijd maar eentje voor een item voorkomt, en dan zou je ze uit normalisatie-overwegingen wel in de oorspronkelijke tabel moeten opnemen, maar uit logica-overwegingen niet.

Als Inleiding en Conclusie qua opslag identiek zijn aan Text, kun je besluiten tot :

Text = ItemNum, TextSoort, TextNum, ...

TextSoort is dan Text, Conclusie, Inleiding, enz.
Voor TextSoorten die logischerwijs maar 1 maal kunnen voorkomen voor een item is dan TextNum niet relevant.

[Nielsz]

*_{* trap *}*

[dusty]

Op maandag 24 december 2001 00:02 schreef wilky het volgende:
op zich kun je dit gerust in één tabel mikken maar, wanneer bijvoorbeeld een eigenaar, die meerdere huizen bezit, verhuist moet er een adreswijziging doorgevoerd worden. als die woningeigenaar dan toevallig 50 woningen bezit om te verhuren, moeten al die 50 woningen voorzien worden van een nieuw eigenaarsadres... have fun!
dus:

Type 1 - Eigenaar
Type 2 - Huis

1,0,1
1,1,'dusty'
1,2,'Tweakerstraat 666'

5,0,2
5,1,'Huisdorp'
5,2,'40'
5,2,'dusty' <--- eigenaar die je weer indezelfde tabel kan opzoeken

dus hoef je slechts de eigenaar EEN keer te updaten.

Je hebt dus een slecht voorbeeld gekozen, omdat ik jouw probleem kan verhelpen door nog steeds gebruik te maken van mijn ene tabel.