[MySQL] structuur database voor cd index sys

[supersook]

Ik ben al een paar dagen bezig met een cd indexerings systeem. Nu werkt het systeem op zich, alleen moet alle informatie nog de DB in om er in te kunnen zoeken.

Het is de bedoeling dat ik net als normaal een zoekopdracht kan doen naar een bestand en/of map. Nu dacht ik zelf dat ik het best een tabel kan maken met daarin alle bestanden die gevonden zijn (is 1 row) met daarin de naam van het bestand, het path, het type, en de cd waar deze op te vinden is. Maar op het moment dat je een stuk of 100 cd's inleest gaat deze db natuurlijk gigantisch veel rows bevatten, en daar wordt de zoektijd nou ook niet bepaald sneller door.

Weet iemand misschien een betere manier om m'n database te vullen?

[Nielsz]

100 cd's * 24 nummers = vet weinig voor een mysql server. Dat vind hij wel gezellig hoor.

[Verwijderd]

Inderdaad. De MySQL DB waarop GoT draait bevat een veelvoud van die informatie, dus de hoeveelheid gegevens moet je niet als een probleem zien.

Wel is het belangrijk dat je goed normaliseert, goeie indexen aanlegt en goeie queries schrijft. Informatie daarover kun je in de FAQ vinden.

Als je hulp nodig hebt met het datamodel moet je een wat completere beschrijving geven, dan zijn er vast wel wat mensen die je willen helpen.

Succes

[supersook]

Op donderdag 11 oktober 2001 17:10 schreef Nielsz het volgende:
100 cd's * 24 nummers = vet weinig voor een mysql server. Dat vind hij wel gezellig hoor.

't gaat hier om data cd's.. misschien dat mijn vraag dan zinniger wordt?

[Verwijderd]

Misschien kan je beter een Directory Service gebruiken voor dit systeem, aangezien die heel goed en snel zijn in het opslaan van hierarchisch georganiseerde gegevens, die niet heel vaak aangepast hoeven te worden.

Zie bijvoorbeeld http://www.OpenLDAP.org voor een gratis Directory Service systeem.

Verder denk ik dat je er niet aan kunt ontkomen om per file en per directory 1 record in een tabel te zetten om de functionaliteit die je schetst te realiseren.

Welke database je daarvoor gebruikt en wat voor hardware je nodig hebt om het snel genoeg te maken is een tweede vraag.

HTH

[Janoz]

Het zoeken op een key veld is een logaritmische operatie.. Dat komt ongeveer neer op dat het zoeken 1 stap langer duurt als het aantal rows een keer zo groot wordt.. Het is dus NIET zo dat een db alle velden bijlangs gaat om een waarde te zoeken..

[supersook]

even de search gebruiken geeft een hoop opheldering over LDAP > Topic over LDAPP

maar wat moet ik me erbij voorstellen? zijn hier docs over die uitleggen wat nou precies de opbouw is. Aangezien ik alleen ervaring heb met databases. En hoe ga ik me gegevens daar dan in opslaan? Ik weet nu wel dat het sneller is voor grote hoeveelheden gegevens, maar op de site van OpenLDAP staaat verder ook niet hoe het precies werkt e.d.

(en nog iets, hoe krijg ik dit onder win2k werkend, want volgens mij staat op de site alleen een versie voor linux)

[Zoijar]

half miljoen records moet geen enkel probleem zijn voor mysql. Ik ken de specs niet precies, maar in principe zou zelfs een aantal miljoen geen probleem op moeten leveren.

[supersook]

Op donderdag 11 oktober 2001 20:16 schreef Zoijar het volgende:
half miljoen records moet geen enkel probleem zijn voor mysql. Ik ken de specs niet precies, maar in principe zou zelfs een aantal miljoen geen probleem op moeten leveren.

ok, probeer ik het eerst met MySQL

[Zoijar]

misschien dat dit iets ophelderd

"In most cases you can estimate the performance by counting disk seeks. For small tables, you can usually find the row in 1 disk seek (as the index is probably cached). For bigger tables, you can estimate that (using B++ tree indexes) you will need: log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1 seeks to find a row.

In MySQL an index block is usually 1024 bytes and the data pointer is usually 4 bytes. A 500,000 row table with an index length of 3 (medium integer) gives you: log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 seeks."

[supersook]

ik waag het er wel gewoon op