[MySQL] Tabel met alleen een ID veld

[Verwijderd]

Wat is volgens de regels van het database ontwerpen het beste?

Situatie 1:
[reactie]
ID
threadID
userID
tekst
etc

[thread]
ID

of situatie 2:
[reactie]
ID
threadID
userID
tekst
etc

Het komt er dus op neer dat threadID een autonummeringsveld is. Dit kan ik handmatig in php doen door SELECT max(threadID)+1 of door mysql een extra tabel te laten gebruiken met een autonummeringsveld. Van de tweede tabel hoeft dus verder geen info bijgehouden te worden. De threadID kan meerdere keren voorkomen uiteraard. Wat is de netste oplossing?

[rickmans]

Je kan het via een autoincrement doen .

PHP:

CREATE TABLE test (
id SMALLINT( 5 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
test VARCHAR( 255 ) NOT NULL ,
PRIMARY KEY ( id )
);

[Wolfboy]

rickmans schreef op dinsdag 25 januari 2005 @ 21:55:
Je kan het via een autoincrement doen .

Nee dat kan niet.
Een autoincrement veld MOET een primary key zijn en een primary key MOET uniek zijn.
Aangezien de TS zegt dat het veld meerdere keren kan voorkomen is dat dus geen oplossing

[Verwijderd]

Dat begrijp ik uiteraard . Ik zal het es wat duidelijker proberen uit te leggen. Het gaat om een reactie systeem. De reacties behoren tot een 'thread'. Een thread kan bij nieuwtjes, of artikelen horen (of andere secties). In de nieuwtjes tabel staat dan een verwijzing naar threadID. Bij een thread horen meerdere reacties uiteraard. Op een forum zou je een aparte tabel 'thread' hebben met een ID, onderwerp, slotje etc. Maar dat heb ik allemaal niet nodig. Ik wil alleen een ID bijhouden. Dit kan dus ook gewoon in de posts tabel dan. Dan moet het alleen via scripts bijgehouden worden. Dat is op zich geen probleem maar ik denk wat minder netjes. Bij de eerste methode heb je alleen een tabel met maar 1 veld: een ID. Dus wat is netter?

[TheDane]

Wat wil TS eigenlijk ?

voor iedere reactie een thread maken

ff lezen en niet tegelijkertijd posten

Als een thread bij een nieuwtje, poll of article hoort, kun je dan niet het ID van die items als threadID gebruiken?

heb je in ieder geval al een mooie integratie

[ Voor 74% gewijzigd door TheDane op 25-01-2005 22:03 ]

[rickmans]

ah verkeerd / te snelgelezen dus *schaam*

Als ik ervan uitgaat dat het een soort van reactiesysteem is. Zou ik persoonlijk kiezen voor een aparte table waarin de threads bijgehouden zouden worden (met dan een autoincrement en primary op thread id) en vervolgens een aparte table met daarin de koppeling tussen reacties en threads. Wellicht als ik nog iets neurotischer bezig ben zouden reactie en threads bij mij twee aparte tables zijn en dan nog een derde table die beiden koppelt (alhoewel dat ook als overbodig beschouwt kan worden aangezien er ook een koppeling plaats kan vinden op reactie level).

[Verwijderd]

TheDane schreef op dinsdag 25 januari 2005 @ 22:00:
Wat wil TS eigenlijk ?

voor iedere reactie een thread maken

ff lezen en niet tegelijkertijd posten

Als een thread bij een nieuwtje, poll of article hoort, kun je dan niet het ID van die items als threadID gebruiken?

heb je in ieder geval al een mooie integratie

Een nieuwtje kan hetzelfde ID nummer hebben als een artikel he

ah verkeerd / te snelgelezen dus *schaam*

Als ik ervan uitgaat dat het een soort van reactiesysteem is. Zou ik persoonlijk kiezen voor een aparte table waarin de threads bijgehouden zouden worden (met dan een autoincrement en primary op thread id) en vervolgens een aparte table met daarin de koppeling tussen reacties en threads. Wellicht als ik nog iets neurotischer bezig ben zouden reactie en threads bij mij twee aparte tables zijn en dan nog een derde table die beiden koppelt (alhoewel dat ook als overbodig beschouwt kan worden aangezien er ook een koppeling plaats kan vinden op reactie level).

Ik was blijkbaar ook niet helemaal duidelijk . Maar een derde tabel is overbodig aangezien een reactie maar tot 1 thread kan behoren. En 2 tabellen is dus ook de oplossing die ik zelf noem. Dat er dan een tabel thread ontstaat met alleen 'ID' als veld is blijkbaar geen probleem?

[TheDane]

Verwijderd schreef op dinsdag 25 januari 2005 @ 22:07:
[...]


Een nieuwtje kan hetzelfde ID nummer hebben als een artikel he


[...]

Ik was blijkbaar ook niet helemaal duidelijk . Maar een derde tabel is overbodig aangezien een reactie maar tot 1 thread kan behoren. En 2 tabellen is dus ook de oplossing die ik zelf noem. Dat er dan een tabel thread ontstaat met alleen 'ID' als veld is blijkbaar geen probleem?

In mijn systeem zouden ze een sequence delen, zoveel verschillende de types 'artikel' en 'nieuwsitem' niet, maargoed

ontopic: een table met maar 1 veld is technisch gezien zeker geen probleem. en 't houdt de mogelijkheid ook nog eens open om toch je model t.a.v. 'threads' uit te breiden. mocht je in de toekomst iets als 'date_creation' of thread-based permissions leuk vinden

[Verwijderd]

TheDane schreef op dinsdag 25 januari 2005 @ 22:15:
[...]


In mijn systeem zouden ze een sequence delen, zoveel verschillende de types 'artikel' en 'nieuwsitem' niet, maargoed

Maar een poll wordt weer wel heel anders, en zo zijn er meer secties .

ontopic: een table met maar 1 veld is technisch gezien zeker geen probleem. en 't houdt de mogelijkheid ook nog eens open om toch je model t.a.v. 'threads' uit te breiden. mocht je in de toekomst iets als 'date_creation' of thread-based permissions leuk vinden

Ok, doe ik dat toch maar . Thanx allen

[Not Pingu]

Verwijderd schreef op dinsdag 25 januari 2005 @ 21:59:
De reacties behoren tot een 'thread'. Een thread kan bij nieuwtjes, of artikelen horen (of andere secties).

Je wilt dus gewoon een koppeltabel die reacties aan een item (nieuwtje, artikel, whatever) koppelt?
Ik maak even een aanname: threads krijgen dus een uniek ID dat dan aan het item gekoppeld wordt? En een thread kan maar aan 1 item hangen? Dan krijg je dus zoiets:

[item]
ID (autonummering, PK)
Titel (tekxt)
Tekst (fulltext/memo)

[thread]
ID (autonummering, PK)
ItemID (numeriek, FK->[item].ID)

[reactie]
ID (autonummering, PK)
ThreadID (numeriek, FK ->[thread].ID)
Poster (tekst)
Reactie (tekst)

PK=Primary Key
FK=Foreign Key (is niet perse nodig, wel sneller)

Is elk item (nieuwsbericht, artikel) van hetzelfde soort? Dwz. worden ze in dezelfde tabel opgeslagen? Of heb je aparte tabellen voor nieuws, artikelen, etc.? Dan zou je het ThreadID in die tabel moeten opslaan ipv. het ItemID in de Thread tabel.

[Verwijderd]

De secties behoren in verschillende tabellen idd en de threadID's worden als foreign keys in die tabellen opgeslagen. Zo krijg je dus nog maar 1 veld in de thread ID. Ik vroeg me af of dat wel netjes was. Dat was eigenlijk de enige vraag.

[mOrPhie]

Persoonlijk zou ik nieuwtjes en artikelen (en anderen) als éénduidig behandelen. Ik zou dat onderbrengen in een tabel met de naam "onderwerp" bijvoorbeeld. Een type-veld zou aangeven om wat voor soort onderwerp het gaat (een nieuwtje, een artikel). Op die manier heb je maar 1 unieke ID om rekening mee te houden. Vervolgens kunnen reacties aan die unieke ID gehangen worden.

Want wat is databasetechnisch gezien nou echt het verschil tussen een nieuwtje en een artikel? Volgens mij reteweinig.

[Verwijderd]

Zoals ik al eerder zei, een poll, een clanpagina, een cupsysteem waarbij op matches gereageerd kan worden etc. Er komt nog meer bij kijken en eigenlijk probeer ik er een herbruikbaar (OOP) systeem van te maken .

[TheDane]

Verwijderd schreef op dinsdag 25 januari 2005 @ 22:31:
Zoals ik al eerder zei, een poll, een clanpagina, een cupsysteem waarbij op matches gereageerd kan worden etc. Er komt nog meer bij kijken en eigenlijk probeer ik er een herbruikbaar (OOP) systeem van te maken .

Al die dingen hebben bepaalde eigenschappen gemeenschappelijk. denk aan een datum van creatie, een eigenaar, een title etc etc.

Da's 't mooie van inheritance, en een van de leuke dingen die je in een OOP model -als je er toch zelf over begint- mooi kan maken.

[Verwijderd]

Ok dat is waar. Maar alleen m'n PHP wordt OOP . Om in MySQL inheritance te gaan gebruiken vind ik nog wat te ver gaan. Misschien iets voor de toekomst.

[mOrPhie]

Inheritence in een database is niets meer dan normaliseren. Iets wat jij al doet door de thread buiten de reactie te zetten (zoiets in de buurt van jouw situatie-1). Dat is dus niet iets nieuws of exotisch. Het enige is: je moet daar een reden voor hebben. Gemeenschappelijke attributen is een hele goede reden om te gaan normaliseren en zal in je PHP-code inheritance tot gevolg (kunnen) hebben. En aangezien een onderwerp (of dit nou een poll of een artikel is) zeker weten gemeenschappelijke attributen kent, zal je dat dus als zodanig kunnen normaliseren. Dat heeft 2 voordelen: Je database is in zekere zin genormaliseerd en je hebt een unieke ID waar je een reactie aan kunt koppelen.

Als je een object georienteerde aanpak wilt, zullen je code én je database afhankelijk zijn van jouw gekozen informatiemodel (klassendiagram).