[SQL] where conditie vraag

[Infern0]

Mijn apache logs gaan nu een DB in, dit is erg handig alleen ik zit te stoeien met een query. Draait op op postgres (dus sub query's )
layout table (eenvoudige)

code:

CREATE TABLE "log_entries" (                                                
      "bytes_sent" integer,
      "request_url_path" character varying(80),
);

nu wil ik het totaal aantal bytes per dir hebben.
In de kolom request_url_path staan zoiets als "/info/plaatje.jpg" (de hele url van deze is dus www.domein.nl/info/plaatje.jpg)

Dus hij moet distincten op /%/ en daarover een count gooien.
Ik wil dus ook dat ie gewoon alle dirs neemt die in de table staan.

In het overzicht moet dus komen te staan hoeveel elke dir verbruikt.

[justmental]

code:

select sum(bytes_sent)
,   count(*)
from log_entries
group by substr(instr(request_url_path,'/')....etc...etc)

Dat laatste zul je zelf even moeten doen aangezien ik geen postgres spreek.

[vandijk]

Daar zit dus ook de file naam nog in. Je moet die kolom nog strippen van alle karakters na de laatste /

[Onno]

Op dinsdag 27 november 2001 16:07 schreef justmental het volgende:

code:

select sum(bytes_sent)
,   count(*)
from log_entries
group by substr(instr(request_url_path,'/')....etc...etc)

code:

select substr(instr(request_url_path,'/')....etc...etc) as blaat,
  sum(bytes_sent) from log_entries group by blaat

Zoiets lijkt me dan iets logischer.

[Infern0]

Ben al flink wat aan het stoeien, maar wil nog niet echt lukken.
deze code zijn een goede stap op weg zijn

code:

select substr(instr(request_url_path,'/')....etc...etc) as blaat,
  sum(bytes_sent) from log_entries group by blaat

Omdat ik de query niet helemaal begrijp heb ik wat dingen na gezocht:
http://technet.oracle.com/doc/lite/sqlref/html/sqfun.htm#1003960
http://technet.oracle.com/doc/lite/sqlref/html/sqfun.htm#1003546
en de oralcle syntax is hetzelfde als de postgres syntax iig voor substr, voor instr heb ik dit gevonden:
http://www.postgresql.org/idocs/index.php?plpgsql-porting.html#PLPGSQL-PORTING-APPENDIX
wat hetzelfde zou doen als de oracle versie.

Volgende probleem is dat ik niet snap waarom jullie deze functie's gebruiken (ik zou ook niet weten hoe anders). Misschien dat iemand wat uitleg kan geven?

[Infern0]

gevonden:

code:

select substr(request_url_path,instr(request_url_path,'/'),  instr(request_url_path,'/',2)) as blaat, sum(bytes_sent) from log_entries group by blaat;

[Onno]

Op dinsdag 27 november 2001 23:42 schreef rlensen het volgende:
Volgende probleem is dat ik niet snap waarom jullie deze functie's gebruiken (ik zou ook niet weten hoe anders).

Je wilt directories opvragen, terwijl je bestandsnamen in je database hebt staan. Dus moet je een manier vinden om van zo'n bestandsnaam een directory te maken: je wilt het stuk na de laatste forward slash weghebben.

Toevallig bestaat^* er dan een nuttige functie instr, waarmee je in een string kunt zoeken naar andere strings.

instr(request_url_path,'/',-1) geeft bijvoorbeeld de laatste positie terug waarop een slash voorkomt. (de -1 zorgt ervoor dat ie achteraan begint te zoeken)

Als je dat eenmaal weet, kun je met substr(request_url_path,1,instr(request_url_path,'/',-1)) de directory opvragen: de substring die begint op positie 1, en eindigt op de plek waar je de laatste slash gevonden hebt.

En die ga je vervolgens selecten.


^* Ik geloof dat PostgreSQL standaard geen instr functie heeft, maar die is wel toe te voegen.

[dusty]

zal ik maar weer typerend een opmerking van mij doen: Slecht database "model".

[Mart!]

[off-topic]
Wat heeft dit in vredesnaam met een slecht database model te maken? Je hebt hier van doen met data die vanuit een externe bron wordt toegevoegd! Dan zul je dus moeten leven met de mogelijkheden van die externe bron - en die kan alleen in een platte tabel schrijven...
Ik ben zeer benieuwd naar de uitleg achter deze opmerking.
[/off-topic]

[Janoz]

Op woensdag 28 november 2001 08:39 schreef Mart! het volgende:
[off-topic]
Je hebt hier van doen met data die vanuit een externe bron wordt toegevoegd! Dan zul je dus moeten leven met de mogelijkheden van die externe bron - en die kan alleen in een platte tabel schrijven...
[/off-topic]

Dan kun je tenminste je data aan de 1e normaalvorm te laten voldoen toch. Als je vind dat mbv een where clause de filename te scheiden is van het path, dan is dit toch net zo goed mogelijk bij een insert operatie?

Niks houd je trouwens tegen om het in eerste instantie in een lelijke tabel op te slan om vervolgens met een chronjob oid de tijdelijke tabel om te zetten naar een fatsoenlijke db.

[dusty]

Op woensdag 28 november 2001 08:39 schreef Mart! het volgende:
Ik ben zeer benieuwd naar de uitleg achter deze opmerking.

Wat de bron van de informatie is, is nooit een reden om een slecht database model te hebben.

[Infern0]

Het database model is denk ik ook niet ontworpen om dir's mee te selecteren. Het is meer bedoeld om subdomeinen mee te selecteren, die staan dan ook in een aparte kolom. In dit geval ben ik afhankelijk van het programma (PGLOGD) wat ik gebruik om de logs in de DB te zetten. Ik had natuurlijk ook het programma kunnen herschrijven, maar mij lijkt dit een betere oplossing.

Maar volgens mij is dit ook een best zware query ben benieuwd of mysql dit veel sneller zou doen als postgresql. De response tijd is ook niet echt hoog.
http://www.webis.nl/rob/traffic.php

[Mart!]

Op zich wel interessant, wat je zegt, dusty...
Maar het is ook niet altijd goed om maar te blijven doornormaliseren tot je er bij neer valt. Je hebt gelijk, er kan nog verder genormaliseerd worden. Maar op zich vindt ik het geen slecht idee om het op bovenstaande manier te doen, omdat je met 1 SQL query toch de gewenste gegevens eruit kan halen. Bovendien brengen cron-jobs weer ander 'problemen' met zich mee, ik zou niet weten hoe ik zo iets moet maken. Anywayz, het is denk ik aan de maker om te bepalen wat de beste oplossing voor zijn probleem is.

In ieder geval wel aardig om aan te geven dat mensen ook aan normaliseren moeten denken, want daar wordt vaak (zeker door beginners) te weinig tijd aan besteed.

[Infern0]

Helaas kon ik mijn 4 college's DB normalisatie's niet gebruiken in dit geval gegeven door de DB goeroe (zo noemt ie zichtzelf)