Ik ben al een tijdje over aan het nadenken, maar kan geen echt effectieve manier bedenken voor het volgende probleem..

Ik heb een database met iets als zo:

id  | pid  | title      | text
----------------------------------
1   | 3    | test 2     | hallo, flip
1   | 4    | test 8     | hallo, flap
1   | 4    | test 4     | hallo, flop
1   | 3    | test 3     | hallo, flup

Nu wilde ik als eindresultaat weten hoeveel kilobyte alle regels zijn gegroupeerd per pid.

"TABLE STATUS" kan helaas alleen de formaten van tabellen terug geven, maar ik wilde van de regels afzonderlijk weten.

[Dr HenDre]

iets in de zin van select * from blaat where pid=3
en alle tekens tellen, en dan weet je hoeveel bytes je hebt

Dr HenDre schreef op 02-04-2005 @ 20:41 :
iets in de zin van select * from blaat where pid=3
en alle tekens tellen, en dan weet je hoeveel bytes je hebt

Dat had ik ook al bedacht...
Maar is ver weg van prettige oplossing..
Het gaat namelijk om +/- 50 verschillende tabellen

datatypes opvragen en bij varchars gemiddelden nemen.

eddie schreef op 03-04-2005 @ 12:44 :
datatypes opvragen en bij varchars gemiddelden nemen.

De regels verschillen per grote

[dafelix]

kent MySQL geen gemiddelde functie? (zoja: aantal rows*gemiddelde lengte=size) Dan is duurt het nog even voordat je query klaar is...

Zoals ik al zei, de regels verschillen van grote..
Er is dus geen gemiddelde te berekenen...

de regels kunnen niet wisselen van grootte; je hebt per regel een maximale grootte (=max van alle datatypen).

int + int + varchar(30 ) = 34 bytes max per regel.

En wat als er velden als type 'text' zijn, en de ene regel 2 woorden bevat, en de volgende 200.



Overigens is de berekening maar 1x per dag op een nachtelijk tijdstip.

als het goed is, een een text max 4 bytes in de tabel. De database maakt een apart bestand waar de inhoud van de text wordt opgeslagen (met een 4-byte adres).

En jji denkt dat een HTTP account access heeft tot de MySQL bestanden?

[Gimme more beer]

********** schreef op 03-04-2005 @ 15:27 :
Overigens is de berekening maar 1x per dag op een nachtelijk tijdstip.

Dan kun je altijd nog regel voor regel gaan uitlezen natuurlijk

Gimme more beer schreef op 03-04-2005 @ 17:56 :
Dan kun je altijd nog regel voor regel gaan uitlezen natuurlijk

Dat is de laatste optie waar ik naar zocht eigenlijk..

[Gimme more beer]

********** schreef op 03-04-2005 @ 18:51 :
Dat is de laatste optie waar ik naar zocht eigenlijk..

Hehe, kan ik me voorstellen

Klein beetje hulp:
http://dev.mysql.com/doc/mysql/en/st...uirements.html

VARCHAR and the BLOB and TEXT types are variable-length types. For each, the storage requirements depend on the actual length of column values (represented by L in the preceding table), rather than on the type's maximum possible size. For example, a VARCHAR(10) column can hold a string with a maximum length of 10. The actual storage required is the length of the string (L), plus 1 byte to record the length of the string. For the string 'abcd', L is 4 and the storage requirement is 5 bytes.

http://dev.mysql.com/doc/mysql/en/blob.html

Each BLOB or TEXT value is represented internally by a separately allocated object. This is in contrast to all other column types, for which storage is allocated once per column when the table is opened.

[edit]
http://dev.mysql.com/doc/mysql/en/st...-overview.html

TEXT

A TEXT column with a maximum length of 65,535 (2^16 − 1) characters.

[/edit]

Hoe de manier van opslaan is wist ik al.
Ik zoek alleen een efficiente manier om het uit te lezen

(Of begrijp ik de hint niet?)

********** schreef op 03-04-2005 @ 21:38 :
Hoe de manier van opslaan is wist ik al.
Ik zoek alleen een efficiente manier om het uit te lezen

(Of begrijp ik de hint niet?)

phpMyAdmin kan toch ook de grootte van de (inhoud van de) tabel uitlezen?

eddie schreef op 03-04-2005 @ 22:54 :


phpMyAdmin kan toch ook de grootte van de (inhoud van de) tabel uitlezen?

Lees het topic nog eens

********** schreef op 03-04-2005 @ 23:01 :
Lees het topic nog eens

Je wilt het gegroepeerd per pid, toch? Als je weet hoe phpMyAdmin het doet, kun je het toch ook zelf maken

Enniewees, wat je ook kunt doen is alle kolommen omzetten naar tekst en daar de lengte van bepalen (=aantal bytes). Integers moet je dan omzetten naar hex-waarden.

Kolommen wijzigen is helaas geen optie.

Grouperen inderdaad per 'pid'.
Maar het formaat per 'pid' wil ik graag weten, niet de totale tabel formaat.

[Enlightenment]

De grote database
De grootte van een database

********** schreef op 03-04-2005 @ 23:17 :
Kolommen wijzigen is helaas geen optie.

Grouperen inderdaad per 'pid'.
Maar het formaat per 'pid' wil ik graag weten, niet de totale tabel formaat.

uuh...

select sum( 4 + 4 + len( title ) + len( text ) )
from tabel
group by pid

Dat valt dus niet onder effectief.
Dan moet ik voor ieder tabel apart de tabel apart die query maken en uitlezen..
(50 tabellen * 25 cellen * 5000 regels+oplopend)

De reden van dit topic is juist om tot een echte oplossing te komen en niet iets als wat jij zegt, want dat had ik zelf ook al bedacht

Allres regel voor regeld uitlezen is echt de aller laatste optie

********** schreef op 04-04-2005 @ 13:10 :
Dat valt dus niet onder effectief.
Dan moet ik voor ieder tabel apart de tabel apart die query maken en uitlezen..
(50 tabellen * 25 cellen * 5000 regels+oplopend)

De reden van dit topic is juist om tot een echte oplossing te komen en niet iets als wat jij zegt, want dat had ik zelf ook al bedacht

Allres regel voor regeld uitlezen is echt de aller laatste optie

php/mysql heeft vast wel:

- functies om alle tabellen op te vragen uit een database
- functies om alle kolommen (inclusief type en lengte) op te vragen van een tabel

Combineer de bovenste twee en bouw een dynamisch statement.

dat kan table status wel..
maar ik vind het allemaal toch niet echt effectief

[Manuzhai]

Ja, hallo, je kan wel zoveel niet effectief vinden. Ik gok dat er geen andere oplossingen zijn dan degenen die er tot nu toe zijn aangedragen. Je probleem is dat je aan de hand van gegevens IN een tabel gegevens OVER die tabel probeert te bepalen; daar is SQL simpelweg niet op berekend. Het is een abstraction, en hoewel bij tijd en wijle leaky is het ook weer niet zo leaky. Je zult dus genoegen moeten nemen met de opties die tot nu toe zijn voorgesteld, of je moet gewoon (en dat is misschien verstandiger) de verschillende dingen met een ander gid in een andere table of zelfs in een andere database opslaan.

De beste optie (denk ik) is niet gegeven, heb op t.net ook even een topic geplaatst en daar kwam iemand met het geniale idee om gebruik te maken van INSERT INTO en dan dus een tijdelijke tabel te gebruiken met als voorwaarde de 'pid'.
Je hoeft dan alleen het formaat van de tijdelijke tabel uit te lezen, daarna leeg je die gewoon weer

Ik heb het nog niet in praktijk getest, maar dat ga ik later vandaag maar eens doen...

Indien iemand nog suggesties heeft hoor ik het graag.

En anders, bedankt voor het meedenken

eddie schreef op 04-04-2005 @ 08:51 :
uuh...

select sum( 4 + 4 + len( title ) + len( text ) )
from tabel
group by pid

Ik ga toch maar voor deze manier..

En voor de geintereseerde:
http://dev.mysql.com/doc/mysql/en/st...uirements.html

Van de ongeveer 870kb die de database bevat (volgens phpMyAdmin -> show) krijg ik maar 730kb geteld..
Iets gaat er nog niet goed

[Manuzhai]

Mogelijkerwijs mis je de indices? Check even hoe groot de .FRM, .MYD en .MYI files zijn. Het zou best kunnen dat je hiermee alleen de .MYD file hebt.

Manuzhai schreef op 07-04-2005 @ 22:57 :
Mogelijkerwijs mis je de indices? Check even hoe groot de .FRM, .MYD en .MYI files zijn. Het zou best kunnen dat je hiermee alleen de .MYD file hebt.

De bestanden al gechecked, die zijn 500Kb

Maar ik ben net achter gekomen dat een aantal vars leeg zijn die gewoon gevuld moeten zijn...
Dus er zit nog een query fout

Edit: ik mis van iedere tabel een aantal b's
Edit2: het gaat overigens over MySQL3 (helaas niet 4).

Ik miste trouwens inderdaad de indices