Jak zaprojektować baze?

[Erbit]

Zastanowił bym się mocniej nad rozwiązaniem proponowanym przez Mrtn!.

[zeus]

A może założe bloga na ten temat?

Wiesz co mysle ze to nie jest zly pomysl...sam jestem u podstaw tworzenia pseudoszukajki po to aby lepiej zrozumiec mechanizmy dzialania wyszukiwarek, jesli np. zebralaby sie grupa osob kazdy by dodal po 1 algorytmie + pani Halinka = onet lezy

[Irek]

zebralaby sie grupa osob kazdy by dodal po 1 algorytmie + pani Halinka = onet lezy

Do tego zbudować sieć robotów indeksujących na wzór "SETI" i Google ma problem

[Edit]

Jest ciszej

[MMP]

Irek, ciszej. Jezu Wy na tym forum wyrzucicie wszystkie moje pomysły.

[Irek]

na tym forum wyrzucicie wszystkie moje pomysły

Najwidocznie nie wpadłeś na to jako pierwszy i jedyny

[MMP]

Irek, to może masz jeszcze jakieś ciekawe pomysły które można by zastosować?

Spytaj córki, bo zapewne zaznajomiłeś ją z mechanizmem działania google i wymyśl coś innowacyjnego :-)

Odkurzyłem starego bloga i dodałem tam kategorie związaną z tym projektem.

[XaV1er]

a moze z innej strony - widze ze masz primaryKey pole URI (rozumiem ze to jakis varchar?) i na nim jest indeks zalozony. W tej chwili gdybam, ale wydaje mi sie to logiczne ... zamiast URI niech kluczem bedzie pole liczbowe ID (integer) i na nim index, na nim wyszukiwanie, itp. Jak mowie, nie jestem pewien (dawno juz nie zglebialem zawilosci projektowania relacyjnych baz danych i troche wyszedlem z tematu) ale index zalozony na polu typu INT powinien dziala szybciej.

Powod, ze operacja DELETE czy UPDATE wykonuje sie dlugo jest taki, ze baza przebudowauje od nowa swoj index. Indeksy maja to do siebie, ze przyspieszaja selecty, ale spowolniaja inne operacje

sprobuj, moze pomoze

a co do trzymania contentu w oddzielnej tabeli... to tez rozsadne, w przypadku, gdybys mial zamiast URI klucz ID, nie byloby to chyba konieczne

[edit]

nie wiem czy w ogole trafilem z tym pomyslem, bo napisalem posta po przeczytaniu zaledwie pierwszej strony i nie wiedzialem, ze ta baza jest na potrzeby wyszukiwarki internetowej w kazdym razie, powodzenia

[MMP]

siteURI, musiało zostać indeksem z powodu działania konstrukcji REPLACE INTO. Jeżeli bym zastosował klucz, i automatyczne zwiększanie wartości to przy każdym REPLACE INTO to te ID by sie zmieniło. Przez co komunikacja pomiędzy tabelami Content i Site by była utrudniona. A także komunikacja z drugą baza danych gdzie są trzymane słowa kluczowe dla danej strony.

gdybys mial zamiast URI klucz ID, nie byloby to chyba konieczne

Było by to niewydaje ponieważ w tej tabeli trzymam adresy jakie robot musi odwiedzić a także te które już odwiedził. Więc musiałem rozbić to na dwie tabele.

Zresztą zawsze lepiej pola tylko LONGTEXT trzymac w osobnej tabeli