Forum threads gelezen of ongelezen

Is het niet beter om een functie te maken?
http://sql-info.de/mysql/examples/create-function-examples.html

Dylanh schreef:

Is het niet beter om een functie te maken?
http://sql-info.de/mysql/examples/create-function-examples.html

Kan, maar dat is onoverzichtelijker. Bovendien is SQL niet echt een programmeertaal te noemen, en als laatste tegenargument: Waarom zou je een functie aanmaken als je die functie maar één keer gebruikt?
Het hele doel van Classes en functies is het hergebruiken van code.

Als je een functie maakt dan moet je alsnog de logica uitdenken, dus daar heb je werkelijk nul voordeel mee.

Rik schreef:

Eerdere citaten tonen

Dylanh schreef:

Is het niet beter om een functie te maken?

http://sql-info.de/mysql/examples/create-function-examples.html

Kan, maar dat is onoverzichtelijker. Bovendien is SQL niet echt een programmeertaal te noemen, en als laatste tegenargument: Waarom zou je een functie aanmaken als je die functie maar één keer gebruikt?
Het hele doel van Classes en functies is het hergebruiken van code.

Als het geen programmeertaal is waarom kan je dan logica maken in SQL (met functies dus)? SQL was toch sneller dan PHP? (Het is toch beter om COUNT() in SQL te gebruiken dan count() in PHP???

Hoebedoel je dat de functie maar 1 keer gebruikt wordt? Bij elke request moet er toch weer opnieuw worden gekeken of een topic gelezen is of zit ik er naast

Dylanh schreef:

Hoebedoel je dat de functie maar 1 keer gebruikt wordt? Bij elke request moet er toch weer opnieuw worden gekeken of een topic gelezen is of zit ik er naast

Ja, maar dat stuk code heb je maar 1 keer. Als je op elke aparte pagina een check doet of iemand ingelogd is gebruik je dat vaker omdat je meer dan 1 pagina hebt waar je dat stuk code gebruikt terwijl dat in dit geval niet zo is, je hebt geen 2 forumindex paginas

Dylanh schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylanh schreef:

Is het niet beter om een functie te maken?

http://sql-info.de/mysql/examples/create-function-examples.html

Kan, maar dat is onoverzichtelijker. Bovendien is SQL niet echt een programmeertaal te noemen, en als laatste tegenargument: Waarom zou je een functie aanmaken als je die functie maar één keer gebruikt?
Het hele doel van Classes en functies is het hergebruiken van code.

Als het geen programmeertaal is waarom kan je dan logica maken in SQL (met functies dus)? SQL was toch sneller dan PHP? (Het is toch beter om COUNT() in SQL te gebruiken dan count() in PHP???

Hoebedoel je dat de functie maar 1 keer gebruikt wordt? Bij elke request moet er toch weer opnieuw worden gekeken of een topic gelezen is of zit ik er naast

Ja, sommige functies (standaard SQL functies) zijn inderdaad sneller te doen in MySQL omdat die functies geoptimaliseerd zijn.
En op elke pageview gebruik je dat stukje logica, met die code maar één keer. Het hele idee achter functies (zeker in OOP) is dat je meerdere keren per pageview dezelfde code kan gebruiken. Het kan dus zijn dat je meerdere malen wil ophalen wat de rechten van een gebruiker zijn. Dan is het handiger om dat in een functie te stoppen.

Oke. Dus in SQL is dat anders in PHP. Want stel je wil kijken of de gebruiker het goede wachtwoord heeft om in te loggen. Die functie gebruik je maar 1 keer. Maar die functie is wel gewoon in OOP gescript?

Als ik het dus goed begrijp; in PHP OOP kan je wel een functie maken die je maar 1 keer gebruikt maar in SQL kan je beter geen functie aanmaken om iets maar 1 keer te gebruiken.

Maar ik kan mij iets herinneren dat ik een vraag stelde op Stackoverflow en dat iemand met het antwoord kwam om een functie maken. Straks even opzoeken.

Dylanh schreef:

Oke. Dus in SQL is dat anders in PHP. Want stel je wil kijken of de gebruiker het goede wachtwoord heeft om in te loggen. Die functie gebruik je maar 1 keer. Maar die functie is wel gewoon in OOP gescript?

Als ik het dus goed begrijp; in PHP OOP kan je wel een functie maken die je maar 1 keer gebruikt maar in SQL kan je beter geen functie aanmaken om iets maar 1 keer te gebruiken.

Maar ik kan mij iets herinneren dat ik een vraag stelde op Stackoverflow en dat iemand met het antwoord kwam om een functie maken. Straks even opzoeken.

Nee, in beide gevallen kan je een functie gebruiken. Het voordeel van PHP is echter dat je het bij de juiste classen en daarmee de juiste objecten onder kan brengen. In normale SQL kan dit niet. in PL/SQL daarintegen kan je packages aanmaken. Dán kan het weer wel, en zou het wellicht overzichtelijker kunnen werken.

Functies in MySQL (Procedures in PL/SQL) hebben wel een ander voordeel: Het maakt niet uit welke taal je gebruikt (of het nu webbased is of een applicatie op je PC), ze werken allemaal met dezelfde returnwaardes vanuit de SQL, zonder invloeden van de programmeertaal.

Sevvlor schreef:

Eerdere citaten tonen

Shahiem schreef:

Het is mij wel een keer gelukt om het te maken, maar geloof mij het is toch wel aardig pittig met al die queries en shizzle. Daar ben je nog wel even mee bezig.

Ik vond het persoonlijk meevallen . Het was alleen een gigantische query.??

toevoeging op 9 december 2014, 0007:

Eerdere citaten tonen

Joeryy schreef:

Ik ben al blij dat ik deze query heb kunnen maken , ben totaal geen held als het om SQL gaat.

SELECT p.datetime AS last_post_thread, r.datetime AS last_visit FROM forum_threads t, forum_posts p, forum_threads_read r WHERE t.id = :thread_id AND (r.datetime > t.datetime OR r.datetime > p.datetime) AND r.user_id = :user_id ORDER BY r.datetime DESC LIMIT 1

Persoonlijk ben ik geen voorstander van tabelnamen in het meervoud. Ver verneukt ORM en bij complexere queries is de naamgeving schijt irritant

Ja, true. Ik heb ook wel een paar momenten gehad waarbij ik echt had moeten nadenken hoe ik dat zou moeten doen.

Dylanh schreef:

Oke. Dus in SQL is dat anders in PHP. Want stel je wil kijken of de gebruiker het goede wachtwoord heeft om in te loggen. Die functie gebruik je maar 1 keer. Maar die functie is wel gewoon in OOP gescript?

Als ik het dus goed begrijp; in PHP OOP kan je wel een functie maken die je maar 1 keer gebruikt maar in SQL kan je beter geen functie aanmaken om iets maar 1 keer te gebruiken.

Maar ik kan mij iets herinneren dat ik een vraag stelde op Stackoverflow en dat iemand met het antwoord kwam om een functie maken. Straks even opzoeken.

Codeblok (voorbeeld.php):

1
2
3
4
5
6
7
8
9
10
11
12

DELIMITER $$
CREATE PROCEDURE insert_or_update(IN p_prev_token varchar(255), IN p_token varchar(255))
BEGIN
IF EXISTS( SELECT 1 FROM sessions WHERE token = p_prev_token ) THEN
UPDATE sessions SET token = p_token, expire = NOW() + INTERVAL 1 HOUR)
WHERE token = p_prev_token;
ELSE
INSERT INTO sessions(token, cookie, expire)
VALUES(p_token, , NOW() + INTERVAL 1 HOUR));
END IF;
END $$
DELIMITER ;

Was een procedure. Laat maar

Oke ik heb nog een vraag en dat is voorlopig de laatste.

Ik heb nu een query om de laatste post op te halen per category (Als voorbeeld 1), is deze query niet super traag bij een hoog aantal threads en posts?

Query:

SELECT p.* FROM forum_posts p LEFT JOIN (SELECT id FROM forum_threads WHERE category_id =1) t ON p.id = t.id ORDER BY p.datetime DESC LIMIT 1

Joeryy schreef:

Oke ik heb nog een vraag en dat is voorlopig de laatste.

Ik heb nu een query om de laatste post op te halen per category (Als voorbeeld 1), is deze query niet super traag bij een hoog aantal threads en posts?

Query:

SELECT p.* FROM forum_posts p LEFT JOIN (SELECT id FROM forum_threads WHERE category_id =1) t ON p.id = t.id ORDER BY p.datetime DESC LIMIT 1

Maak een testcase aan, vul je database met verschillende data (die wel representatief is voor de data die je gaat gebruiken) en kijk of het sloom is. Zoja, doe een DESCRIBE op je query om te kijken waar wel en geen indices gebruikt worden, en plaats waar nodig is extra indices of optimaliseer je query. Zolang het niet kapot is hoeft het niet gefixed te worden.

Rik schreef:

Eerdere citaten tonen

Joeryy schreef:

Oke ik heb nog een vraag en dat is voorlopig de laatste.

Ik heb nu een query om de laatste post op te halen per category (Als voorbeeld 1), is deze query niet super traag bij een hoog aantal threads en posts?

Query:

SELECT p.* FROM forum_posts p LEFT JOIN (SELECT id FROM forum_threads WHERE category_id =1) t ON p.id = t.id ORDER BY p.datetime DESC LIMIT 1

Maak een testcase aan, vul je database met verschillende data (die wel representatief is voor de data die je gaat gebruiken) en kijk of het sloom is. Zoja, doe een DESCRIBE op je query om te kijken waar wel en geen indices gebruikt worden, en plaats waar nodig is extra indices of optimaliseer je query. Zolang het niet kapot is hoeft het niet gefixed te worden.

Overigens is het waarschijnlijk beter om je categorie een lastPostID te geven, dan hoef je alleen maar op dat ID te zoeken en niet nog eens dat ID gaan zoeken

Luukvdo schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Joeryy schreef:

Oke ik heb nog een vraag en dat is voorlopig de laatste.

Ik heb nu een query om de laatste post op te halen per category (Als voorbeeld 1), is deze query niet super traag bij een hoog aantal threads en posts?

Query:

SELECT p.* FROM forum_posts p LEFT JOIN (SELECT id FROM forum_threads WHERE category_id =1) t ON p.id = t.id ORDER BY p.datetime DESC LIMIT 1

Maak een testcase aan, vul je database met verschillende data (die wel representatief is voor de data die je gaat gebruiken) en kijk of het sloom is. Zoja, doe een DESCRIBE op je query om te kijken waar wel en geen indices gebruikt worden, en plaats waar nodig is extra indices of optimaliseer je query. Zolang het niet kapot is hoeft het niet gefixed te worden.

Overigens is het waarschijnlijk beter om je categorie een lastPostID te geven, dan hoef je alleen maar op dat ID te zoeken en niet nog eens dat ID gaan zoeken

Dan zit je echter wel met het verwijderen van een post weer te zoeken naar de goede ID die je vervolgens weer moet updaten. Dat is ook niet ideaal.

Rik schreef:

Eerdere citaten tonen

Luukvdo schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Joeryy schreef:

Oke ik heb nog een vraag en dat is voorlopig de laatste.

Ik heb nu een query om de laatste post op te halen per category (Als voorbeeld 1), is deze query niet super traag bij een hoog aantal threads en posts?

Query:

SELECT p.* FROM forum_posts p LEFT JOIN (SELECT id FROM forum_threads WHERE category_id =1) t ON p.id = t.id ORDER BY p.datetime DESC LIMIT 1

Maak een testcase aan, vul je database met verschillende data (die wel representatief is voor de data die je gaat gebruiken) en kijk of het sloom is. Zoja, doe een DESCRIBE op je query om te kijken waar wel en geen indices gebruikt worden, en plaats waar nodig is extra indices of optimaliseer je query. Zolang het niet kapot is hoeft het niet gefixed te worden.

Overigens is het waarschijnlijk beter om je categorie een lastPostID te geven, dan hoef je alleen maar op dat ID te zoeken en niet nog eens dat ID gaan zoeken

Dan zit je echter wel met het verwijderen van een post weer te zoeken naar de goede ID die je vervolgens weer moet updaten. Dat is ook niet ideaal.

Gezien je bij een forum veel vaker gegevens ophaalt dan in de database stopt is dat wel te verantwoorden