Inrichten database

[aex351]

Ik ben bezig in C# om een tool te schrijven dat headers van nieuwgroepen wegschrijft naar een database. Nu is dat niet zo'n probleem, maar het inrichten van de database om het zo snel door zoekbaar te maken wel. Ik heb al tal van manieren geprobeerd maar steeds kom ik op een punt dat er toch redundant data aanwezig is. Dus hierbij open ik deze thread in de zoektocht naar een oplossing.

Zo ziet een usenet header eruit (heb wat data veranderd zodat gebruiker anoniem blijft)

code:

104491  cool - Maya - Introduction school - Walk Cycle.part10.rar-(Piet)[12/22] (51/79) [e-mail] (Piet)  Sat, 09 Jun 2007 03:48:56 -0500 <part51of79.KGqrAWvo9VacGfIJb&[e-mail]>     646475  5004    Xref: feeder.gebruiktenieuwserver.nl alt.binaries.bonless:104491

Elke kolom onderscheid ziet via een tab \t (niet zichtbaar in bovenstaande voorbeeld). Dit is uit te splitsen in: (zie afbeelding)



Opsommingen in het bovenstaande afbeelding betekend dat er vanuit die ene regel meer data te ontrekken is.

Deze header (zie codeblok hierboven) is onderdeel van één bestand, dit is af te leiden uit de haakjes. Er staat in de subject regel, tweede kolom, (51/79) . Dit betekend dat het PART 51 is van 79 om één bestand te maken.
Deze Part maakt ook onderdeel uit van een collectie van bestanden. Dit is af te leiden uit [12/22] in de subject regel. Bestand nummer 12 van de in totaal 22 bestanden.

Article_id = unieke id van part welk bij de gebruikte usenetserver hoort.
message_id = unieke id van de part, is op elke usenetserver hetzelfde.
xref = bestaat uit [gebruikte usenetserver en naar welke usenetgroep(en) is geupload met de de daar bijbehorende article_id )

Hoe kan ik nu het beste de database inrichten, of anders gezegt: hoe moet ik verder met normaliseren.

[Pete]

Het ligt er een beetje aan wat het doel is van je database. Zoals ik het nu zie zo ik je model opsplitsen in de volgende entiteiten (tabellen)
Collection 1 - 00 File 1 - 00 Message(Part) 1 - 00 Article
(00 staat voor oneindig. dit zijn dus allemaal 1 staat tot veel relaties)

Dit lijkt mij vrij standaard. Maar welke modellen had je zelf al ontworpen? Wat wil je met je data gaan doen (omdat normalisatie niet altijd het beste is)?

[Confusion]

aex351 schreef op woensdag 13 juni 2007 @ 21:00:
Ik heb al tal van manieren geprobeerd maar steeds kom ik op een punt dat er toch redundant data aanwezig is.

Dat is vaak ook wel noodzakelijk om tot snellere queries te komen. En bepaald niet erg, mits je zorgt dat redundante data niet inconsistent kan raken.

Dus hierbij open ik deze thread in de zoektocht naar een oplossing.

Is een tool als Lucene niets voor je? Dat is juist bedoeld om full text-search mogelijkheden aan programma's/databases toe te voegen.

Hoe kan ik nu het beste de database inrichten, of anders gezegt: hoe moet ik verder met normaliseren.

Niet. Het normaliseren van databases is goed voor een paar aspecten van datagebruik, maar lang niet voor alle. Zoals altijd zijn er tradeoffs.

[ Voor 17% gewijzigd door Confusion op 13-06-2007 22:00 ]

[NetForce1]

Confusion schreef op woensdag 13 juni 2007 @ 21:58:
Is een tool als Lucene niets voor je? Dat is juist bedoeld om full text-search mogelijkheden aan programma's/databases toe te voegen.

Dat lijkt mij ook een goede optie, nog beter is dan Compass. Compass is een framework om Lucene heen waarmee je heel makkelijk domein modellen kunt mappen naar Lucene.

[Confusion]

NetForce1 schreef op woensdag 13 juni 2007 @ 22:28:
Dat lijkt mij ook een goede optie, nog beter is dan Compass. Compass is een framework om Lucene heen waarmee je heel makkelijk domein modellen kunt mappen naar Lucene.

Van Compass bestaat zo te zien geen .Net versie. Dat maakt het voor de topicstarter lastig om te gebruiken .

[NetForce1]

Confusion schreef op woensdag 13 juni 2007 @ 22:51:
[...]

Van Compass bestaat zo te zien geen .Net versie. Dat maakt het voor de topicstarter lastig om te gebruiken .

O ja, dat had ik even niet in de gaten...

[aex351]

phsmit schreef op woensdag 13 juni 2007 @ 21:53:
Het ligt er een beetje aan wat het doel is van je database. Zoals ik het nu zie zo ik je model opsplitsen in de volgende entiteiten (tabellen)
Collection 1 - 00 File 1 - 00 Message(Part) 1 - 00 Article
(00 staat voor oneindig. dit zijn dus allemaal 1 staat tot veel relaties)

Dit lijkt mij vrij standaard. Maar welke modellen had je zelf al ontworpen? Wat wil je met je data gaan doen (omdat normalisatie niet altijd het beste is)?

De data moet opgeslagen worden in de db en vervolgens snel doorzoekbaar worden. Collecties moeten gevonden worden en bestanden.

De model zoals jij die omschrijft zo had ik het ook aanvankelijk, iets uitgebreider, uitgewerkt. Alleen loop er dan uiteindelijk toch weer op vast. Vandaar ook dat ik mijn eerst post zo minimaal mogelijk heb gehouden.

Confusion schreef op woensdag 13 juni 2007 @ 21:58:
Dat is vaak ook wel noodzakelijk om tot snellere queries te komen. En bepaald niet erg, mits je zorgt dat redundante data niet inconsistent kan raken.

Klopt. Maar met een database dat snel tot in de miljoenen records zal gaan lopen probeer ik alles zo geoptimaliseerd mogelijk te houden.
[/quote]

Is een tool als Lucene niets voor je? Dat is juist bedoeld om full text-search mogelijkheden aan programma's/databases toe te voegen.

Interface zal webbassed worden middels PHP en zal tevens ook de zoekfunctionaliteit moeten bieden. C# is het backend gedeelte dat dus de power werk zal moeten doen.

[ Voor 37% gewijzigd door aex351 op 14-06-2007 21:25 ]

[NetForce1]

aex351 schreef op donderdag 14 juni 2007 @ 21:22:
[...]

Interface zal webbassed worden middels PHP en zal tevens ook de zoekfunctionaliteit moeten bieden. C# is het backend gedeelte dat dus de power werk zal moeten doen.

Er is een C# port van Lucene, en een PHP koppeling met de C port, dus dat lijkt me geen enkel probleem.

[Pete]

aex351 schreef op donderdag 14 juni 2007 @ 21:22:

De model zoals jij die omschrijft zo had ik het ook aanvankelijk, iets uitgebreider, uitgewerkt. Alleen loop er dan uiteindelijk toch weer op vast. Vandaar ook dat ik mijn eerst post zo minimaal mogelijk heb gehouden.

Waar liep je precies op vast? Dan kunnen we je daar helpen.

[aex351]

phsmit schreef op donderdag 14 juni 2007 @ 21:30:
[...]
Waar liep je precies op vast? Dan kunnen we je daar helpen.

Hoe ik ervoor kan zorgen dat ik met zo min mogelijk queries de data gestructureerd kan toevoegen in de database. Teveel dubbele data is ook geen optie vanwege de grootte van de database, zal uit miljoenen records bestaan.

Nu haal ik alle headers op en stop ze in de usenet_part tabel. Zoals bekend maken vele van deze headers onderdeel uit van 1 bestand. Dit gegeven wil ik in de usenet_bestand tabel verwerken. Hoe pak ik dit aan? Want iedere keer wanneer ik een header in de usenet_part tabel stop moet ik dus ook kunnen controleren of deze al is aangemaakt in de usenet_bestand tabel.

Ben dus opzoek naar een efficiente manier.

[Comgenie]

Ik werk momenteel ook met grote databases die snel al 50 gig worden. En doorzoekbaar moeten blijven. Bij mij helpt het een heleboel door voor velden die je zou willen laten doorzoeken een index aan te maken. Zodat hij het indexeerd (doh). Als je daarbij ook nog een LIMIT 100 achter een select query zet is het zeer goed te doen. En zou je evt. alles in de database kunnen zetten hoe je het hebt gesplit. Natuurlijk valt er wel hier en daar wat te optimaliseren.=)

[Niemand_Anders]

MySQL heeft een ingebouwde optie om middels 1 query zowel een insert OF een update uit te voeren. Dat wordt gedaan middels de replace query. In plaats van INSERT INTO schrijf je nu de query REPLACE INTO. De rest van de query blijft hetzelfde. Als MySQL een record vind welke voldoet aan de where clause, dan wordt er een update query van gemaakt en ander wordt het een insert.

Maar waarom wil je zo min mogelijk queries gebruiken? Meestal betekend dat complexere queries en daarmee een langere uitvoer tijd. Zet gewoon de juiste indexen en de select query om te bepalen of je een insert of update moet doen, komt binnen enkele millisecondes terug.

Verder moet je achterhalen waarop precies gezocht moet kunnen worden. Alleen op subject of ook body en afzender? Hoe complex kunnen de zoekopdrachten (via de webinterface) worden? Wil je boolean searches ondersteunen? Of moet een bezoeker gewoon kunnen zoeken op een keyword?

Hoe lang (retentie) blijven de artikelen zelf in de database staan? Ik raad je aan je voorlopig te beperken tot 2 a 3 nieuwsgroepen en dan verschillende database ontwerpen c.q. oplossingen uit te proberen.

[Voutloos]

Niemand_Anders schreef op dinsdag 03 juli 2007 @ 11:50:
MySQL heeft een ingebouwde optie om middels 1 query zowel een insert OF een update uit te voeren. Dat wordt gedaan middels de replace query. In plaats van INSERT INTO schrijf je nu de query REPLACE INTO. De rest van de query blijft hetzelfde. Als MySQL een record vind welke voldoet aan de where clause, dan wordt er een update query van gemaakt en ander wordt het een insert.

offtopic:
Nope. REPLACE is de tegenhanger van INSERT IGNORE.
Ik neem aan dat je een 'INSERT ... ON DUPLICATE KEY UPDATE' bedoelt.

Overigens had nog niemand het expliciet over mysql gehad.