[Database] Opzet voor Forum

[dawuss]

Ik heb net wat zitten denken over de opzet van de databases voor het forum dat ik aan het maken ben. Uiteindelijk kwam ik op het volgende model:



Het plaatje spreekt denk ik redelijk voor zich. De User tabel staat niet in z'n volledigheid in het plaatje, daar komen nog amin-levels etc bij, maar dan werd het plaatje onnodig groot.

offtopic:
Ja, het is gemaakt in MS Word, vandaar die hoofdletters

Wat vinden jullie hier van? Moet ik dingen nog anders aanpakken?

edit: Oké chem, speciaal voor jou aangepast met wat transparency

[ Voor 10% gewijzigd door dawuss op 25-02-2003 17:05 . Reden: mooier plaatje ]

[chem]

ik vind het erg wit!

[Verwijderd]

Het eerste wat ik op te merken heb is dat ik 'categorie_id' of iets dergelijks zou gebruiken ipv 'cat'. Op dezelfde manier 'InTopic'. Hiervoor zou ik topic_id oid gebruiken. Dat is wat duidelijker en algemener gebruikt.
(bij posterid doe je al wel iets dergelijks).
Ook hoop ik voor je dat 'topicstarter' een user-id is en niet de nick.

Verder zou ik zou date/time samenvoegen in 1 kolom (in Topics en 2 keer in Posts).

En kun je wat meer uitleggen over je Permissions?
Ik snap niet helemaal hoe je dit wilt gaan gebruiken.

Oh, en over je plaatje op zich: kun je users en permissions niet omdraaien? Dan krijg je ook niet zo'n rare kruising.

Als laatste wil ik nog zeggen dat dit wel wat karig is, maar voor een basic forum is het voldoende kan het voldoende zijn. Je zult het waarschijnlijk later wel uit gaan bouwen.

[ Voor 81% gewijzigd door Verwijderd op 25-02-2003 16:42 ]

[dawuss]

Verwijderd schreef op 25 February 2003 @ 16:36:
Ook hoop ik voor je dat 'topicstarter' een user-id is.

Ja, met die pijl bedoel ik dat hier dezelfde waarde staat, zodat deze gekoppeld kan worden aan de 'user' tabel.

En kun je wat meer uitleggen over je Permissions?
Ik snap niet helemaal hoe je dit wilt gaan gebruiken.

Het 'user_id' verwijst naar de betreffende user, waar deze permission-rule voor geldt, het 'realm' is een id dat verwijst naar het gedeelte van de site, dus bijvoorbeeld een crewforum, wat een categorie-id heeft.
De Access waarde tenslotte, geeft aan of de user er lees-rechten, post rechten, mod rechten etc heeft, door een macht van 2.
Over deze tabel ben ik nog niet helemaal zeker, misschien dat ik de individuele rechten nog opsplits.

In Posts: Ik zou date/time samenvoegen in 1 kolom

Hoe doe ik dat makkelijk? En hoe trek ik deze waarden later weer uitelkaar? Kan ik daar ook op sorteren?


Het forum wordt inderdaad heel erg basic. Ik doe (nog) geen IT-gerichte opleiding (laatste jaar VWO) en ik wil hier wat ervaring mee opdoen. (en het is natuurlijk leuk )

[Verwijderd]

dawuss schreef op 25 February 2003 @ 16:47:
Ja, met die pijl bedoel ik dat hier dezelfde waarde staat, zodat deze gekoppeld kan worden aan de 'user' tabel.

Ik bedoel 'topicstarter' in Topics.
Die zie ik niet gelinkt staan en het is me ook niet duidelijk dat dat een id is.
Dit bedoelde ik ook met het eerste stuk van mijn post. Als je die 'user_id' oid genoemd had, dan was 't meteen duidelijk geweest.
Maar zoiets is niet verplicht, uiteraard.

Het 'user_id' verwijst naar de betreffende user, waar deze permission-rule voor geldt, het 'realm' is een id dat verwijst naar het gedeelte van de site, dus bijvoorbeeld een crewforum, wat een categorie-id heeft.
De Access waarde tenslotte, geeft aan of de user er lees-rechten, post rechten, mod rechten etc heeft, door een macht van 2.
Over deze tabel ben ik nog niet helemaal zeker, misschien dat ik de individuele rechten nog opsplits.

Met het oog op eventuele uitbreidingen is dit niet echt heel handig.
Ook moet je nu elke user apart recht toewijzen.
Maar ok, voor een basicforum kan het wel.
Ik zou dat wel als een van de eerste 'verbeterpunten' aanmerken.

Hoe doe ik dat makkelijk? En hoe trek ik deze waarden later weer uitelkaar? Kan ik daar ook op sorteren?

Ja hoor, als je bijv een timestamp gebruikt, daar zitten de seconden al in.
In elk zelfrespecterend dbms zit wel de mogelijkheid een datetime veld te gebruiken. Notatie, naam en vorm moet je even bij de docs bekijken.
Welk dbms ga je eigenlijk gebruiken (en welke taal)?

Het forum wordt inderdaad heel erg basic. Ik doe (nog) geen IT-gerichte opleiding (laatste jaar VWO) en ik wil hier wat ervaring mee opdoen. (en het is natuurlijk leuk )

Ja, leuk is het zeker.
Van een forum maken leer je heel veel.
Maar ik vind dat je aardig eind op weg bent.

btw: Ik heb mijn eerste post in de tussentijd ook weer wat bijgewerkt, dat kun je misschien ook nog gebruiken.

[ Voor 9% gewijzigd door Verwijderd op 25-02-2003 16:56 ]

[dawuss]

Verwijderd schreef op 25 February 2003 @ 16:54:
[...]

Ik bedoel 'topicstarter' in Topics.
Die zie ik niet gelinkt staan en het is me ook niet duidelijk dat dat een id is.
Dit bedoelde ik ook met het eerste stuk van mijn post. Als je die 'user_id' oid genoemd had, dan was 't meteen duidelijk geweest.
Maar zoiets is niet verplicht, uiteraard.

Och Vergeten een pijl te zetten. Dat was inderdaad wel de bedoeling ja

Met het oog op eventuele uitbreidingen is dit niet echt heel handig.
Ook moet je nu elke user apart recht toewijzen.
Maar ok, voor een basicforum kan het wel.
Ik zou dat wel als een van de eerste 'verbeterpunten' aanmerken.

Kun je misschien een beter alternatief geven?

Ja hoor, als je bijv een timestamp gebruikt, daar zitten de seconden al in.
In elk zelfrespecterend dbms zit wel de mogelijkheid een datetime veld te gebruiken. Notatie, naam en vorm moet je even bij de docs bekijken.
Welk dbms ga je eigenlijk gebruiken?

MySQL, zoals bijna iedere beginner
Maar hoe krijg ik zo'n timestamp terug naar "bericht gepost om 17:01 op 25-2-2003"?

[ Voor 6% gewijzigd door dawuss op 25-02-2003 17:00 . Reden: quote tags gefixt ]

[dawuss]

Verwijderd schreef op 25 February 2003 @ 16:36:
Oh, en over je plaatje op zich: kun je users en permissions niet omdraaien? Dan krijg je ook niet zo'n rare kruising.

Ja, dat was inderdaad wel beter geweest. Ik heb het gewoon in de volgorde gezet hoe ik de tabellen gemaakt heb, en later kwamen die pijlen dus in de knoop. Had geen zin meer om dat te wijzigen

[LeonT]

dawuss schreef op 25 February 2003 @ 16:58:

MySQL, zoals bijna iedere beginner
Maar hoe krijg ik zo'n timestamp terug naar "bericht gepost om 17:01 op 25-2-2003"?

http://www.mysql.com/doc/en/DATETIME.html
http://www.mysql.com/doc/en/Date_and_time_functions.html
met DATE_FORMAT

[ Voor 14% gewijzigd door LeonT op 25-02-2003 17:06 ]

[EfBe]

Je bent 'forum' vergeten

Verder zou ik 'roles' introduceren. Per role-forum combinatie kun je dan rights definieren voor die role, plus je hebt een setje system rights die je direct per role definieert. Users plaats je dan in de roles, en die erven dan dus de rights per forum en de system rights van de role(s) waar ze in zitten.

Je bent ook de posting history vergeten, dwz, dat je de wijzigingen van een posting opslaat in een aparte table, zodat je t.a.t. vanaf het begin totaan de huidige versie de wijzigingen kunt volgen en kunt zien wie dat gedaan hebben.

Topicstarter in je topics table is een FK naar Id in de usertable. Je postings zou ik zowel in text zoals ze zijn ingetikt opslaan als ook in bv HTML of als je meerdere formats wilt ondersteunen, per format in een aparte tabel. Zodoende kun je bij retrieval van de postings door de viewer (die aangeroepen wordt door de bezoeker) meteen HTML vanuit de database naar de browser streamen zonder post-processing.

hier een snapshot van een model, niet alle relaties zijn aangegeven, want Enterprise Manager vindt dat op een of andere manier niet nodig.

[ Voor 11% gewijzigd door EfBe op 25-02-2003 17:13 ]

[Verwijderd]

Zie ik dat goed, permissions en userid wordt lekker vol als je 5000 users hebt en maar 4 soorten permissies. Ik zou er dan groupid van maken en bij iedere user een groupid. Zo bespaar je een hele hoop rijen lijkt me zo

[dawuss]

EfBe schreef op 25 februari 2003 @ 17:06:
Je bent 'forum' vergeten

volgens mij heet dat bij mij 'categories' als dat is wat je bedoelt.

Verder zou ik 'roles' introduceren. Per role-forum combinatie kun je dan rights definieren voor die role, plus je hebt een setje system rights die je direct per role definieert. Users plaats je dan in de roles, en die erven dan dus de rights per forum en de system rights van de role(s) waar ze in zitten.

Bedoel je hiermee een soort van rights-presets? Dus je bent 'moderator' + je hebt rechten om topics te trashen o.i.d?

Je bent ook de posting history vergeten, dwz, dat je de wijzigingen van een posting opslaat in een aparte table, zodat je t.a.t. vanaf het begin totaan de huidige versie de wijzigingen kunt volgen en kunt zien wie dat gedaan hebben.

Dat vond ik nog wat moeilijk om mee te beginnen. Ik wist niet hoe ik dat moest maken. (dmv LastModDate kon ik wel edits bijhouden)

Topicstarter in je topics table is een FK naar Id in de usertable.

Wat is een FK?

Je postings zou ik zowel in text zoals ze zijn ingetikt opslaan als ook in bv HTML of als je meerdere formats wilt ondersteunen, per format in een aparte tabel. Zodoende kun je bij retrieval van de postings door de viewer (die aangeroepen wordt door de bezoeker) meteen HTML vanuit de database naar de browser streamen zonder post-processing.

Ik wilde eigenlijk de input uit de database door htmlspecialchars() en addslashes() heen halen, en daarna parsen met preg_replace(). Dit om beveiligingslekken te voorkomen, dus dat mensen javascript in de database kunnen gooien o.i.d.

edit:
Dat plaatje van je ziet er erg strak uit, maar zo ambitieus durf ik niet te zijn
Ik ben maar een beginner op dit gebied (n00b vind ik zo'n lelijk woord, dus dat gebruik ik al expres niet )

[ Voor 8% gewijzigd door dawuss op 25-02-2003 17:18 ]

[dawuss]

Verwijderd schreef op 25 February 2003 @ 17:12:
Zie ik dat goed, permissions en userid wordt lekker vol als je 5000 users hebt en maar 4 soorten permissies. Ik zou er dan groupid van maken en bij iedere user een groupid. Zo bespaar je een hele hoop rijen lijkt me zo

idd. Dat moest ik maar eens doen ja
Overigens krijgt het forum maar rond de 100 users het is meer voor educatieve doeleinden, dus zeg aub niet dat ik dan maar phpbb moet gebruiken

[ Voor 11% gewijzigd door dawuss op 25-02-2003 17:16 ]

[EfBe]

dawuss: dat plaatje is toch niet zo heel moeilijk? Het is wat uitgebreider, maar ook weer niet al te uitgebreid (je kunt nl. nog wel veel meer verzinnen ). Het enige wat je moet doen is veel insert/select/delete/update routines maken, en als je database dat ondersteunt, triggers (voor de message counts e.d.)

[Olaf van der Spek]

dawuss schreef op 25 februari 2003 @ 17:14:
Wat is een FK?

Een Foreign Key

Ik wilde eigenlijk de input uit de database door htmlspecialchars() en addslashes() heen halen, en daarna parsen met preg_replace(). Dit om beveiligingslekken te voorkomen, dus dat mensen javascript in de database kunnen gooien o.i.d.

Dat kun je toch doen voordat je het insert in de DB?
edit:

[dawuss]

OlafvdSpek schreef op 25 February 2003 @ 17:47:
Dat kun je toch doen voordat je het insert in de DB?

dat is waar
maar volgens mij is het makkelijker om gewoon alle HTML code pas te genereren bij het parsen van de UBB tags uit de database.

URL's kunnen dus gewoon opgeslagen worden als [url=blabla]text[/url] en <a href="blabla">text</a>wordt gewoon als zodanig weergegeven, en nooit als link.

[ Voor 46% gewijzigd door dawuss op 25-02-2003 18:03 ]

[EfBe]

dawuss schreef op 25 februari 2003 @ 18:01:
[...]
dat is waar
maar volgens mij is het makkelijker om gewoon alle HTML code pas te genereren bij het parsen van de UBB tags uit de database.

err, dat zou ik niet doen . Bij het saven van het bericht parse je de UBB tags naar je format, bv XML, en haalt dan een template eroverheen om HTML te genereren. Die HTML zet je in de database. Anders wordt je forum nogal erm... traag

[Verwijderd]

Ik denk dat de TS nu aantal leuke handvaten heeft om verder te bouwen.
Als je net begint met een forum is het imo niet handig om heel meteen heel uitgebreid te maken.

Maar om nog even op EfBe's post te reageren:
Het is inderdaad niet verstandig om on-the-fly al je html te gaan genereren en je ubb in de db op te slaan, hoewel ik dat ook gedaan heb bij de eerste versie van mijn forum
Je komt daar snel genoeg achter en voor een pruts/hobby/leer projectje is het niet erg.
Als het publiek komt heb je vooral te maken met user-input controle ed.
Of het langzaam is, tja, dat kun je weer aanpassen.
Desondanks wel handiger om het meteen goed te doen natuurlijk.

dawuss, de antwoorden op de vragen die je mij stelde zijn hierboven al door anderen gegeven. Succes verder en post je ervaringen

[djluc]

Het nadeel van het parsen van de ubb codes als je het in de db gaat zetten is natuurlijk wel dat je ten eerste eigenlijk de 'regels' ( ja ze staan tussen aanhalingstekens!) overtreed omdat je opmaakkenmerken (HTML) in je db zet. Verder moet je als je de layout van je site gaat veranderen in je database de HTML info aan gaan passen om in de nieuwe lay-out te passen terwijl je dit eigenlijk ergens in je code, of nog liever in je template had moeten doen.

Wat je wel zou kunnen doen is bijvoorbeeld codes als

code:

<div class="quote">de tekst die tussen ubb codes stond</div>

Dan kun je alsnog via 1 css commando de opmaak wijzigen.

[Verwijderd]

Ja, of je slaat ze gewoon allebei op.
En stel dat je meerdere varianten hebt (html, xml, wml, vxml, etc) daar een aparte tabel voor maken.
Dus de source in je post-tabel en voor elke output-variant een aparte tabel met de geparste meuk.
Bij een nieuwe lay-out moet je dan alleen de nieuwe output genereren en opslaan.
Het kost wel wat extra opslag (het dubbele bij 1 output-soort), maar het is wel veel handiger.

/me kan zich overigens geen forum herinneren met een vxml-output
Daarom geldt dit ook niet alleen voor een forum, maar voor allerlei toepassingen.

[EfBe]

djluc: ooit van html stylesheets gehoord? Toegegeven, als je echt radicale html changes toe wilt passen dan heb je een probleem, maar dat kun je ondervangen door je geparste data op te slaan in het tussenformat dat je gebruikt, bv XML. Mijn UBB+ parser (LR(1) parser ) parst alles naar een XML tree en die zou ik dus ipv de HTML op kunnen slaan, en on the fly die XML middels de actuele XSL template converteren naar HTML, en dat eventueel cachen in de webserver.

[Verwijderd]

EfBe schreef op 25 February 2003 @ 17:06:
Een mooie ERD

Toch zou ik aanraden om primaire sleutels over meer dan een veld te vermijden. Er zijn eigelijk ook maar heel weinig situaties te bedenken waar het echt noodzakelijk is. Het getuigd negen van de tein keer van een slecht ontwerp. Ik zou het overigens graag proberen aan te passen,maar daar nu geen tijd en zin in

[djluc]

[quote]EfBe schreef op 25 February 2003 @ 20:41:
djluc: ooit van html stylesheets gehoord? :)[quote]Wat bedoel je daar precies mee, stylesheets in css werken volgens mij goed, in HTML zou ik niet weten hoe je centraal kunt aangeven dat een quote bijvoorbeeld in een andere lettergrootte moet oid.

Toegegeven, als je echt radicale html changes toe wilt passen dan heb je een probleem, maar dat kun je ondervangen door je geparste data op te slaan in het tussenformat dat je gebruikt, bv XML.

Ik heb ook gezegd dat dat divje alleen een van de mogelijkheden was, natuurlijk zijn er nog veel meer mogelijkheden, het ging me meer om het principe.

Mijn UBB+ parser (LR(1) parser ) parst alles naar een XML tree en die zou ik dus ipv de HTML op kunnen slaan, en on the fly die XML middels de actuele XSL template converteren naar HTML, en dat eventueel cachen in de webserver.

Dat is inderdaad een goed mogelijke manier net als zovele anderen, waar mijn post vooral over ging was dat je alleen de data op moet slaan, eventueel aangegeven met wat het voor soort data is bijvoorbeeld een quote, maar dat je dus niet moet gaan toekennen tussen de gegevens hoe de gegevens er uit moeten komen te zien.

[tomato]

Verwijderd schreef op 25 February 2003 @ 21:11:
Toch zou ik aanraden om primaire sleutels over meer dan een veld te vermijden. Er zijn eigelijk ook maar heel weinig situaties te bedenken waar het echt noodzakelijk is. Het getuigd negen van de tein keer van een slecht ontwerp. Ik zou het overigens graag proberen aan te passen,maar daar nu geen tijd en zin in

Hoezo dat
Samengestelde primaire sleutels komen toch wel vrij veel voor en zijn volgens mij helemaal niet controversieel.

Als je alleen al naar koppeltabellen kijkt, komt dat in 80% of meer van de gevallen neer op een samengestelde PK.

Ik eigenlijk ook niet goed bedenken waarom je het gebruik ervan zou willen afraden.... verklaar je nader

[slm]

- forum desc + lastpostdate (scheelt weer een diepere query) en evt een lastpostbyid
- bij users: sign up ip adres en evt. lastused ip adres
- bij posts: ip adres van user (hiermee kan je claims voorkomen á la: "was ik niet, mijn account was gehacked" bla bla bla)
- date en time kunnen erg makkelijk in 1 veld (datetime)
- evt usernames naast userid's bij posts en threads zetten (scheelt vaak een join. nadeel is wel bij nickchanges dat je evt. een update query erdoor moet halen)
- een replies count veld bij threads (scheelt een extra query)
- erg belangrijk: een closed veldje!!
- weergeven=ja/nee veld zodat de echte delete transacties later uitgevoerd kunnen worden

Dat 2e veldje berichtalshtml vind ik heel interessant, was ik zelf nog niet opgekomen en ga eens uitzoeken hoeveel dit in tijd/serverload bespaart aangezien het de data zeker zal verdubbelen.

[Nielsz]

EfBe: leuke IPban table heb je waarom in godsnaam?
Daar had ik laatst wel een leuk ding voor gemaakt (prive, ik zou het niet in het echt los durven laten, erg ranzig )

Table bans:
id (autoincrement)
type
value
active
reason
ttl


Waar type een enum is:
0 = ipban
1 = userban
2 = groepban
3 = allban


En dan een query:
select reason,ttl from bans where (type=0 and value = "192.168.0.1") or (type=1 and value="1") or (type=2 and value="2") or (type=3 and value!=NULL) and active=1

Er ranzig, maar zo had je in een query een banscript en maintenance en pushmessages script enzo

[dusty]

Verwijderd schreef op 25 February 2003 @ 21:11:
[...]

Toch zou ik aanraden om primaire sleutels over meer dan een veld te vermijden. Er zijn eigelijk ook maar heel weinig situaties te bedenken waar het echt noodzakelijk is. Het getuigd negen van de tein keer van een slecht ontwerp. Ik zou het overigens graag proberen aan te passen,maar daar nu geen tijd en zin in

Ik zou het zelfs anders durven te stellen.

In een datamodel waar geen tabel bestaat met een primary key die bestaat uit een samengestelde tabel is of een heel klein simpel systeempje of getuigd juist dat het een slecht ontwerp is, en dat de ontwerper niet echt verstand heeft van datamodellen en het idee achter een database.

Vaak gaan de mensen dan ook een "nieuwe" unieke sleutel toevoegen voor juist alleen dat tabel, die niet wordt gebruikt in enig andere tabel, wat dus alleen maar duidelijker maakt dat het een slecht ontwerp is en de persoon inderdaad niet heeft begrepen hoe een database intern exact werkt.

In andere woorden zeg ik hier precies het tegenovergestelde van wat jij zegt.

[EfBe]

Verwijderd schreef op 25 februari 2003 @ 21:11:
[...]

Toch zou ik aanraden om primaire sleutels over meer dan een veld te vermijden. Er zijn eigelijk ook maar heel weinig situaties te bedenken waar het echt noodzakelijk is. Het getuigd negen van de tein keer van een slecht ontwerp. Ik zou het overigens graag proberen aan te passen,maar daar nu geen tijd en zin in

err, dit komt rechtstreeks uit een ORM model hoor. Verder mag jij vinden wat je wil in het kader van 'slecht', maar multi-column keys zijn niet 'slecht', integendeel: hoe een PK is samengesteld doet niet ter zake, ALS er maar een unieke identificatie van een entiteit is door een of meerdere attributen in een tabel.

[ Voor 15% gewijzigd door EfBe op 25-02-2003 23:31 ]

[EfBe]

Nielsz schreef op 25 February 2003 @ 21:55:
EfBe: leuke IPban table heb je waarom in godsnaam?

Nou IPv6 support leek me wel nuttig, omdat je dan niet de handel hoeft te updaten wanneer dat gemeengoed wordt binnenkort. Verder heb ik de ip adressen als segments opgeslagen met een mask, zodat je ranges kunt bannen. De IPSegmentMasked* fields zijn computed columns overigens, dwz de mask toegepast op het ip segment.

Omdat ik geen strings gebruik als ip nummers, kan ik nu heel gemakkelijk met SQL bans selecteren op basis van een IP adres in segments. Dit kan in een stored proc en neemt weinig tijd in beslag. Dit moet je wel elke keer uitvoeren wanneer een user een page opvraagt (request doet), en kan belastend werken voor je site, wanneer het te traag is. Wildcards in strings, dus 192.168.*.* bv als ban, werkt niet in SQL, dat moet je dus met de hand gaan lopen uitvogelen. Wellicht dat php of apache daar iets voor heeft, met asp.net, sqlserver en iis moet je kiezen voor segments

[EfBe]

dusty schreef op 25 februari 2003 @ 23:09:
Vaak gaan de mensen dan ook een "nieuwe" unieke sleutel toevoegen voor juist alleen dat tabel, die niet wordt gebruikt in enig andere tabel, wat dus alleen maar duidelijker maakt dat het een slecht ontwerp is en de persoon inderdaad niet heeft begrepen hoe een database intern exact werkt.

single-column PK vs multi-column PK is ook weer zo'n heilige huizendiscussie . Sommigen willen per se geen multi-column PK's en plaatsen bv in een koppeltabel een extra auto-number key die dan weer wordt hergebruikt in andere tables ipv de samengestelde key uit de koppeltabel. (Objectified Relation in ORM). Ik vind het overkill, zeker als je zoals je zegt de key niet hergebruikt in andere tables.

[Verwijderd]

Mij lijkt het nu net handiger om samengestelde PK's te gebruiken. In mijn ogen is het onhandig om nog een extra autonummerveld toe te voegen.

[djluc]

EfBe schreef op 25 February 2003 @ 23:34:
[...]

single-column PK vs multi-column PK is ook weer zo'n heilige huizendiscussie . Sommigen willen per se geen multi-column PK's en plaatsen bv in een koppeltabel een extra auto-number key die dan weer wordt hergebruikt in andere tables ipv de samengestelde key uit de koppeltabel. (Objectified Relation in ORM). Ik vind het overkill, zeker als je zoals je zegt de key niet hergebruikt in andere tables.

Het kan soms wel handig zijn als je iets wilt verwijderen, invoegen, of updaten omdat je dan een heel snel en simpel query kan gebruiken.

[dawuss]

* dawuss * Zouden jullie deze offtopic discussie misschien ergens anders willen voortzetten? /me snap er niet veel van, want in de openingspost geef ik al duidelijk aan dat ik een beginneling ben op dit gebied, dus ik heb weinig aan deze discussie.

Bij voorbaat dank

[dawuss]

Na alle adviezen heb ik m'n opzet even opnieuw uitgewerkt:


Commentaar?

[jordan2k]

Wat een toeval ben zelf bezig met een soort van ID site en zit best vast op dat DB verhaal tot dat ik dit topic tegen kwam.

vraagje is daar een progie voor ? die daar een DB van maakt ? of zit je met een teken programa die tabelen te maken ?

[gorgi_19]

jordan2k schreef op 26 February 2003 @ 20:02:
Wat een toeval ben zelf bezig met een soort van ID site en zit best vast op dat DB verhaal tot dat ik dit topic tegen kwam.

vraagje is daar een progie voor ? die daar een DB van maakt ? of zit je met een teken programa die tabelen te maken ?

offtopic:
Microsoft Visio heeft er op zich weinig problemen mee om zoiets maken. Verder kan Access ook hele nette relatiediagrammen weergeven, evenals Enterprise Manager bij MS SQL. Alhoewel deze twee laatste niet echt uitgebreid zijn

[djluc]

De laatste 2 kolommen, wat wil je daarmee bereiken? Kun je niet beter 1 berichtkolom nemen en 1 kolom met een true/false waarde die aangeeft of het plain of styles is?

Waarom wil je trouwens rechten opgeven voor 1 categorie, of maak je ook nog algemene rechten? Wat versta jij eigenlijk precies onder een categorie, wat ze hier /14 noemen ed of bedoel je iets anders?

Is het trouwens niet zo dat iemand die topics mag sluiten ze ook mag verplaatsen, dat mogen de meeste mods toch?

Verder geef je bij een topic aan of deze actief is, wil je daarmee zeggen niet gesloten, of bedoel je dat het een hottopic is waar dus bijvoorbeeld veel op gereageerd wordt, dan hoort dat namelijk niet echt in je db thuis.

Ik hoop dat je hier wat aan hebt, overigens de discussie die je net afkapt kan toch van essentieel belang zijn voor de performance van je script, nergens is gezegd dat het gemakkelijk kan zijn om een forum te maken. Al doende leert men.

[dawuss]

ik heb dit gewoon met MS Word gemaakt. Het was in het begin eigenlijk ook alleen maar de bedoeling om voor mijzelf duidelijk en functioneel te zijn, maar toen het af was dacht ik "waarom post ik het niet op GoT".

[dawuss]

djluc schreef op 26 February 2003 @ 20:05:
De laatste 2 kolommen, wat wil je daarmee bereiken? Kun je niet beter 1 berichtkolom nemen en 1 kolom met een true/false waarde die aangeeft of het plain of styles is?

Naar aanleiding van de opmerking van EfBE heb ik hier voor gekozen. In de 'plain' kolom komt de tekst, met UBB code, en in de 'styled' kolom komt de daadwerkelijke code, zodat als een user zijn/haar post wil editen, deze niet met HTML/XML/... om de oren gesmeten wordt, maar gewoon de oorspronkelijke post.

Waarom wil je trouwens rechten opgeven voor 1 categorie, of maak je ook nog algemene rechten? Wat versta jij eigenlijk precies onder een categorie, wat ze hier /14 noemen ed of bedoel je iets anders?

Ik wil gebruikers per categorie rechten gaan geven ja. En met een categorie bedoel ik inderdaad een subforum. Zo kan ik per forum aangeven wat welke user mag.

Is het trouwens niet zo dat iemand die topics mag sluiten ze ook mag verplaatsen, dat mogen de meeste mods toch?

Ja, maar ik wil toch de mogelijkheid behouden om dit te kunnen veranderen. Zo kan ik ook een soort van lite-mod of zo maken. Je weet maar nooit waar het goed voor is

Verder geef je bij een topic aan of deze actief is, wil je daarmee zeggen niet gesloten, of bedoel je dat het een hottopic is waar dus bijvoorbeeld veel op gereageerd wordt, dan hoort dat namelijk niet echt in je db thuis.

Actief betekent inderdaad dat deze 'niet op slot' is. ik vind If(topic == Active) mooier dan if(topic != Inactive).

Overigens de discussie die je net afkapt kan toch van essentieel belang zijn voor de performance van je script, nergens is gezegd dat het gemakkelijk kan zijn om een forum te maken. Al doende leert men.

Dat klopt, maar het ging in eerste instantie over mijn database model, en dat is erg simpel en eenvoudig en ik ben een beginner. Jullie discussie ging over de database van EfBE, en was voor mij dermate ingewikkeld dat ik er niets aan had. Ik keur het verder ook niet af of zo, maar het is offtopic, dus open er dan liever een apart topic voor, wat ik overigens graag wil lezen en leren begrijpen, maar zo wordt m'n topic onoverzichtelijk.

In ieder geval tot nu toe iedereen bedankt voor de goede tips

[Verwijderd]

Ik gebruik momenteel xCase voor het maken van Data Modellen. Ik vind het prima werken