[php&mysql] hoe opzetten reviewsysteem..

[TheRebell]

Olá,

ik heb al een tijd het idee om een review/artikel systeem(pje) te gaan maken in PHP en MySQL.
Beetje spiekend naar T.NET hoe ze het daarzo doen vraag ik me toch een aantal dingen af..

Ik wil het zo doen dat je de titel van je hoofdstuk en de tekst opgeeft. Dit wordt gesaved als jij naar de volgende bladzijde gaat (dus per scherm/form 1 hoofdstuk).
Alleen moetje ook terug kunnen... Nu zou je dus na << of >> door je hoofdstukjes moeten kunnen bladeren maar nu moet hierachter telkens de content worden gesaved (je kunt nl evt iets veranderen) maar als het een vorige page is moet je het updaten en anders inserten
het wordt dan per hoofdstuk in een row opgeslagen met een review_id en een page_nr.

Vraag me af of het niet makkelijker/simpeler is om alle tekst (de hoofdstuktitel + de tekst) in een text field te zetten. Dan krijg je dus één row per review/artikel.

Op het moment is dit mijn database:

code:

+-----------+
| review    |
+-----------+
|review_id  |
|rev_titel  |
|omschr     |
|auteur     |
|timestamp  |
+-----------+

+-----------+
|review_data|
+-----------+
|review_id  |
|pag_nr     |
|hfd_titel  |
|tekst      |
+-----------+

Met een relatie van review_id op review_id.
Geen idee of dit een beetje zou werken

heb ergen het gevoel dat ik erg verkeerd bezig ben

kan natuurlijk ook gewoon niet 'auto-saven' maar hiervoor een aparte button maken. Door << & >> kun je dan alleen 'bladeren'. Op deze manier kun je dan ook kijken of ie terug-bladerd en dan hieraan een update hangen

Heb het gevoel dat ik mezelf antwoord geef in afwachting van mijn mede GoT'ers

..zou de rest slapen

ikke nu wel

[.GoO]

Kunnen 2 verschillende tabellen eigenlijk wel dezelfde primaire sleutel hebben?

[Wouter Tinus]

Op woensdag 03 juli 2002 01:08 schreef devv05 het volgende:
Kunnen 2 verschillende tabellen eigenlijk wel dezelfde primaire sleutel hebben?

Ja _{is nl. niet 'dezelfde', ze hebben alleen dezelfde naam}

[Postman]

Je kunt toch ook twee tabellen maken? Een voor de final data en 1 voor de update. Save in het begin de titel, reviewer en de rest van de static data in de final tabel. Neem dan de id van die row (row is nog niet compleet, hoofdstukken moeten nog ingevoegd worden) en zet die dan per hoofdstuk in de update tabel. Aan het einde zet je alles in de final tabel en wis je de update tabel (alleen wat die id heeft natuurlijk, of je moet alleen op die dbase werken). Maak hiervoor dan een aparte commit knop oid.

[TheDane]

Op woensdag 03 juli 2002 01:08 schreef devv05 het volgende:
Kunnen 2 verschillende tabellen eigenlijk wel dezelfde primaire sleutel hebben?

tuurlijk, primary key valt binnen de scope van de tabel. dus table1.review_id staat in principe compleet los van table2.review_id ... alleen intern kunnen er dan relaties tussen bestaan.

[.GoO]

Op woensdag 03 juli 2002 01:16 schreef TheDane het volgende:

[..]

tuurlijk, primary key valt binnen de scope van de tabel. dus table1.review_id staat in principe compleet los van table2.review_id ... alleen intern kunnen er dan relaties tussen bestaan.

Owkee, begon ff te twijfelen

Maar het lijkt me wel verwarrend.. Ik heb altijd geleerd dat het niet mag...

[TheDane]

misschien zou ik 't zo doen: (off the top of my head)

reviews
--------------
id
title
author
etc etc
first_page_id


review_data
----------------
page_id
(review_id)
next_page_id
paragraph_title
paragraph_data


review_data.page_id is dan de foreign key naar reviews.first_page_id
review_data.next_page_id is een key naar review_data.page_id

review_data.review_id heb je in principe niet meer nodig; de volgorde van de hoofdstukken staat in de tabel vastgelegd, en waar 't eerste hoofdstuk bij hoort weet je ook.. ik zou review_id wel erbij zetten wegens performance (bij verwijderen van review bijvoorbeeld)

't voordeel hiervan is dat je heel makkelijk (aanpassen van 1 next_page_id een pagina in je review kan tussenvoegen. je kunt ook heel makkelijk naar volgende/vorige page in je review scrollen en je hoeft zelfs niet verplicht een 'hoofdstuk' toe te voegen aan je review (in review_data)

imo redelijk schaalbaar

[TheDane]

Op woensdag 03 juli 2002 01:21 schreef devv05 het volgende:

[..]

Owkee, begon ff te twijfelen

Maar het lijkt me wel verwarrend.. Ik heb altijd geleerd dat het niet mag...

huh waar dan ?

imo is 't juist verwarrend als je in iedere tabel een andere naam gebruikt terwijl je 't over dezelfde entiteit/attribuut hebt.

in user table heb je 't over user_id, in een of andere content table heb je 't over author_id
in een andere tabel heb je 't wellicht over user1_id en user2_id

maakt 't niet bijzonder duidelijker / overzichtelijker op imo....

[SyphOn]

Zorg dat dusty dit topic ff leest
Aangezien hij veel van databases etc. weet.

[TheRebell]

mogûh,

waarom ik 2x review_id heb is omdat deze in feiten hetzelfde zijn. Het geeft de relatie aan tussen de eerste helft van het review (de titel en auteur) en de echte tekst. Dit is in feite één. Voor de db maakt het geen mik uit of jij in 2 taballen dezelfde naam gebruikt, ligt er puur aan of jij(de ontwikkelaar) deze manier handig vindt

review_id zou in de tabel review_data idd een foreign key worden, dat klopt. Page_id is dus page_nr (het pagina nummer).

Ik denk dat het makkelijkste is dat je de titel en een korte omschrijving als eerste opgeeft. Daarna kun je je tekstje typen waarna je via een knoppie (nieuw ofzo ) een nieuwe page krijgt waarbij de huidige gesaved wordt op review_id en page_nr(of page_id). Op deze manier kun je doorgaan en kunnen er zelfs meerdere reviews tegelijk worden ingevoerd.
Als je tijdens je verhaaltje terug wilt kan dat door een knoppie "<<" en dan kun je evt iets aanpassen waarna je het los moet saven (save changes) ipv via een auto-save ofzo. Door "<<" en ">>" kun je dus bladeren, die hebben verder dus geen save functie.
Op deze manier moet je dus een review kunnen invoeren, updaten en zo evt ook kunnen deleten (op review_id). Ook kun je dus zo vrij makkelijk een list maken van alle reviews en de hoofdstukken erin.

Lijkt het ergens op?

Vraag me toch nog af of het veel uitmaakt als je alle tekst in één field zou zetten ipv gescheiden per hoofdstuk Ik denk dat de laaste qua onderhoud makkelijker is.

[TheRebell]

Op woensdag 03 juli 2002 10:43 schreef SyphOn het volgende:
Zorg dat dusty dit topic ff leest
Aangezien hij veel van databases etc. weet.

Dat zou idd erg mooi zijn
Zoek dus een goed ontwerp van mn db, maar denk dat deze redelijk schaalbaar is (hoop ik )

[TheRebell]

subtiel trapje

morgen ga ik weerverder met het uitdenken van de DB (was vandaag weg dusja)...

Denk dat de huidige layout van de DB zo redelijk schaalbaar is en dat ik zo de opties vrij makkelijk moet kunnen integreren..

[Nielsz]

Misschien een tipje, kan je beter een topic smiddags aanmaken, dan kan je na 24 uur kicken, op een moment dat er ook daadwerkelijk mensen online zijn

[Soultaker]

Op donderdag 04 juli 2002 01:01 schreef Nielsz het volgende:
Misschien een tipje, kan je beter een topic smiddags aanmaken, dan kan je na 24 uur kicken, op een moment dat er ook daadwerkelijk mensen online zijn

Of overmorgenmiddag weer, natuurlijk. (Ik draag iig mijn steentje bij om 'm hoog te houden. )

[Helox-in-a-box]

ennuh, alles kan gewoon in 1 tabel als je tog geen 1 op veel relaties hebt tussen de tabellen aangezien je review_id in beide tabellen gebruikt.

[TheRebell]

Op donderdag 04 juli 2002 01:01 schreef Nielsz het volgende:
Misschien een tipje, kan je beter een topic smiddags aanmaken, dan kan je na 24 uur kicken, op een moment dat er ook daadwerkelijk mensen online zijn

Was gisteren laat thuis dusja. En vaak zit ik tot vrij laat online en dan zijn de meeste GoT'ertjes alweer aan het
En aangezien ik meestal pas 's avonds tijd heb wordt het dus 's avonds posten...

Op donderdag 04 juli 2002 01:59 schreef Helox-in-a-box het volgende:
ennuh, alles kan gewoon in 1 tabel als je tog geen 1 op veel relaties hebt tussen de tabellen aangezien je review_id in beide tabellen gebruikt.

Tsja, zou idd ook nog kunnen. Alleen krijg je dan dat echt alles bij elkaar staat (duh) en niet dat je de titel,auteur,tijd en evt publicatie apart hebt vande echte tekst. Als je 1 tabel hebt zul je die gegevens meerdere malen tegen komen(auteur,tijd,publicatie).

Vraag me nu alleen af wat een goede manier is om te kijken of je evt op de "<<" of ">>" knop hebt gedrukt. Dan moet ie namelijk de vorige/volgende page halen en het page_id(of page_nr) verlagen/verhogen. Ook moet je dus ventevoren weten hoeveel pagina's er zijn anders plaatjes een ">>" knopje terwijl het de laatste page is . Ik zou dit gewoon via een formpje doen, zijn hiervoor misschien makkelijkere methoden of moet het gewoon zo

[TheDane]

Op donderdag 04 juli 2002 11:49 schreef TheRebell het volgende:

of je evt op de "<<" of ">>" knop hebt gedrukt. Dan moet ie namelijk de vorige/volgende page halen en het page_id(of page_nr) verlagen/verhogen. Ook moet je dus ventevoren weten hoeveel pagina's er zijn anders plaatjes een ">>" knopje terwijl het de laatste page is . Ik zou dit gewoon via een formpje doen, zijn hiervoor misschien makkelijkere methoden of moet het gewoon zo

kijk dan eens naar mijn oplossing

next_page_id opnemen in review_data

als ie leeg is: geen linkje, en anders linkje naar page met dat id.

[TheRebell]

Op donderdag 04 juli 2002 13:44 schreef TheDane het volgende:

[..]

kijk dan eens naar mijn oplossing

next_page_id opnemen in review_data

als ie leeg is: geen linkje, en anders linkje naar page met dat id.

[shame]

[/shame]

ik ga het zo eens proberen op je manier TheDane

[TheDane]

Op donderdag 04 juli 2002 13:54 schreef TheRebell het volgende:

[..]

[shame]

[/shame]

ik ga het zo eens proberen op je manier TheDane

succes

[TheRebell]

Op donderdag 04 juli 2002 13:44 schreef TheDane het volgende:

[..]

kijk dan eens naar mijn oplossing

next_page_id opnemen in review_data

als ie leeg is: geen linkje, en anders linkje naar page met dat id.

Je neemt next_page_id op om naar een volgende pagina te gaan. Maar dan zou previous_page_id er ook bij moeten staan aangezien je dan een vorige-knopje kunt maken...

Klopt zekers ook wel dat er nu redelijk wat query's gaan lopen?! Inserten in de ene table, lezen van een auto_id en dan inserten in de andere en vervolgens hier weer wat uit lezen en weer terug inserten in de 1e table... pfff....

[TheDane]

Op donderdag 04 juli 2002 15:22 schreef TheRebell het volgende:

[..]

Je neemt next_page_id op om naar een volgende pagina te gaan. Maar dan zou previous_page_id er ook bij moeten staan aangezien je dan een vorige-knopje kunt maken...

Klopt zekers ook wel dat er nu redelijk wat query's gaan lopen?! Inserten in de ene table, lezen van een auto_id en dan inserten in de andere en vervolgens hier weer wat uit lezen en weer terug inserten in de 1e table... pfff....

je zou inderdaad nog een previous_page_id op kunnen nemen in de table, maar je zou ook in je linkje naar next_page een extra parameter toe kunnen voegen met daarin 't id van de huidige page. die kun je dan gebruiken in je linkje naar vorige page. (eerste page is geen probleem, want die heeft toch geen previous, en dan hoef je dat linkje dus ook niet te tonen)

en wat bedoel je precies met dat query-deel ? valt volgens mij heel erg mee, als je een nieuwe page maakt bij een review, dan geef je als (hidden) parameter mee de huidige page, en dan heb je dus 1 insert query (voor je nieuwe page) en 1 update query (voor het updaten van je next_page_id in je voorgaande page.)

voordeel is in ieder geval dat de page_id's niet opeenvolgend hoeven te zijn. dus kun je makkelijk een page tussenvoegen zonder alle achterliggende pages te gaan schuiven.

[TheRebell]

Op donderdag 04 juli 2002 16:46 schreef TheDane het volgende:

[..]

je zou inderdaad nog een previous_page_id op kunnen nemen in de table, maar je zou ook in je linkje naar next_page een extra parameter toe kunnen voegen met daarin 't id van de huidige page. die kun je dan gebruiken in je linkje naar vorige page. (eerste page is geen probleem, want die heeft toch geen previous, en dan hoef je dat linkje dus ook niet te tonen)

Alleen kun je dan niet terug bladeren. Dus van page 5 naar 4 en dan naar 3 (enz).

en wat bedoel je precies met dat query-deel ? valt volgens mij heel erg mee, als je een nieuwe page maakt bij een review, dan geef je als (hidden) parameter mee de huidige page, en dan heb je dus 1 insert query (voor je nieuwe page) en 1 update query (voor het updaten van je next_page_id in je voorgaande page.)

De waarden worden iig gewoon via hidden fields meegegeven(review_id en previous_page_id)

Nou je krijgt 3 query's om de 1e page in te voeren:
- geg in review zetten, review_id uitlezen (mysql_insert_id),
- geg in review_data zetten, page_id uitlezen,
- geg in review updaten, first_page-id

Voor elke volgende page krijg je 2 query's:
- geg in review_data zetten, het page_id uitlezen,
- geg van vorige page aanpassen (next_page_id)

voordeel is in ieder geval dat de page_id's niet opeenvolgend hoeven te zijn. dus kun je makkelijk een page tussenvoegen zonder alle achterliggende pages te gaan schuiven.

Dit was bij mijn opzetje ook al zo het geval. Een page was uniek op de combinatie review_id en page-nr. Voeg je later een page toe dan wordt het dus gewoon review_id + volgende page nr, leen moet je dan we weten wat het laatste nr is. Danwerkt jou manier iets simpeler
Schuiven was iig ook niet de bedoeling cq nodig.

[TheRebell]

Hoe kun je nu het beste van die keuzes maken?

Je hebt knopjes "invoeren" & "volgende"(als vb), koppel je daar dan aan het begin van je script een stuk code aan van:

PHP:

<?if($HTTP_GET_VARS['invoeren']){   //voer enkele acties uit}if($HTTP_GET_VARS['volgende']){   //voer enkele acties uit}?>

of zijn hier andere cq betere/makkelijkere manieren voor?!
Als ik het zo doe krijg ik vaak een hele rij met variabelen die true of false moeten zijn om een statement uniek te maken.

[TheDane]

ik gebruik altijd de $action variable:

en dan zoiets:

PHP:

<?switch ($action) { case 'add' : doe iets; break; case 'edit': doe iets; break; case 'etc' : etc; break;}?>

[SyphOn]

Op phpbuilder.com staat een tutorial over wat jij wilt.

[TheRebell]

Op vrijdag 05 juli 2002 09:25 schreef SyphOn het volgende:
Op phpbuilder.com staat een tutorial over wat jij wilt.

Ohja : ik kijk daar ook altijd of er toevallig niets tussen staat (meestal voordat ik hier post) maar heb niets kunnen vinden. Zou je misschien kunnen zeggen welke tut (article) je bedoeld?

[TheRebell]

Op vrijdag 05 juli 2002 09:03 schreef TheDane het volgende:
ik gebruik altijd de $action variable:

en dan zoiets:

PHP:

<?switch ($action) { case 'add' : doe iets; break; case 'edit': doe iets; break; case 'etc' : etc; break;}?>

Je gebruikt dus zoiets:

code:

<input type=submit name=action value=add>
<input type=submit name=action value=edit>

zoiets?

[Verwijderd]

Ik zou 2 tabellen gebruiken.

Tabel 1
ID - Review onderwerp - datum - poster - etc. etc.

Tabel 2
ID - review tekst

Waarbij de id in tabel 2 per review verschillend is.
Een review bestaande uit 6 pagina's kent hier dus 6 dezelfde id's. Maak een combinatie van de id in tabel 1 naar dezelfde id's in tabel 2.

[TheRebell]

Op vrijdag 05 juli 2002 11:58 schreef laddy17 het volgende:
Ik zou 2 tabellen gebruiken.

Tabel 1
ID - Review onderwerp - datum - poster - etc. etc.

Tabel 2
ID - review tekst

Waarbij de id in tabel 2 per review verschillend is.
Een review bestaande uit 6 pagina's kent hier dus 6 dezelfde id's. Maak een combinatie van de id in tabel 1 naar dezelfde id's in tabel 2.

Nou ik heb deze tabellen al (thnx 2 TheDane)

code:

review
--------
review_id
review_title
author
first_page_id
locked
timestamp

review_data
-----------
page_id
review_id
paragraph_title
paragraph_text
previous_page_id
next_page_id

en dit werkt perfect dus..
Nu nog even de mogelijkheid voor het bladeren erin zetten. Zit alleen nog ff te denken of ik voor de statements een switch ga gebruiken. Wat zou nu echt makkelijker/beter zijn
allemaal if-jes of één switch met allemaal cases.
Ik principe is het beter om veel if'statements te vervangen door één switch...

[TheDane]

Op vrijdag 05 juli 2002 10:06 schreef TheRebell het volgende:

[..]

Je gebruikt dus zoiets:

code:

<input type=submit name=action value=add>
<input type=submit name=action value=edit>

zoiets?

yep, that's it.

[TheRebell]

Op vrijdag 05 juli 2002 12:22 schreef TheDane het volgende:

[..]

yep, that's it.

mooi, ik ga hem zo veranderen en er een switch in zetten.
Een review toevoegen werkt iig al , de page_id's plaatst ie netjes

[Verwijderd]

Ik zou eerst een ER diagram gaan maken en misschien een usecase zodat duidelijk wordt wat een gebruiker allemaal kan en wat er wordt bijgehouden in je systeem.

Aan de hand daarvan kun je dan gaan coden...

Dus maak ff een diagrammetje en daar kijk ik dan wel ff na (en natuurlijk ook Dusty, met behulp van z'n Date(!?) boek)

[SyphOn]

Op vrijdag 05 juli 2002 10:04 schreef TheRebell het volgende:

[..]

Ohja : ik kijk daar ook altijd of er toevallig niets tussen staat (meestal voordat ik hier post) maar heb niets kunnen vinden. Zou je misschien kunnen zeggen welke tut (article) je bedoeld?

http://www.phpbuilder.com/columns/rod20000221.php3

Ik denk dat je daar heel wat verder mee komt

[TheRebell]

Ik heb hier een erd'tje


en een use-case-diagram


Wat scenario's:
Use Case name create new review
Participating Actor auteur
Entry condition titel en tekst zijn ingevoerd
Flow of events

• sys slaat geg op in review,

• sys leest review_id,

• sys slaat geg op in review_data,

• sys leest page_id,

• sys slaat page_id op in review als first_page_id,

• sys genereert nieuw form met review_id en previous_page_id
Exit condition 1e pagina is opgeslagen en 2e formulier gegenereerd
Exceptions

• geen db verbinding

• niets ingevuld

voor alle pagina's NA de 1e
Use Case name create new page
Participating Actor auteur
Entry condition titel en tekst zijn ingevoerd
Flow of events

• sys slaat geg op in review_data

• sys leest page_id,

• sys slaat next_page_id op in review_data (waar page_id=previous_page_id,

• sys genereert nieuw form met review_id en previous_page_id
Exit condition 1e pagina is opgeslagen en volgende formulier gegenereerd
Exceptions

• geen db verbinding

• niets ingevuld

Use Case name get previous page
Participating Actor auteur
Entry condition previous_page_id is gegeven
Flow of events

• sys leest titel en tekst uit review_data waar page_id=previous_page_id

• sys plaatst geg in form
Exit condition form met gelezen geg
Exceptions

• geen db verbinding

• niets ingevuld

Use Case name get next page
Participating Actor auteur
Entry condition next_page_id is gegeven
Flow of events

• sys leest titel en tekst uit review_data waar page_id=next_page_id

• sys plaatst geg in form
Exit condition form met gelezen geg
Exceptions

• geen db verbinding

• niets ingevuld

Use Case name publish
Participating Actor auteur
Entry condition review_id is gegeven
Flow of events

• sys set locked=0 waar review_id=review_id
Exit condition review is gepubliceerd
Exceptions

• geen db verbinding

• geen review_id

zoiets denk ik...

[TheRebell]

Op vrijdag 05 juli 2002 15:52 schreef SyphOn het volgende:

[..]

http://www.phpbuilder.com/columns/rod20000221.php3

Ik denk dat je daar heel wat verder mee komt

thnx, ikzal een skijken of ik deze manier kan gebruiken, anders doe ik het op een iets andere manier(stukje nog niet gelezen).
[edit]
denk toch dat ik mijn manier ga gebruiken.

Wat er nu ook nog speelt is als je 'terug' gaat naar de vorige page. Dan is al je tekst weg dus moet ie dat opslaan. Alleen als je dan nog een sterug gaat moet ie het dus weer gaan opslaan of je moet er rekening mee houden dat de data van je laatste page nog niet is opgeslagen en de rest wel. Dis zou moeten lukken aangezien je die net uit de DB hebt getrokken...

[TheRebell]

Ik ben nu al even bezig met het maken ervan maak ik kom toch wat problemen tegen mbt het design

Een aantal namen moeten veranderen ahv of het de 1e pagina is of dat het een 2e of later pagina is. Ook moeten ahv deze de knoppen veranderen. Dat lukt nog wel...
Maar het moet dus ook mogelijk zijn om weer die befaamde vorige en volgende knoppen te gebruiken (om nog maar niet over de publish te spreken).
Hier kom ik niet echt vast te zitten maar de code wordt zo, voor mijn gevoel, een beetje rommelig. Komt misschien omdat er een hoop acties moeten gebeuren tijdens de uitvoer.

Hoe doet de pro dat nou vraag ik me dus nu af?! losse files, alles in array's opslaan, reggen in sessions of