[mySQL] database indeling

[Captain N]

Ik heb nu voor het eerst een database ingedeeld, en iets zegt me dat het wel helemaal anders zal moeten... dus tips/opmerkingen zijn welkom. Ik heb de volgende tabellen:

tekst
----------
ID | tekst | datum


titel
-----------
blz | titel


sectie
----------
sec | svu


auteur
----------
aut_ID | aut | email


rpganime
----------
ID | blz | sec | aut_ID


*************
In de eerste tabel genaamd "tekst" komt een ID, de tekst van het artikel, en de datum waarop het artikel is geschreven.

In de tweede tabel genaamd "titel" komt onder blz een afkorting als bijvoorbeeld "main" (om te gebruiken in blaat.php?blz=main), en onder titel komt de titel die bij de afkorting hoort (dus als blz=main, titel=Hoofdpagina).

In de derde tabel genaamd "sectie" komen "sec": zelfde idee als blz, alleen dan de afkorting van een sectie. "svu" staat voor "Sectie VolUit".

In de vierde tabel genaamd "auteur" staan "aut_ID" (ID van de auteur), "aut" (naam van de auteur), en "email" (email van de auteur).

Als laatste tabel is er "rpganime". Hierin komt: "ID" (de ID uit de tabel "tekst"), "blz" (uit "titel"), "sec" (uit "sectie"), en "aut_ID" (uit "auteur").

*****************

Ik wil nog even zeggen dat ik al een boek + tuto's in huis heb (en doorgenomen), maar ik volg het idee van indelen van een database nog niet echt helamaal goed volgens mij... vandaar mijn vraag om me even op weg te helpen.

Alvast bedankt,

Goku.

[Janoz]

Ik zou sowieso met id nummers werken ipv blz ed .. Dat is een stuk makkelijker, en sneller voor jou en de database (aanroepen doe je dan ook niet met blz=main, maar blz=3 oid)

[Captain N]

Daar zit inderdaad wel wat in ja, bedankt.

Ik heb nu dus "blz" en "sec" de eigenschappen

INT NOT NULL AUTO_INCREMENT PRIMARY KEY

gegeven. Meer tips zijn zeer welkom.

[2]

Aangezien ik ook met een vraagje rondloop binnen dit kader post ik het hier ff.

Als je een database hebt voor grote stukken tekst, artikelen bijvoorbeeld, die je uiteindelijk wilt splitsen in verschillende pagina's, is het dan handiger om dat on the fly te doen, dus iedere keer dat het artikel opgevraagd wordt met een regexp de eerste 500 woorden ofzo eruit te halen, tweede pagina de woorden 500 - 1000 etc. of is het beter om de tekst direct bij invoering te splitsen en de stukken allemaal apart in de database te zetten?

Dus zo:

code:

+------+--------------------+
|  ID  | Text          |
+------+--------------------+
| 0001 | alle 1000 woorden  |
+------+--------------------+
| 0002 | alle 1500 woorden  |
+------+--------------------+
| 0003 | alle 500 woorden   |
+------+--------------------+

of zo:

code:

+------+--------------------+------+
|  ID  | Text          | Page |
+------+--------------------+------+
| 0001 | eerste 500 woorden |   1  |
+------+--------------------+------+
| 0001 | tweede 500 woorden |   2  |
+------+--------------------+------+
| 0002 | eerste 500 woorden |   1  |
+------+--------------------+------+
| 0002 | tweede 500 woorden |   2  |
+------+--------------------+------+
| 0002 | derde  500 woorden |   3  |
+------+--------------------+------+
| 0003 | eerste 500 woorden |   1  |
+------+--------------------+------+

etc.

Scheelt dat niet een hoop tijd of is het juist inefficienter?

[Janoz]

Goku> Zet er gelijk ook ff UNSIGNED bij, aangezien je toch geen negatieve ID's gebruikt.

2> Maak dan wel 2 tabellen:

artikel
ID artikel titel schrijver en rest artiekelgegevens

pagina
artikelid pgnumber tekst

Opslaan in meerdere velden is makkelijker, omdat dat zo uit de database getrokken kan worden (Is dus ook iets sneller dus) Groot nadeel hiervan is dat het maken van artikelen wat ingewikkelder wordt. Je kunt namelijk niet zomaar bij het 500-e teken af gaan kappen.. Het afkappen kan beter tussen twee alinea's gebreuren

[Captain N]

Okay, weer bedankt. Is er ook nog iemand die opmerkingen heeft wat betreft de structuur zeg maar. Dus hoe het beter kan qua opbouw?

[Killemov]

Op zondag 09 september 2001 22:24 schreef 2 het volgende:
Aangezien ik ook met een vraagje rondloop binnen dit kader post ik het hier ff.

Als je een database hebt voor grote stukken tekst, artikelen bijvoorbeeld, die je uiteindelijk wilt splitsen in verschillende pagina's, is het dan handiger om dat on the fly te doen, dus iedere keer dat het artikel opgevraagd wordt met een regexp de eerste 500 woorden ofzo eruit te halen, tweede pagina de woorden 500 - 1000 etc. of is het beter om de tekst direct bij invoering te splitsen en de stukken allemaal apart in de database te zetten?

Dus zo:

code:

+------+--------------------+
|  ID  | Text          |
+------+--------------------+
| 0001 | alle 1000 woorden  |
+------+--------------------+
| 0002 | alle 1500 woorden  |
+------+--------------------+
| 0003 | alle 500 woorden   |
+------+--------------------+

of zo:

code:

+------+--------------------+------+
|  ID  | Text          | Page |
+------+--------------------+------+
| 0001 | eerste 500 woorden |   1  |
+------+--------------------+------+
| 0001 | tweede 500 woorden |   2  |
+------+--------------------+------+
| 0002 | eerste 500 woorden |   1  |
+------+--------------------+------+
| 0002 | tweede 500 woorden |   2  |
+------+--------------------+------+
| 0002 | derde  500 woorden |   3  |
+------+--------------------+------+
| 0003 | eerste 500 woorden |   1  |
+------+--------------------+------+

etc.

Scheelt dat niet een hoop tijd of is het juist inefficienter?

Je moet je tekst in ieder geval nooit automatisch laten opsplitsen. (Dan krijg je ALTIJD gezeik met layout.) Wat je wel kunt doen is een speciale 'tag' (<?PAGEBREAK>) in je tekst opnemen waarop eventueel gesplitst mag worden. Maarrrr ... dan moet je wel de mogelijk hebben om de tekst te parsen. Zo niet: Tekst opgesplitst in pagina's opslaan, je kunt dan altijd nog eventueel de tekst van verschillene pagina's bij elkaar vegen tot 1 pagina.

[Killemov]

code:

tekst
----------
ID | tekst | datum

titel
-----------
blz | titel

sectie
----------
sec | svu

auteur
----------
aut_ID | aut | email

rpganime
----------
ID | blz | sec | aut_ID

Die laatste tabel 'rpganime' moet zowieso weg.

Artikel = ArtID + titel + datum + samenvatting
Pagina = ArtID + PagID + tekst
Auteur = AutID + naam + omschrijving + email

Als een artikel maar door 1 auteur kan worden geschreven:
AutID opnemen bij Artikel
anders:
GeschrevenDoor = ArtID + AutID

[drm]

Killemov:
(..)
Als een artikel maar door 1 auteur kan worden geschreven:
AutID opnemen bij Artikel
anders:
GeschrevenDoor = ArtID + AutID

Daar zou ik ook nog een primary key aan hangen. Makkelijker updaten / replacen.

code:

GeschrevenDoor
+------+-------+--------+
| gdID | artID | authID |
+------+-------+--------+

[2]

Op zondag 09 september 2001 22:39 schreef Janoz het volgende:
2> Maak dan wel 2 tabellen:

artikel
ID artikel titel schrijver en rest artiekelgegevens

pagina
artikelid pgnumber tekst

Ja precies, dat was mijn bedoeling.

Opslaan in meerdere velden is makkelijker, omdat dat zo uit de database getrokken kan worden (Is dus ook iets sneller dus) Groot nadeel hiervan is dat het maken van artikelen wat ingewikkelder wordt. Je kunt namelijk niet zomaar bij het 500-e teken af gaan kappen.. Het afkappen kan beter tussen twee alinea's gebreuren

Maar dat heb je dan toch ook als je het op de eerste door mij genoemde manier doet? De tekst wordt op dezelfde manier en op dezelfde plaats opgesplitst, alleen op een anderr moment .

Op maandag 10 september 2001 11:07 schreef Killemov
Je moet je tekst in ieder geval nooit automatisch laten opsplitsen. (Dan krijg je ALTIJD gezeik met layout.) Wat je wel kunt doen is een speciale 'tag' (<?PAGEBREAK>) in je tekst opnemen waarop eventueel gesplitst mag worden. Maarrrr ... dan moet je wel de mogelijk hebben om de tekst te parsen. Zo niet: Tekst opgesplitst in pagina's opslaan, je kunt dan altijd nog eventueel de tekst van verschillene pagina's bij elkaar vegen tot 1 pagina.

Dat is inderdaad en erg goed idee. Ik denk wel dat het allerbeste sowieso is dat de schrijvers er ook rekening mee houden, iets wat niet zo heel vreemd is ook lijkt mij. Kunnen zij ook zelf aangeven hoe ze de tekst willen indelen over de verschillende pagina's.

Ik had als voordeel van dit systeem ook nog bedacht dat als je een zoekfunctie erop los zou laten, het ook makkelijker zou zijn (sneller voornamelijk) om de resultaten te laten leiden naar de desbetreffende pagina van het artikel waar de zoekterm gevonden is.

Heeft iemand ervaring met dit soort indeling en is het gebruikelijk om het op deze manier te doen?

[Captain N]

Op maandag 10 september 2001 11:19 schreef Killemov het volgende:

code:

tekst
----------
ID | tekst | datum

titel
-----------
blz | titel

sectie
----------
sec | svu

auteur
----------
aut_ID | aut | email

rpganime
----------
ID | blz | sec | aut_ID

Die laatste tabel 'rpganime' moet zowieso weg.

Artikel = ArtID + titel + datum + samenvatting
Pagina = ArtID + PagID + tekst
Auteur = AutID + naam + omschrijving + email

Als een artikel maar door 1 auteur kan worden geschreven:
AutID opnemen bij Artikel
anders:
GeschrevenDoor = ArtID + AutID

Bedankt voor het advies. Die samenvatting die je in Artikel hebt staan, is dat bedoeld voor als je een zoekoptie wilt maken op je site of zo?

[Verwijderd]

smells like spam spirit..

[tomato]

Op vrijdag 14 september 2001 13:54 schreef WouteRF het volgende:
smells like spam spirit..

Smells [url="http://gathering.tweakers.net/forum/find/poster/25187]like[/url] 'techposts aan het verzamelen'

[Captain N]

??

[tomato]

www.Goku.nl: ??

Had niets met jou te maken, dus ook volledig off-topic (evenals de reactie van WourteRF).

[Verwijderd]

Ik wil ook wel eens weten hoe anderen hun 'databases' indelen, ontwerpen.... waar ga je naar kijken, wat add je extra zodat het de functionaliteit van je db vergroot etc!?

heeft iemand trouwens comments op mijn structuren?

code:

// fotoboek

fotoboek_id int(4) NOT NULL auto_increment,
fotoboek_regdate datetime NOT NULL,
fotoboek_regip varchar(15) NOT NULL,
fotoboek_reghost varchar(75) NOT NULL,
fotoboek_date datetime NOT NULL,
fotoboek_ip varchar(15) NOT NULL,
fotoboek_host varchar(75) NOT NULL,

fotoboek_validated tinyint(3) NOT NULL,
fotoboek_level tinyint NOT NULL,
fotoboek_mail varchar(50) NOT NULL,
fotoboek_cookie varchar(20) NOT NULL,
fotoboek_username varchar(12) NOT NULL,  
fotoboek_password varchar(12) NOT NULL,  

fotoboek_firstname varchar(50) NOT NULL,  
fotoboek_lastname varchar(50) NOT NULL,  
fotoboek_email varchar(50) NOT NULL,  
fotoboek_website varchar(75) NOT NULL,  

fotoboek_province varchar(50) NOT NULL,  
fotoboek_city varchar(50) NOT NULL,  
fotoboek_country varchar(50) NOT NULL,  
fotoboek_birthday varchar(50) NOT NULL,  
fotoboek_sex varchar(5) NOT NULL,  
fotoboek_icq int(12) NOT NULL,  
fotoboek_msn varchar(50) NOT NULL,  
fotoboek_irc varchar(50) NOT NULL,
fotoboek_ircchannel varchar(50) NOT NULL,
fotoboek_profession varchar(50) NOT NULL,  
fotoboek_school varchar(50) NOT NULL,  

fotoboek_text as longtext NOT NULL,
UNIQUE id (fotoboek_id)

// poll

poll_id int(4) NOT NULL auto_increment,
poll_username varchar(12) NOT NULL,
poll_password varchar(12) NOT NULL,
poll_question varchar(75) NOT NULL,

poll_pollid int(4) NOT NULL,
poll_optionid longint NOT NULL,
poll_optionvalue varchar(75) NOT NULL,
poll_votes longint NOT NULL,

poll_ipid int(4) NOT NULL,
poll_ip varchar(75) NOT NULL,
UNIQUE id (poll_id)

// statistics

stat_id int(4) NOT NULL auto_increment,
stat_username varchar(12) NOT NULL,
stat_password varchar(12) NOT NULL,
stat_title varchar(75) NOT NULL,
stat_referer varchar(75) NOT NULL,

stat_statid int(4) NOT NULL,
stat_ip varchar(75) NOT NULL,
stat_ipcount longint NOT NULL,
stat_os varchar(75) NOT NULL,
stat_oscount longint NOT NULL,
stat_host varchar(75) NOT NULL,
stat_hostcount longint NOT NULL,
stat_date datetime NOT NULL,
stat_datecount longint NOT NULL,
stat_color varchar(75) NOT NULL,
stat_colorcount longint NOT NULL,
stat_referer varchar(75) NOT NULL,
stat_referercount longint NOT NULL,
stat_browser varchar(75) NOT NULL,
stat_browsercount longint NOT NULL,
stat_screensize varchar(75) NOT NULL,
stat_screensizecount longint NOT NULL,
UNIQUE id (stat_id)

Tnx.

[Verwijderd]

Edit: was zinloos

[Verwijderd]

dubbel