[sql] forum query's verbeteren.

[Verwijderd]

Hiya, ik ben op dit moment bezig van meerdere query's 1 te maken omdat ik heb gehoord/gelezen dat meerdere query's een forum sloom maken en dat je dus beter van meerdere 1 kan maken..

nou dat is niet helemaal mogelijk maar voor me index ben ik nu bezig om van 5 query's er 2 te maken alleen zit ik met het volgende probleem

query

code:

SELECT 
galleryforumfora.*, 
count(galleryforumtopic.id) as topiccount,
count(galleryforumpost.id) as postcount
FROM galleryforumfora 
LEFT JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id 
LEFT JOIN galleryforumtopic ON
galleryforumtopic.id = galleryforumfora.id WHERE galleryforumfora.index_id='1'
GROUP by galleryforumfora.id 
ORDER BY fsort LIMIT 0, 30

krijg ik de 'volgede' output.

code:

id  index_id  name  subname  subject  lastpost  fsort  right_reply  right_read  right_start  right_banned  right_admin  topiccount  postcount  
1 1 ChitChat CC ChitChat about everything 2002-07-12 22:07:21 1 0 0 0 6661 10001 125 125 
2 1 Latest News LN Chat about the latestnews 2002-06-26 10:06:42 2 0 0 10 6662 10002 7 7

oftewel de postcount is gelijk aan de topiccount, dat moet ik oplossen want dat koste alleen al 2 apparte query's ..

en is het mogelijk om met de rechten tabel van dusty die ik heb geimplementeerd (user_id, right_id) een soortement leftjoin te maken ook in deze query zodat ik gelijk alle 'admins' van een bepaald forum ook gelijk uitlees?

en graag geen slotje dit keer, want ik doe mijn best en probeer echt heel veel

code:

SELECT
        galleryforumfora.*,
        count(galleryforumpost.id) as postcount
        FROM galleryforumfora
        LEFT JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id
        WHERE galleryforumfora.index_id='" . $cat_list['id'] . "'
        GROUP by galleryforumfora.id
        ORDER BY fsort";

deze query werkt trouwens, en is de voorloper van de gene die boven staat mja die heeft nog geen topic count. dus weer een query extra

[robjanssen]

Waarom gebruik je eigenlijk een LEFT JOIN?

Misschien dat het zo werkt?

code:

SELECT galleryforumfora.*,
COUNT(galleryforumpost.id) AS postcount,
(SELECT COUNT(galleryfourmtopic.id) FROM galleryforumtopic WHERE galleryforumfora.id = galleryforumtopic.forum_id) AS topiccount
FROM galleryforumfora
INNER JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id
WHERE galleryforumfora.index_id='" . $cat_list['id'] . "'
GROUP by galleryforumfora.id
ORDER BY fsort";

[Stilgar]

Misschien dat dit werkt?

code:

SELECT 
galleryforumfora.*, 
count(DISTINCT galleryforumtopic.id) as topiccount,
count(DISTINCT galleryforumpost.id) as postcount
FROM galleryforumfora 
LEFT JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id 
LEFT JOIN galleryforumtopic ON
galleryforumtopic.id = galleryforumfora.id WHERE galleryforumfora.index_id='1'
GROUP by galleryforumfora.id 
ORDER BY fsort LIMIT 0, 30

(dus keyword DISTINCT toevoegen in je counts)

[Verwijderd]

Op zaterdag 13 juli 2002 13:33 schreef robjanssen het volgende:
Waarom gebruik je eigenlijk een LEFT JOIN?

Misschien dat het zo werkt?

code:

SELECT galleryforumfora.*,
COUNT(galleryforumpost.id) AS postcount,
(SELECT COUNT(galleryfourmtopic.id) FROM galleryforumtopic WHERE galleryforumfora.id = galleryforumtopic.forum_id) AS topiccount
FROM galleryforumfora
INNER JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id
WHERE galleryforumfora.index_id='" . $cat_list['id'] . "'
GROUP by galleryforumfora.id
ORDER BY fsort";

dit is niet mogelijk in mysql in combinatie met php

Op zaterdag 13 juli 2002 14:03 schreef Stilgar het volgende:
Misschien dat dit werkt?

code:

SELECT 
galleryforumfora.*, 
count(DISTINCT galleryforumtopic.id) as topiccount,
count(DISTINCT galleryforumpost.id) as postcount
FROM galleryforumfora 
LEFT JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id 
LEFT JOIN galleryforumtopic ON
galleryforumtopic.id = galleryforumfora.id WHERE galleryforumfora.index_id='1'
GROUP by galleryforumfora.id 
ORDER BY fsort LIMIT 0, 30

(dus keyword DISTINCT toevoegen in je counts)

deze werkt echt wel veel beter alleen kloppen de hoeveelheid topics niet

code:

id  index_id  name  subname  subject  lastpost  fsort  right_reply  right_read  right_start  right_banned  right_admin  topiccount  postcount  
1 1 ChitChat CC ChitChat about everything 2002-07-12 22:07:21 1 0 0 0 6661 10001 1 125 
2 1 Latest News LN Chat about the latestnews 2002-06-26 10:06:42 2 0 0 10 6662 10002 1 7

beiden bevatten meerdere topics

Ik gebruik trouwens inner joins omdat ik dat eerder heb gebruikt en omdat ik verder weinig mysql kennis heb

[whoami]

Op zaterdag 13 juli 2002 14:53 schreef xtentic het volgende:


Ik gebruik trouwens inner joins omdat ik dat eerder heb gebruikt en omdat ik verder weinig mysql kennis heb

Misschien een tip:
eerst even SQL leren en dan gaan kijken hoe je kunt optimaliseren?

[Verwijderd]

Op zaterdag 13 juli 2002 14:58 schreef whoami het volgende:

[..]

Misschien een tip:
eerst even SQL leren en dan gaan kijken hoe je kunt optimaliseren?

Ok, ik heb al vaak die mysql.com page doorgelezen en veel begrijp ik er gewoon niet van en heb veel geprobeerd te lezen, leren en op te nemen van andere vragen hier op het forum en daar moet ik het dus mee doen.. verder ga ik me statement niet verdedigen

[ACM]

Op zaterdag 13 juli 2002 14:59 schreef xtentic het volgende:
Ok, ik heb al vaak die mysql.com page doorgelezen en veel begrijp ik er gewoon niet van en heb veel geprobeerd te lezen, leren en op te nemen van andere vragen hier op het forum en daar moet ik het dus mee doen.. verder ga ik me statement niet verdedigen

Op mysql.com staan ook niet echt tutorials die SQL uitleggen of wel?
Maar voornamelijk lappen tekst die de werking van SQL binnen MySQL, het beheren ervan, etc uitleggen.

Kortom, zoek dan naar begrijpelijke teksten ipv domweg alleen bij mysql.com te blijven hangen

[mbravenboer]

xtentic: en daar moet ik het dus mee doen..

Daar hoef je het helemaal niet mee te doen: koop gewoon een goed en leuk boek over database en SQL en neem dat eens goed door. Je zult er in tegenstelling tot wat je wellicht verwacht veel plezier van hebben .

[whoami]

http://www.sqlcourse2.com/

[Verwijderd]

Op zaterdag 13 juli 2002 15:01 schreef ACM het volgende:
Op mysql.com staan ook niet echt tutorials die SQL uitleggen of wel?
Maar voornamelijk lappen tekst die de werking van SQL binnen MySQL, het beheren ervan, etc uitleggen.

Kortom, zoek dan naar begrijpelijke teksten ipv domweg alleen bij mysql.com te blijven hangen

was maar een example, ik heb natuurlijk meerdere sites bekeken en van a-z doorgelezen maar heb wel gemerkt dat mijn engels op dat gebied niet zo sterk is

Op zaterdag 13 juli 2002 15:01 schreef mbravenboer het volgende:
Daar hoef je het helemaal niet mee te doen: koop gewoon een goed en leuk boek over database en SQL en neem dat eens goed door. Je zult er in tegenstelling tot wat je wellicht verwacht veel plezier van hebben .

Als ik op dit moment genoeg $$ had had ik idd al zo'n mooi boek gehaald

Op zaterdag 13 juli 2002 15:01 schreef whoami het volgende:
http://www.sqlcourse2.com/

Ga het bekijken, en hoop op wat meer resultaten dan mysql.com

-edit
die site laat niets zien m.b.t inner/left en joins..

[mbravenboer]

xtentic: Als ik op dit moment genoeg $$ had had ik idd al zo'n mooi boek gehaald

Bij de slegte hebben ze veel tweedehands studieboeken die ongeveer even duur zijn als een cd'tje. Je maakt mij niet wijs dat je geen geld hebt om een cd'tje te kopen .

[mbravenboer]

xtentic: die site laat niets zien m.b.t inner/left en joins..

Woei, jij bent snel... te snel.

Google vond snel en simpel bijvoorbeeld dit:
http://www.sql-guru.com/sql101/basicjoins.html

[Verwijderd]

Op zaterdag 13 juli 2002 15:08 schreef mbravenboer het volgende:
Bij de slegte hebben ze veel tweedehands studieboeken die ongeveer even duur zijn als een cd'tje. Je maakt mij niet wijs dat je geen geld hebt om een cd'tje te kopen .

Daar heb je dit keer ongelijk in, ik heb al ruim een half jaar geen cd's, kleding en andere expensive dingen zelf gekocht omdat me rekeningen stapel groter is dan me inkomsten

[Verwijderd]

Op zaterdag 13 juli 2002 15:12 schreef mbravenboer het volgende:

[..]

Woei, jij bent snel... te snel.

Google vond snel en simpel bijvoorbeeld dit:
http://www.sql-guru.com/sql101/basicjoins.html

Naja te snel zeg niettus, die site van mr. w bevatte idd geen inner joins enzo... maar ik ga deze direct uitspitten bedankt!

-edit

deze heb ik ook even gelezen, en ik denk dat ik dat gedeelte al wel door heb maar daar staat jammer genoeg niets over dubbele inner joins mja dat maakt ook niet uit ik begrijp nu wel ff wat meer over inner, left en right en outer joins ...

[mbravenboer]

Deze is ook aardig:

http://www.swynk.com/friends/boyle/ansijoins.asp

[mbravenboer]

xtentic: maar ik ga deze direct uitspitten

Weet je hoe ik hem vond? +"inner join" +"left join". Pagina 1 of 2 volgens mij . Waarschijnlijk zit er nog veel meer bruikbaar materiaal tussen,

[Verwijderd]

Op zaterdag 13 juli 2002 15:14 schreef mbravenboer het volgende:
Deze is ook aardig:

http://www.swynk.com/friends/boyle/ansijoins.asp

deze heb ik ook ff doorgelezen maar begon een beetje te spiegelen voor me ogen... veel in mijn ogen on nodige informatie en vage query's die vorige had teminste iets waar ik zag dat dingen te maken hadden met andere, deze is volgens mij ook meer gericht op alleen sql en niet sql in combi met php...

-edit
nogmaals even doorgelezen. en snap er wat meer van maar blijft toch moeilijker dan die vorige url.

[Verwijderd]

Voor SQL vragen/problemen kijk ik altijd even op http://www.developersdex.com/sql/Default.asp. Hoop resources o.a. van de nieuwsgroepen.

En wellicht beantwoord SQL Guru Joe Celko je vraag wel. Dat is trouwens ook mijn boektip. Joe Celko, o.a. van SQL for Smarties. Beschrijft o.a. erg goed de problemen met "Relational Division".

[Verwijderd]

code:

SELECT 
galleryforumfora.*, 
count(DISTINCT galleryforumtopic.id) as topiccount,
count(DISTINCT galleryforumpost.id) as postcount
FROM galleryforumfora 
LEFT JOIN galleryforumtopic ON galleryforumfora.id = galleryforumtopic.forum_id 
LEFT JOIN galleryforumpost ON galleryforumfora.id = galleryforumpost.forum_id 
WHERE galleryforumfora.index_id='1'
GROUP by galleryforumfora.id 
ORDER BY fsort LIMIT 0, 30

deze werkt trouwens en verder bedankt, ik ga ook de andere tutors lezen en proberen nog meer te leren.

maar geeft ook errors
-edit lama... is alleen een PHPMYADMIN error

[Verwijderd]

trouwens is het mogelijk dat ik de vorige query met deze koppel?

code:

SELECT
        galleryforumrights.user_id,
        galleryforumrights.right_id,
        gallerymember.id,
        gallerymember.username
        FROM galleryforumrights
        LEFT JOIN gallerymember ON gallerymember.id = galleryforumrights.user_id
        WHERE galleryforumrights.right_id='$forumcode'

want deze query neemt nogal wat performace

[TheDane]

hmm, ik heb laatst nog gelezen dat meerdere simpele queries aanzienlijk sneller werken dan 1 query waarmee je alle data in 1 keer op moet halen


ik heb liever 3 queries ala :
"select bla from table where $where"
als 1 van jouw queries eigenlijk ...

[Verwijderd]

Op zaterdag 13 juli 2002 16:13 schreef TheDane het volgende:
hmm, ik heb laatst nog gelezen dat meerdere simpele queries aanzienlijk sneller werken dan 1 query waarmee je alle data in 1 keer op moet halen


ik heb liever 3 queries ala :
"select bla from table where $where"
als 1 van jouw queries eigenlijk ...

Dan hebben we het wel over ECHT ingewikkelde queries, en niet over simpele queries die gebruik maken van een paar joins hoor. Joins zijn immers een van de troeven van sql, dus je gebruiker die beter wel in één querie, maar je moet idd. niet overdrijven, maar dat is bij de queries in deze thread zeker niet het geval volgens mij

[TheDane]

Op zaterdag 13 juli 2002 16:18 schreef DiEana het volgende:

[..]

Dan hebben we het wel over ECHT ingewikkelde queries, en niet over simpele queries die gebruik maken van een paar joins hoor. Joins zijn immers een van de troeven van sql, dus je gebruiker die beter wel in één querie, maar je moet idd. niet overdrijven, maar dat is bij de queries in deze thread zeker niet het geval volgens mij

mja, ik reageerde eigenlijk alleen op de eerste zin van topicstarter .. vorige week had -ik geloof ACM- nog iets gezegd over 't gebruik van simpele queries en de voordelen ervan ipv complexe shit .. heb verder eigenlijk niet naar die queries gekeken

bovendien werk ik normaal gesproken met Oracle en daar heb je fijne optimizer hints

[Verwijderd]

maar zou het mogelijk zijn om die laatste query te combineren met die andere query zodat ik in 1x alle admins van een forum kan selecteren?

[Verwijderd]

Op zaterdag 13 juli 2002 16:59 schreef xtentic het volgende:
maar zou het mogelijk zijn om die laatste query te combineren met die andere query zodat ik in 1x alle admins van een forum kan selecteren?

Zolang je per resultaat een gelijk aantal rijtjes hebt, kan je in principe "alles" combineren... de vraag is alleen of je dat echt wil

Een dom voorbeeld:
Je haalt forumtopics neer, stel het zijn er bijvoorbeeld 30. Nu heb je op dat forum ook forumrechten. Nu kan je via een left join die forumrechten ook neerhalen, maar dan gebeurt dat wel 30 keer (per topic rij wordt het eraan geplakt = left join). Maar wil je dat? Ik denk het niet
Dus dan maak je toch "simpelweg" een tweede querie die 1 maal de forumrechten neerhaalt?

[Verwijderd]

Op zaterdag 13 juli 2002 17:04 schreef DiEana het volgende:

[..]

Zolang je per resultaat een gelijk aantal rijtjes hebt, kan je in principe "alles" combineren... de vraag is alleen of je dat echt wil

Een dom voorbeeld:
Je haalt forumtopics neer, stel het zijn er bijvoorbeeld 30. Nu heb je op dat forum ook forumrechten. Nu kan je via een left join die forumrechten ook neerhalen, maar dan gebeurt dat wel 30 keer (per topic rij wordt het eraan geplakt = left join). Maar wil je dat? Ik denk het niet
Dus dan maak je toch "simpelweg" een tweede querie die 1 maal de forumrechten neerhaalt?

Ok dat is idd handiger, maar er zijn meerdere admins per forum en die wil ik tegelijketijd uitlezen, dat doe ik nu dmv de volgende functie..

code:

function getAdmins($forumcode) {
    $sql = "SELECT
        galleryforumrights.user_id,
        galleryforumrights.right_id,
        gallerymember.id,
        gallerymember.username
        FROM galleryforumrights
        LEFT JOIN gallerymember ON gallerymember.id = galleryforumrights.user_id
        WHERE galleryforumrights.right_id='$forumcode'";
    $query = mysql_query($sql);
    $items = mysql_num_rows($query);
    
    $add = "";
    if ($items > 1) {
      $add = ", ";
    }
    
    for ($z = 0; $z < $items-1 ; $z++) {
      $list = mysql_fetch_assoc($query);
      $names .= $list['username'] . $add;
    }
    $list = mysql_fetch_assoc($query);
    $names .= $list['username'];
    
    return $names;
}

op zich werkt dat ook best hoor maar tja het kan leuker

[ACM]

Op zaterdag 13 juli 2002 16:35 schreef TheDane het volgende:
mja, ik reageerde eigenlijk alleen op de eerste zin van topicstarter .. vorige week had -ik geloof ACM- nog iets gezegd over 't gebruik van simpele queries en de voordelen ervan ipv complexe shit .. heb verder eigenlijk niet naar die queries gekeken

Die queries waren niet zo complex, maar hadden niets met elkaar te maken enzo en daardoor werden de deelqueries veel minder complex
Jouw opmerking past alleen in de goede contexten.

Trouwens, xtentic, als je echt snelheid wil winnen, moet je afstappen van het continue opnieuw tellen...
Sla de telling op bij de forums/topics en haal bij het tonen van lijsten alleen die waarde op.
Bij elke topic/reply insert/delete moet je die tellingen dan weer bijwerken natuurlijk.

[edit]
Ging om: [topic=547785]

[Verwijderd]

Op zaterdag 13 juli 2002 17:12 schreef ACM het volgende:

[..]

Die queries waren niet zo complex, maar hadden niets met elkaar te maken enzo en daardoor werden de deelqueries veel minder complex
Jouw opmerking past alleen in de goede contexten.

Trouwens, xtentic, als je echt snelheid wil winnen, moet je afstappen van het continue opnieuw tellen...
Sla de telling op bij de forums/topics en haal bij het tonen van lijsten alleen die waarde op.
Bij elke topic/reply insert/delete moet je die tellingen dan weer bijwerken natuurlijk.

[edit]
Ging om: [topic=547785]

dus het is handiger om bij de tabellen een 'count' te zetten van alle 'topics' en postings?, maar dat maakt toch ook je forum weer slomer qua updaten ed.?

Al update ik nu ook voor iedere post de last post enzo.. dus moet het wel te doen zijn

[Verwijderd]

Op zaterdag 13 juli 2002 17:34 schreef xtentic het volgende:

[..]

dus het is handiger om bij de tabellen een 'count' te zetten van alle 'topics' en postings?, maar dat maakt toch ook je forum weer slomer qua updaten ed.?

Al update ik nu ook voor iedere post de last post enzo.. dus moet het wel te doen zijn

Het inserten is slower ja: je moet 1 of meerdere "extra" inserts doen + de index van die "extra" tabellen moeten eventueel aangepast worden.

Een domme vraag misschien, maar wat ben je met een "lijst" van alle admins? Zolang je maar weet wat de huidige(!) gebruiker kan en niet kan, is het toch voldoende?

[TheDane]

Op zaterdag 13 juli 2002 17:12 schreef ACM het volgende:

[..]

Die queries waren niet zo complex, maar hadden niets met elkaar te maken enzo en daardoor werden de deelqueries veel minder complex
Jouw opmerking past alleen in de goede contexten.

Trouwens, xtentic, als je echt snelheid wil winnen, moet je afstappen van het continue opnieuw tellen...
Sla de telling op bij de forums/topics en haal bij het tonen van lijsten alleen die waarde op.
Bij elke topic/reply insert/delete moet je die tellingen dan weer bijwerken natuurlijk.

[edit]
Ging om: [topic=547785]

sorry hoor
maargoed, like i said, ik reageerde vooral en alleen op de eerste zin van topicstarter

en verder is redundante informatie (inderdaad) helemaal niet zo eng/erg als 't lijkt. als je database goed in elkaar zit, levert 't vaak meer voordelen op dan nadelen.

Iedereen lijkt er alleen altijd zo bang voor ...

[bartvb]

Redundant info is bij een forum database bijna niet te voorkomen als je alles een beetje snel wil houden..

Houd verder erg goed in de gaten dat er tegenover iedere update een stuk of 10 (of meer) reads staan. Het is dus _veel_ belangrijker om je index, forum- en topicviews snel te krijgen dan het posten.. En zo'n 'UPDATE topics SET views=views+1 WHERE id = 1234' kost echt bijna geen tijd, zie ook daarvoor de mysql manual trouwens.

Kijk welke dingen er lang duren (ophalen counts van views/posts, lijst met moderators, etc) en zet die dingen ergens weg.

[mbravenboer]

Redundante informatie is prima, maar naar mijn mening liever niet in de tabellen zelf en ook zeker niet zelf deze redundante informatie bijhouden. Er zijn veel mogelijkheden:

Als je een wat completer DBMS gebruikt kan je kiezen voor het geclusterd opslaan van tabellen, waardoor je zonder redundantie ook nog een heel grote performance winst kan boeken.

Serialized views kunnen ook een heleboel helpen. Met name zou ik de topic count liever in een serialized view opslaan, die door het DBMS zelf bijgehouden kan worden.

Ook kunnen goede indexen (bijvoorbeeld een hash index) nog behoorlijk wat helpen. Als je een hash index op het forum van een topic maakt, kan een goed geoptimaliseerd DBMS in no-time een count doen over deze topics.

[ACM]

Op zaterdag 13 juli 2002 20:27 schreef mbravenboer het volgende:
Redundante informatie is prima, maar naar mijn mening liever niet in de tabellen zelf en ook zeker niet zelf deze redundante informatie bijhouden. Er zijn veel mogelijkheden:

Voor een simpele applicatie als een forum is dat denk ik nog niet zo heel erg
Officieel is het wel netter, maar om nou voor die 3 velden aparte tabellen aan te leggen?
Worden je joins alleen maar weer groter van en je kans op missende entries is bij mysql dan helemaal eng groot (geen foreign key verplichtingen, geen triggers etc).

Om maar een voorbeeld te geven, de preferences en members worden in aparte tabellen opgeslagen hier op GoT. Er zijn zo'n 500 members die _geen_ preferences hebben...

So far for relationele integriteit in mysql...

Serialized views kunnen ook een heleboel helpen. Met name zou ik de topic count liever in een serialized view opslaan, die door het DBMS zelf bijgehouden kan worden.

Whehehehe, ik wist dat je die view variant weer zou noemen

Welk DBMS gebruik jij?

Ook kunnen goede indexen (bijvoorbeeld een hash index) nog behoorlijk wat helpen. Als je een hash index op het forum van een topic maakt, kan een goed geoptimaliseerd DBMS in no-time een count doen over deze topics.

Een hash index? Ik zie overal bij de postgresql dat ze hash indices liever niet zo heel zinvol vinden?

Because of the limited utility of hash indexes, a B-tree index should generally be preferred over a hash index. We do not have sufficient evidence that hash indexes are actually faster than B-trees even for = comparisons. Moreover, hash indexes require coarser locks; see Section 9.7.

In: http://www.postgresql.org/idocs/index.php?indexes-types.html

[mbravenboer]

ACM: Voor een simpele applicatie als een forum is dat denk ik nog niet zo heel erg

Ach, ik overdrijf graag en daarnaast is het meeste werk wat hier gebeurt toch educatief van aard. Ten behoeve van educatie kan je niet ver genoeg overdrijven .

Whehehehe, ik wist dat je die view variant weer zou noemen

Voorspelbaar ben ik he? .

Welk DBMS gebruik jij?

Diverse, voor commercieel werk het meeste met Postgres en licht-gewicht Java databases. Helaas kom ik niet echt toe aan geavanceerder werk omdat het simpelweg niet m'n directe vakgebied is en ik er dus ook minder mee bezig ben. Ik ben op dit moment echter intensief met een query-compiler/optimizer bezig en daarom heb ik wat meer interesse gekregen in al deze toestanden .

Een hash index? Ik zie overal bij de postgresql dat ze hash indices liever niet zo heel zinvol vinden?

Mwah, zodra je ook maar iets met een range-query gaat doet moet je natuurlijk een B-tree hebben, maar ik zou niet weten waarom je geen hash-index zou kunnen gebruiken voor simpele equivalenties. Juist voor bijvoorbeeld de topics van forum lijkt mij dat helemaal geen slecht idee. Een B-Tree is natuurlijk ook een fantastisch mechanisme, maar het onderhouden daarvan is toch een stukje complexer en het biedt in ieder geval geen betere performance voor equivalentie (tenzij ik het heel erg mis heb....)

Ik kan me best voorstellen dat ze B-trees adviseren omdat je in veel andere gevallen toch ook wel met een range zult werken en ze niet echt een groot nadeel hebben tov van hash-tables voor simpele equivalentie.

Overigens wilde ik eerst ook een B-tree erbij willen noemen als voorbeeld, had ik beter dus maar wel kunnen doen .

[ACM]

Op zaterdag 13 juli 2002 22:44 schreef mbravenboer het volgende:
Diverse, voor commercieel werk het meeste met Postgres en licht-gewicht Java databases. Helaas kom ik niet echt toe aan geavanceerder werk omdat het simpelweg niet m'n directe vakgebied is en ik er dus ook minder mee bezig ben. Ik ben op dit moment echter intensief met een query-compiler/optimizer bezig en daarom heb ik wat meer interesse gekregen in al deze toestanden .

Ahzo, maar postgres kent geen gekke view's toch? Alleen de 'query rewritende' variant, toch?

Cluster zag ik toevallig net staan toen ik wilde weten wat je precies bedoelde, helaas wordt die niet automagisch bijgewerkt.
De laatste tijd zie ik steeds weer dingen in postgres waarvan ik dacht dat het er niet in zou zitten (of niet wist dat het bestond )

Juist voor bijvoorbeeld de topics van forum lijkt mij dat helemaal geen slecht idee.

Ja, daar zou je wel es gelijk in kunnen hebben.
De meeste queries zijn natuurlijk gewoon 'select ... from messages where topicid=X' etc.
Als ik er aan denk zal ik ze es tegen elkaar vergelijken

Overigens wilde ik eerst ook een B-tree erbij willen noemen als voorbeeld, had ik beter dus maar wel kunnen doen .

Nu is er meer discussie

[Verwijderd]

En wat heeft de topicstarter nu aan deze "overkill" (in deze situatie dus) methoden?

[ACM]

Op zaterdag 13 juli 2002 22:57 schreef DiEana het volgende:
En wat heeft de topicstarter nu aan deze "overkill" (in deze situatie dus) methoden?

Niks, maar das een trekje van mij en mbravenboer, we willen nog wel es 'doorslaan'.
En zolang de topicstarter niet reageert kunnen we lekker verder kletsen

[mbravenboer]

ACM: Ahzo, maar postgres kent geen gekke view's toch? Alleen de 'query rewritende' variant, toch?

Nee niet echt inderdaad... Dan kom je toch wel bij Oracle of MS SQL Server uit....

Hier hadden we het er ook al over:
[topic=524140/1/25]

Nu is er meer discussie

Das waar .

[mbravenboer]

DiEana: En wat heeft de topicstarter nu aan deze "overkill" (in deze situatie dus) methoden?

Als je een database kunt gebruiken die deze features support hoeft het helemaal geen overkill te zijn denk ik .

Verder is het denk ik toch zo dat iedereen hier fora maakt om iets te leren. Er zijn er toch maar weinig die een forum alleen maar maken om het resultaat. Het kan helemaal geen kwaad om nog meer kennis op te doen van database systemen en SQL en dus interessante features te gebruiken .

[ACM]

Op zaterdag 13 juli 2002 23:10 schreef mbravenboer het volgende:
Nee niet echt inderdaad... Dan kom je toch wel bij Oracle of MS SQL Server uit....

Hier hadden we het er ook al over:
[topic=524140/1/25]

Owja, dat topic
Wel jammer dat het niet in postgres zit en er voorlopig niet in komt.

Owja, vindt je dan vast interessant:

in postgresql.hackers zag ik:
Hello,
>
> I somehow feel that I do not know anymore what are the current expectations
> for a release date for 7.3.


Beta freeze September 1, final release October/November, is my guess.

Das waar .

Hehehe,

[EgoH]

Op zaterdag 13 juli 2002 15:01 schreef mbravenboer het volgende:

[..]

Daar hoef je het helemaal niet mee te doen: koop gewoon een goed en leuk boek over database en SQL en neem dat eens goed door. Je zult er in tegenstelling tot wat je wellicht verwacht veel plezier van hebben .

Weet jij misschien een goed boek voor beginnend sql?
Snap normale querys wel, maar ingewikkelde goed uitgelegd zou erg mooi zijn .

[mbravenboer]

ACM: Wel jammer dat het niet in postgres zit en er voorlopig niet in komt.

Ik weet absoluut niets over de plannen voor de toekomst, maar het is inderdaad wel jammer. Met name omdat de andere reuzen het wel ondersteunen en er (terecht) erg trots op zijn .

Owja, vindt je dan vast interessant

Eerlijk gezegd upgrade ik niet zo vaak . Alleen als er echt een feature is die ik voor m'n toestanden nodig heb. Ik ben helaas veel te weinig praktisch ermee bezig omdat ik er simpelweg geen concreet werk voor heb en ik veel meer andere dingen te doen heb om er (of bijv met Oracle) zomaar mee te gaan 'spelen'.

Wel merkwaardig op zich dat ik ondertussen behoorlijk wat weet van query optimalisatie en daar ook praktisch mee gewerkt heb (de over het algemeen sterk vereenvoudigde weergave in een boek lezen is 1, implementeren is 3 ), maar eigenlijk maar weinig praktisch met database systemen werk.

[mbravenboer]

EgoH: Weet jij misschien een goed boek voor beginnend sql? Snap normale querys wel, maar ingewikkelde goed uitgelegd zou erg mooi zijn .

Ik heb hier een aantal boeken, het hangt nogal van je behoefte af wat je wilt:

A Guide to the SQL Standard, C.J. Date: perfecte reference voor SQL als je echt de feiten of de details van de taal moet weten, maar het is geen SQL handleiding of introductie in databases.

A First Course in Database Systems: wordt veel gebruikt als les-boek op universiteiten volgens mij en is een goede een begrijpelijke introductie in database systemen, SQL en een stukje theorie erachter waar je toch eigenlijk ook kennis van moet hebben om echt te begrijpen waar het over gaat (relationele algebra).

Verder heb ik nog Database System Concepts. Aardig boek, goed verhaal over relationele algebra, maar ik vond het SQL stuk een stuk minder. Ik zou dan eerder de tweede die ik noemde kiezen.

Als je alles over indexen en andere interne aangelegenheden wilt weten moet je een boek hebben over database systeem architectuur, maar als ik je goed begrijp is dat niet direct wat je wilt...

[EgoH]

Op zaterdag 13 juli 2002 23:26 schreef mbravenboer het volgende:

[..]

Ik heb hier een aantal boeken, het hangt nogal van je behoefte af wat je wilt:

A Guide to the SQL Standard, C.J. Date: perfecte reference voor SQL als je echt de feiten of de details van de taal moet weten, maar het is geen SQL handleiding of introductie in databases.

A First Course in Database Systems: wordt veel gebruikt als les-boek op universiteiten volgens mij en is een goede een begrijpelijke introductie in database systemen, SQL en een stukje theorie erachter waar je toch eigenlijk ook kennis van moet hebben om echt te begrijpen waar het over gaat (relationele algebra).

Verder heb ik nog Database System Concepts. Aardig boek, goed verhaal over relationele algebra, maar ik vond het SQL stuk een stuk minder. Ik zou dan eerder de tweede die ik noemde kiezen.

Als je alles over indexen en andere interne aangelegenheden wilt weten moet je een boek hebben over database systeem architectuur, maar als ik je goed begrijp is dat niet direct wat je wilt...

Nou ik zocht meer een boek (met bijv voorbeelden) over geavanceerde querys:
Hoe je beste data uit verschillende tabellen op kan halen met welke indexen en in welke situaties je bijvoorbeeld wel aparte querys moet gebruiken.
(uitleg waarom dat zo is, zou dan ook handig zijn)
Allemaal van dat soort weetjes op het maximale uit je database te halen eigenlijk.

[Verwijderd]

Op zaterdag 13 juli 2002 23:12 schreef mbravenboer het volgende:

[..]

Verder is het denk ik toch zo dat iedereen hier fora maakt om iets te leren. Er zijn er toch maar weinig die een forum alleen maar maken om het resultaat. Het kan helemaal geen kwaad om nog meer kennis op te doen van database systemen en SQL en dus interessante features te gebruiken .

Akkoord, ik 'gebruik' het ook vooral om te leren.. maar het ik zou het vervelend vinden als er ineens gepraat zou worden over 'moeilijke' onderwerpen, die totaal geen bijdrage hebben aan het huidig gegeven

Maar verder blijft het interessant, dus ga gerust door

[ACM]

Op zaterdag 13 juli 2002 23:20 schreef mbravenboer het volgende:
Eerlijk gezegd upgrade ik niet zo vaak . Alleen als er echt een feature is die ik voor m'n toestanden nodig heb. Ik ben helaas veel te weinig praktisch ermee bezig omdat ik er simpelweg geen concreet werk voor heb en ik veel meer andere dingen te doen heb om er (of bijv met Oracle) zomaar mee te gaan 'spelen'.

Ah, ik heb ook nog niet echt hoogte van wat er nou in komt, maar aangezien het bij elke 'major' release over het algemeen een stuk beter wordt...
Point in time recovery is er iig een van.
Daarnaast worden de system catalogs flink onder handen genomen meen ik.

Ow, ik kijk net de TODO door van postgresql en zie dit staan:

* -Test hash index performance and discourage usage

Dat 'komt' ook in 7.3

[mbravenboer]

EgoH: Nou ik zocht meer een boek (met bijv voorbeelden) over geavanceerde querys

Ik ken geen boek met zo'n aanpak, maar zoveel boeken heb ik nu ook weer niet gezien dus misschien dat iemand anders nog suggesties heeft . Verder biedt het middelste boek wat ik noemde trouwens ook al best wel een goede basis omdat veel toestanden met geavanceerde queries toch echt gebaseerd zijn op de theorie.

Als je echt ver wilt gaan kan je ook nog een boek over database systeem architectuur overwegen omdat daar erg veel in zal staan over de kosten van operaties en wanneer welke index gebruikt moet worden enz enz... Hiervoor heb je echter wel een goede basiskennis nodig en voldoet een beetje SQL kennis echt niet (kan uiteraard niet inschatten hoe dat bij jou zit ).

ACM: Ow, ik kijk net de TODO door van postgresql en zie dit staan

Hum, toepasselijker kan niet .

[Verwijderd]

Op zaterdag 13 juli 2002 17:54 schreef DiEana het volgende:

[..]

Het inserten is slower ja: je moet 1 of meerdere "extra" inserts doen + de index van die "extra" tabellen moeten eventueel aangepast worden.

Een domme vraag misschien, maar wat ben je met een "lijst" van alle admins? Zolang je maar weet wat de huidige(!) gebruiker kan en niet kan, is het toch voldoende?

Een lijst van admins gebruik ik om te laten zien in de forum index welke users admins zijn voor welke fora's

verder heb ik niet meer gereageerd omdat ik andere dingen te doen had en vraag me nu af na alle postings gelezen te hebben wat beter is, toch de query's uitvoeren of indexes maken dus het aantal postings / etc in de db zetten.

[ACM]

Op zondag 14 juli 2002 08:58 schreef xtentic het volgende:
en vraag me nu af na alle postings gelezen te hebben wat beter is, toch de query's uitvoeren of indexes maken dus het aantal postings / etc in de db zetten.

Mbravenboer en ik hadden het vooral over geavanceerdere databases (daar waar ze waar voor hun geld beginnen te maken...) ipv mysql.
Daar is het waarschijnlijk in vrijwel alle gevallen de count ergens op te slaan en per bericht bij te werken...