Suggesties ivm. dbase layout

[Verwijderd]

Hoi

Ik heb namiddag wat zitten sleutelen aan een nieuwe dbase layout (enkel nog maar het clans, users en forums gedeelte), en dit is wat ik ervan terecht gebracht heb:



Graag zou ik nu weten wat jullie van deze layout vinden, en of jullie denken dat deze layout kans heeft op slagen

wat uitleg:
· rood: primary key / paars: index
· tabel clans: bevat alle clans. Het is natuurlijk de bedoeling dat hier zaken zoals clan_url, clan_irc, clan_.. ook in opgenomen worden.
· tabel users: bevat alle users. Het is natuurlijk de bdoeling dat hier zaken zoals user_mail, user_birthdate, ... ook in opgenomen worden.
· tabel forums: bevat de verschillende forums van clan. Het is de bedoeling dat de clans een ongelimiteerd aantal forums kunnen bijmaken/wissen/beheren.
· tabel forum_topics: bevat de topics van forum threads.
· tabel forum_threads: bevat de teksten/replies van de topics.
· tabel forum_topics_visits: bevat de datum wanneer een user (user_id) een bepaald topic (topic_id) bezocht heeft. Zo kan ik achterhalen of er updates zijn/of een gebruiker een topic reeds bezocht zijn.
· tabel forum_userrights: bevat de userrights die een gebruiker heeft op een bepaald forum. Userrechten worden opgebouwd volgens het "1 + 2 + 4 + 8" principe.
· tabel sessions: bevat de session_id's, die tevens staan in de cookie van een gebruiker. Zo hoeft een gebruiker niet altijd opnieuw in te loggen. Ik heb hiervoor een aparte tabel gemaakt (en dus niet in de tabel users een extra kolom aangemaakt), zodat het mogelijk is om zowel ingelogd te blijven op werk, als thuis, als...
· tabel sessions_data: tvv. van de session-files van php, zet ik dit nu allemaal in de dbase. Dit is (volgens mij) bijvoorbeeld makkelijker om oude sessies te wissen, en voor zaken zoals "who is online".

Wat vinden jullie van deze opzet?

Het enigste () waar ik problemen mee heb/zou kunnen hebben is het feit dat ik mijn forum opsplits in 'topics' en 'threads' en ik daardoor bijvoorbeeld via een aparte query de thread-topic/titel moet gaan halen, bij het bekijken van de replies op een thread.

Bedankt

[Verwijderd]

En de cardinaliteiten ?!

[NightBird]

thread == topic ?

[Verwijderd]

Op dinsdag 09 juli 2002 18:26 schreef Tizzwat het volgende:
En de cardinaliteiten ?!

Dat is nu even van minder belangrijk denk ik?

· Alle id's zijn INT, hoewel ik sommige zaken (zoals bijv. clan_id) op smallint ga zetten
· Session data is BLOB
· Namen/passworden/titels zijn VARCHAR met de gepaste lengte

[Verwijderd]

Op dinsdag 09 juli 2002 18:28 schreef NightBird het volgende:
thread == topic ?

thread = de TEKST velden, samen met de auteur + datum
topic = de TITEL velden

Ik heb het vooral zo gedaan omdat forums als phpbb en vbulletin het ook zo doen.. waarschijnlijk om die grote TEKST velden te vermijden bij het enkel afprinten van de topics.

offtopic: NB?! #r_b !

[Verwijderd]

ff wat opmerkingen :
- waar zijn de relaties? lijken me wel belangrijk
- entiteiten nooit meervoud namen geven >dus USER ipv USERS

voor de rest heb ik niet echt een goed idee wat je wilt modelleren en of het dus allemaal klopt. Lijkt erop dat je net zogoed een db structuur van een bestaande forum app kunt rippen (cq aanpassen)

[Verwijderd]

Op dinsdag 09 juli 2002 18:35 schreef vip32 het volgende:
ff wat opmerkingen :
- waar zijn de relaties? lijken me wel belangrijk

Die heb ik toch aangeduid met de kleurtjes? Akkoord ja, ik kon er pijltjes tussen zetten, maar het is toch in dit klein dbase-model duidelijk dat clan_id verwijst naar clan_id uit de tabel clans?

- entiteiten nooit meervoud namen geven >dus USER ipv USERS

ok!

voor de rest heb ik niet echt een goed idee wat je wilt modelleren en of het dus allemaal klopt. Lijkt erop dat je net zogoed een db structuur van een bestaande forum app kunt rippen (cq aanpassen)

Neen, want ik wil het zelf leren. Aan rippen heb ik echt niets aan.
Wat ik wil modelleren in dit geval: een forumsysteem bedoelde voor verschillende afzonderlijke clans, en waarbij clans zelf kunnen beheren, en elke user de nodige suerrechten kan 'krijgen'.

[Verwijderd]

Op dinsdag 09 juli 2002 18:39 schreef DiEana het volgende:

[..]

Die heb ik toch aangeduid met de kleurtjes? Akkoord ja, ik kon er pijltjes tussen zetten, maar het is toch in dit klein dbase-model duidelijk dat clan_id verwijst naar clan_id uit de tabel clans?
[..]



[..]

neenee, bij database modeleren horen relaties, PUNT
anders kan je netzogoed een tekst bestand tikken met alle velden en relaties, die visuele relaties voegen meer toe dan je denkt.

[Verwijderd]

Op dinsdag 09 juli 2002 18:43 schreef vip32 het volgende:

[..]

neenee, bij database modeleren horen relaties, PUNT
anders kan je netzogoed een tekst bestand tikken met alle velden en relaties, die visuele relaties voegen meer toe dan je denkt.

Dus jij vindt ze niet duidelijk in dit geval?

[Verwijderd]

Op dinsdag 09 juli 2002 18:47 schreef DiEana het volgende:

[..]

Dus jij vindt ze niet duidelijk in dit geval?

ik zie ze niet dus is het niet duidelijk nee. Maar goed, ik vindt dat het gewoon bij een database model hoort. Ben zelf gewend veel in UML te modeleren en het voordeel daarvan is dat er regels zijn hoe je iets modeleert. Bij db modelen heb je dat dus ook met die ER notatie wijze.

[Verwijderd]

Op dinsdag 09 juli 2002 18:50 schreef vip32 het volgende:

[..]

ik zie ze niet dus is het niet duidelijk nee. Maar goed, ik vindt dat het gewoon bij een database model hoort. Ben zelf gewend veel in UML te modeleren en het voordeel daarvan is dat er regels zijn hoe je iets modeleert. Bij db modelen heb je dat dus ook met die ER notatie wijze.

Akkoord.. maar vergeet niet dat ik nog nooit iets of wat geleerd heb van dbase modelleren/UML modellen/... Ik doe dit dus in mijne vrije tijd om wat bij te leren... gewoon omdat ik het graag doe

Maar je hebt gelijk hoor... er horen relaties bij.

Maar ik vond ze waarschijnlijk zo duidelijk, omdat ik er toch een tijdje aan gewerkt heb.

[Verwijderd]

Op dinsdag 09 juli 2002 19:03 schreef DiEana het volgende:

[..]

Akkoord.. maar vergeet niet dat ik nog nooit iets of wat geleerd heb van dbase modelleren/UML modellen/...

Maar je hebt gelijk hoor... er horen relaties bij.

Maar ik vond ze waarschijnlijk zo duidelijk, omdat ik er toch een tijdje aan gewerkt heb.

Daarom benadruk ik het hier ook zo....

psies, maar modeleren doe je niet alleen voor jezelf > je geeft het met dit topic al aan.
ennuh als je over een half jaar naar dit model terug kijkt is het wel makkelijk als het ook visueel spreekt.

[Killemov]

Het is goed dat er 1 keer in al die 1000 forum-db-layout topics een plaatje staat. Maar verder is dit echt weer een standaard DB-vraagstuk dus pak een boek, doe een cursus of ga naar school.

[Verwijderd]

ik zou een index zetten op topic_timestamp en thread_timestamp, omdat je daar op gaat sorteren

[pkouwer]

Op dinsdag 09 juli 2002 21:37 schreef Killemov het volgende:
Het is goed dat er 1 keer in al die 1000 forum-db-layout topics een plaatje staat. Maar verder is dit echt weer een standaard DB-vraagstuk dus pak een boek, doe een cursus of ga naar school.

vind ik niet, we zijn hier om elkaar te helpen, nietwaar ? Als iederen maar boeken moet gaan lezen of naar school moet, kan dit forum zijn poorten wel sluiten, immers alles is te leren.

[Verwijderd]

Op dinsdag 09 juli 2002 21:37 schreef Killemov het volgende:
Het is goed dat er 1 keer in al die 1000 forum-db-layout topics een plaatje staat. Maar verder is dit echt weer een standaard DB-vraagstuk dus pak een boek, doe een cursus of ga naar school.

Zoals ik al zei, ik doe dit in mijne vrije tijd.

En trouwens, ik heb een boek en ik lees het, maar wil dat zeggen dat ik het dan allemaal perfect kan? Zou leuk zijn, als iedereen door simpelweg naar school te gaan, of een boek te lezen, alles perfect kon.

De titel ken ik niet, maar het is een wit boek, en het is geschreven door Paul Dubois. (als iemand het kent)

Verder heb ik en anderen aan zulke reacties totaal niets.

Dus idd pkouwer.

[Verwijderd]

Op dinsdag 09 juli 2002 21:44 schreef deur het volgende:
ik zou een index zetten op topic_timestamp en thread_timestamp, omdat je daar op gaat sorteren

Ga ik dan niet te veel index'en hebben? Of schat ik dat verkeerd in?

En is het verder nog om in forum_topic (zonder s ) een kolom user_id te hebben? Want eigenlijk staat dat user_id ook in de tabel forum_thread.

Of zou ik gewoon beide tabellen samenvoegen, en werken met parentids? Of gaan de grote tekst-velden dan de query zwaar vertragen?

[Verwijderd]

Op dinsdag 09 juli 2002 22:13 schreef DiEana het volgende:

[..]

Zoals ik al zei, ik doe dit in mijne vrije tijd.

En trouwens, ik heb een boek en ik lees het, maar wil dat zeggen dat ik het dan allemaal perfect kan? Zou leuk zijn, als iedereen door simpelweg naar school te gaan, of een boek te lezen, alles perfect kon.

De titel ken ik niet, maar het is een wit boek, en het is geschreven door Paul Dubois. (als iemand het kent)

Verder heb ik en anderen aan zulke reacties totaal niets.

Dus idd pkouwer.

het beste boek geschreven door de opper guru (chris date)
http://www.amazon.com/exec/obidos/ASIN/0201385902/qid=1026292094/sr=8-1/ref=sr_8_1/002-3180789-5487251

[Verwijderd]

Op dinsdag 09 juli 2002 22:14 schreef DiEana het volgende:

[..]

Ga ik dan niet te veel index'en hebben? Of schat ik dat verkeerd in?

En is het verder nog om in forum_topic (zonder s ) een kolom user_id te hebben? Want eigenlijk staat dat user_id ook in de tabel forum_thread.

Of zou ik gewoon beide tabellen samenvoegen, en werken met parentids? Of gaan de grote tekst-velden dan de query zwaar vertragen?

Je kan nooit teveel indexen hebben

[Verwijderd]

Op woensdag 10 juli 2002 11:23 schreef CyruzB het volgende:

[..]

Je kan nooit teveel indexen hebben

Waarom staat in mijn boek dan "bij indices gaat het principe -hoe meer, hoe beter-, niet op" ? Beetje logisch eigenlijk: hoe meer indices, hoe meer index-lijsten aangepast moeten worden bij een INSERT?

Maar voor de rest geen aan- of opmerkingen? Dus ik heb het er goed van terecht gebracht?

[Verwijderd]

gut te gut, wat brak dit zeg.. je hebt bijvoorbeeld dit"

sessions:
session_id (kan je ook ID noemen)
user_id

en dan
session_data:
session_id,
session_data,
session_timestamp
userid

Waarom niet gewoon deze twee tabellen samen voegen ?? je doet echt ongeloofelijk moeilijk.. jezus..

doe het zo :

sessions:

session_id
user_id
session_data
session_timestamp

simpel, zelfde geld voor threads en topics, dat kan je ook samen voegen .. :R :R :R

[Verwijderd]

Op woensdag 10 juli 2002 12:25 schreef Stoel het volgende:
gut te gut, wat brak dit zeg.. je hebt bijvoorbeeld dit"

sessions:
session_id (kan je ook ID noemen)
user_id

en dan
session_data:
session_id,
session_data,
session_timestamp
userid

Waarom niet gewoon deze twee tabellen samen voegen ?? je doet echt ongeloofelijk moeilijk.. jezus..

doe het zo :

sessions:

session_id
user_id
session_data
session_timestamp

simpel, zelfde geld voor threads en topics, dat kan je ook samen voegen .. :R :R :R

Als je gelezen had wat ik zei, dan wist je dat sessions en session_data NIETS met elkaar te maken hebben.
--> sessions_data: sessie inhouden tvv. van files
--> sessions: om ingelogd te blijven

En hoezo kan ik threads en topics bij elkaar voegen? Werken met parent id's? Dan zit ik altijd wel met een lege topic bij replies?

offtopic: En als het je zo tegensteekt, reply dan liever niet.. als je nog niet de minste elementaire beleefdheid kan opbrengen, excuses in jou plaats dan. danku

[Dido]

Feit blijft dat je twee tabellen hebt waarbinnen ee record uniek gedefinieerd wordt door user_ID en session_ID, en er dus sprake is van een 1-op-1 relatie. Hoe je het ook draait, wendt of keert, maar je kunt dat of in 1 tabel kwijt, of het gaat niet om dezelfde informatie, in welk geval je het een andere naam moet geven.

Verder verwacht ik bij een tabel SESSION een enkelvoudige sleutel, namelijk Session_ID. Als die vervolgens gelinkt wordt met USER, krijg je iets als USER_SESSION, een n-m relatie in een koppeltabel.

Zet die relatielijntjes nou maar eens, dan zie je vanzelf waarom ze van belang zijn

Als je het goed doet zijn al je relaties 1-n!

[Verwijderd]

Op woensdag 10 juli 2002 11:53 schreef DiEana het volgende:

[..]

Waarom staat in mijn boek dan "bij indices gaat het principe -hoe meer, hoe beter-, niet op" ? Beetje logisch eigenlijk: hoe meer indices, hoe meer index-lijsten aangepast moeten worden bij een INSERT?

Maar voor de rest geen aan- of opmerkingen? Dus ik heb het er goed van terecht gebracht?

In zekere mate wel, maar op column's waar je van weet dat je in de toekomst op zal zoeken/sorteren is het altijd goed om indexen te hebben, gezien dit de opzoeksnelheid verhoogd.
En ik ga er van uit dat je meer selects dan inserts zult doen ?

Enfin, ik ben geen expert, maar ik heb net men eigen forum indexen aangepast en bij testen bleek dat het per query toch wel enkele tot 10 100ste van een seconde winst maakte.
Dat lijkt niet veel, maar als je zo 15 queries doet kan het wel een groot verschil gaan maken, zeker bij een hoge load van je site.

[Verwijderd]

Op woensdag 10 juli 2002 14:30 schreef Dido het volgende:
Feit blijft dat je twee tabellen hebt waarbinnen ee record uniek gedefinieerd wordt door user_ID en session_ID, en er dus sprake is van een 1-op-1 relatie. Hoe je het ook draait, wendt of keert, maar je kunt dat of in 1 tabel kwijt, of het gaat niet om dezelfde informatie, in welk geval je het een andere naam moet geven.

Verder verwacht ik bij een tabel SESSION een enkelvoudige sleutel, namelijk Session_ID. Als die vervolgens gelinkt wordt met USER, krijg je iets als USER_SESSION, een n-m relatie in een koppeltabel.

Zet die relatielijntjes nou maar eens, dan zie je vanzelf waarom ze van belang zijn

Als je het goed doet zijn al je relaties 1-n!

De verwarring komt door het feit dat ik deze tabellen "foute" benamingen gegeven had.

De tabel sessions dient om session_id's in op te slaan, die ik handmatig (ahv. gepaste functie) genereer en die ook opgeslaan worden in een cookie. Op deze manier kan ik snel controleren of session_id cookie = session_id tabel, en zo hoeft de gebruiker niet telkens opnieuw in te loggen. Nu kon ik natuurlijk evengoed een extra kolom 'session_id' aanmaken in de tabel users, maar dit gaf 1 probleem: mensen met verschillende pc's. Zo kan je bijvoorbeeld niet ingelogd blijven EN op het werk EN bij je thuis, omdat deze 2 verschillende session_id's hebben.

De tabel sessions_data dient voor data op te slaan tijdens een bezoek, zaken zoals: prefered_highlight_color, user_id, user_mail, ...

Waarom dit volgens mij niet in 1 tabel kan?
-> Zoals ik al zei, sessions kan meedere rijen bevatten voor 1 user (=het aantal pc's van de gebruiker). sessions_data bevat echter een 'ontelbaar' aantal rijen van een gebruiker.

Of zie ik het mis?

--

Waar ik nog 'problemen' mee heb, is het feit dat ik zaken zoals user_id, topic_replies en topic_timestamp heb opgenomen in mijn forum_topic table. Echter kan ik al deze informatie ook uit de threads halen, namelijk:
-> user_id: de auteur van de eerste post (met mysql functies als MIN, LIMIT moet dat te doen zijn?)
-> replies: count(..)
-> topic_timestamp: datum van de laatste post (MAX)

Is het de moeite dat ik een "kopie" maak van deze gegevens, om zo snellere queries te kunnen maken? Want de SELECT querie zal misschien sneller zijn, maar bij een insert van een reply moet ik ook gegevens in de tabel forum_topics (replies verhogen, datum aanpassen) gaan zetten. Dat geeft in dit geval dus een extra querie?

--

En nog iets: sommige mensen zeggen dat ik topics en threads als 1 tabel moet samen voegen, en gebruik te maken van parentID's. Maar wat doe ik dan met toekomstige kolommen als 'forum_isSticky', 'forum_status', 'forum_isDeleted', 'topic_title' in mijn forum_topic table? Want dat is informatie die alleen opgaat voor de topics, niet voor de replies/threads. Ik kan toch moeilijk bij alle replies default waarden als O/NULL hanteren? Dat levert toch een enorme inconsistente database op en is moeilijker voor search functies?

[Verwijderd]

Op woensdag 10 juli 2002 16:04 schreef CyruzB het volgende:

[..]

In zekere mate wel, maar op column's waar je van weet dat je in de toekomst op zal zoeken/sorteren is het altijd goed om indexen te hebben, gezien dit de opzoeksnelheid verhoogd.
En ik ga er van uit dat je meer selects dan inserts zult doen ?

Enfin, ik ben geen expert, maar ik heb net men eigen forum indexen aangepast en bij testen bleek dat het per query toch wel enkele tot 10 100ste van een seconde winst maakte.
Dat lijkt niet veel, maar als je zo 15 queries doet kan het wel een groot verschil gaan maken, zeker bij een hoge load van je site.

Je kan gelijk hebben, en ik zal het alleen maar te weten komen door testen denk ik, net zoals jij gedaan hebt

Maar zelf dacht ik gelezen te hebben dat indices op datums ongebruikelijk is... ik kan me natuurlijk vergissen.

[Nielsz]

reageer jij altijd op jezelf

[Verwijderd]

Op woensdag 10 juli 2002 16:14 schreef Nielsz het volgende:
reageer jij altijd op jezelf

Het was de bedoeling dat ik mijn "tweede" reply achter mijn eerste reply ging plakken.. heb het een beetje opgefuckt (drukt op reply ipv. op edit)

Het is in orde nu, phew

[Verwijderd]

Ik ben er nog altijd niet uit hoor!