[SQL] Projekt bazy dla serpów

[k0l3c]

Proszę o poradę odnośnie najlepszego rozwiązania bazy danych dla serwisu ala webpozycja, stat4seo itp. abym mógł dodawać łatwo nowe domeny, frazy i aktualizować miejsca bezpośrednio ze zmiennej zwróconej przez klasę do sprawdzania pozycji. I oczywiście odczytywać do tabel podzielonych na miesiące. (ale to już bardziej php)

Chodzi mi głównie o sam projekt tabel/tabeli, jak byście ją zrobili?

Na razie kombinuję coś na ten styl, tylko jeszcze by się data pewnie przydała.

CREATE TABLE pozycje (id int NOT NULL AUTO_INCREMENT, DOMENA char(30), fraza char(30), miejsce int(3), PRIMARY KEY(id))

Jest sens w takiej formie?

[INOMan]

Kilka z moich zasad odnośnie struktur baz danych:

1) Nazwa tabeli zawsze w rzeczowniku w 1 osobie, czyli nie "pozycje" a "pozycja"

2) Nazwy tabel i kolumn - po angielsku, czyli nie "pozycja" a "position" lub "rank"

3) Jeżeli tabela posiada tylko jeden numeryczny Primary Key generowany/autoincrement to niech się nazywa "id"

4) Klucze obce zawsze najlepiej w postaci: "nazwa-obcej-tabeli_id"

W twoim przykładzie kolumna "id" nigdy nie będzie ujemna więc spokojnie można dać atrybut UNSIGNED - zawsze dodatkowa korzyść, podobnie kilku pozostałym kolumnom w moim przykładzie niżej.

Co do struktury, tak w skrócie bo elaboratu nie będę pisać:

Table "rank":

id,

domain_id,

phrase_id,

position,

Table "rank_history"

id,

rank_id,

position,

position_time

Table "domain"

id,

name,

name_without_www

Table "phrase"

id,

name

length

Myślę, że za dużo nie muszę tu tłumaczyć - nazwy kolumn są samo wyjaśniające się.

[WebReklama]

W tabeli "rank" pole position jest nie potrzebne - chyba że ma ono służyć do ustawiania kolejności fraz podczas wyświetlania.

[INOMan]

Tak WebReklama - sam sobie odpowiedziałeś. Po za tym czasem można chcieć po prostu pobrać aktualną ostatnią pozycję i wtedy nie trzeba ruszać tabeli "rank_history".

[WebReklama]

Ale trzaeba ptrzy zbieraniu statystyk 2 tabele aktualizować

[INOMan]

Hehe, no już nie czepiajmy się szczegółów To luźna struktura jak ktoś chce ją wykorzystać to i tak przerobi tak jak mu pasuje.

[Razjer]

pole `fraza` dałbym trochę więcej miejsca bo 30 znaków to za mało jeżeli chcesz sprawdzać regionalki i długi ogon. Pozycja będzie sprawdzana przez serwery proxy czy cyklicznie?

Domeny dałbym do osobnej tabeli a w twojej tabeli przechowywałbym tylko id domeny

Edit: Nie zauważyłem, kolega INOMAN dał ci strukturę znormalizowaną.

[k0l3c]

Teraz mam problem z wyświetlaniem tego, chciałem do tabeli, ale jak na razie to tworzę dwie osobne tabele.

tabela1 = frazy

tabela2 = miejsca

Jak sformułować takie zapytanie "SELECT FROM rank WHERE id" jest takie samo jak keyword_id FROM website?

Czytam, szukam aż mi się obraz rozmazuje..

Tak to teraz wygląda:

$frazy = mysql_query("SELECT * FROM keyword");
echo '<table class="frazy">';
echo '<tr><td>FRAZY</td></tr>';
while ($fa = mysql_fetch_assoc($frazy)) {
echo '<tr><td>';
echo ($fa['name']);
echo '</td></tr>';
}
echo '</table>';

/**/
echo '<table class="rank"><tr>';
for($i=1;$i<32;$i++) {
echo '<td>',$i,'</td>';
}
echo '</tr><tr>';
/**/

$wyniki = mysql_query("SELECT * FROM rank WHERE keyword_id=1");
while ($txt = mysql_fetch_assoc($wyniki)){
echo '<td>';
echo ($txt['rank']);
echo '</td>';
}
echo '</tr><tr>';
$wyniki = mysql_query("SELECT * FROM rank WHERE keyword_id=2");
while ($txt = mysql_fetch_assoc($wyniki)){
echo '<td>';
echo ($txt['rank']);
echo '</td>';
}
echo '</tr>';
echo '</table>';

mysql_close($q);

[Razjer]

SELECT tabela1.pole, tabela2.pole FROM tabela1 LEFT JOIN tabela2 ON tabela1.pole = tabela2.pole;

Myślę że o takie coś chodziło?

[k0l3c]

A nie da się tego zrobić wygodniej? np. nie lepiej będzie z miejsca utworzyć całą tabelę na miesiąc i tylko robić UPDATE?

[Mion]

Implementuj tak jak ci "wygodnie" i na poziomie obecnych umiejętności. "Lepsze" rozwiązania przychodzą z czasem ....

Musisz też przewidzieć, ze dany keywords dostał bana i nie występuje wcale w SERP lub na odległych pozycjach standardowo do 100 się sprawdza.

[k0l3c]

Jeżeli nie ma frazy w ustalonym przeze mnie zakresie, klasa zwraca mi "-", także powinno być ok.

Najgorsze są pętle, które mają rysować tabelkę na cały miesiąc, ale już coś tam napisałem także powinienem dojść do dobrego rozwiązania.

I tak jak mówisz, z czasem się to zoptymalizuje wraz z nową wiedzą.

Tylko też chciałbym uniknąć robienia na około, dla tego pytam jak wy byście to rozwiązali.

[WebReklama]

Problem z robieniem tabelki na cały miesiąc możesz rozwiązać tak, że w bazie masz tylko wyniki do dzisiaj / wczoraj. PHP rysuje tabelke na cały miesiąc i uzupełnia ja danymi które posiada. Mniej danych w bazie, mielenia prawie tyle samo

[Mion]

Od tego trzeba zacząć "Problem z robieniem tabelki na cały miesiąc ", że to nie żaden problem. Dane o pozycjach zapisuje się codziennie wstawiając zwyczajnie dane do tabeli:

Tabela: PozycjeFraz

INT idf > jest to klucz obcy z id frazy dodany w innej tabeli SprawwdzaneFrazy

INT pozycja > zajmowana pozycja podczas sprawdzania

DATE > data sprawdzania

[INOMan]

Taka mała uwaga: te cztery zasady projektowania baz co podałem wcześniej to tak naprawdę nie tyle są moje, co są dość szeroko rozpowszechnione wśród osób które zajmują się tym profesjonalnie.

Więc nazywanie tabel "PozycjeFraz" albo klucz obcy "idf" do tabeli "frazy" (zamiast frazy_id) to w tym sensie błąd.

Oczywiście można to olać sikiem prostym tak samo jak można olewać przepisy ruchu drogowego albo np. zasadę, że zupę je się łyżką a nie ręką - ale naprawdę warto się tych 4 zasad budowy baz trzymać!