SELECT problem z zapytaniem Opcje

[i'm_an_amateur]

Witam, mam następujące tabele

articles (id, title, author, content, submenu)
users (id, login, pass, name, last_login, sign_up)
submenu (id, subtemplate_id, name, link)
subtemplates (id, subtemplate)

Strona posiada jakieś podkategorie, każda z tych kategorii może się wyświetlać w innym subtemplate.

Moim zadaniem jest pobrac wraz z pobieraniem artykułu subtemplate w jakim będzie sie wyświetlać ten artykuł, przy czym kolumna posts posiada klucz obcy tyloko do submenu, natomiast dopiero to submenu do subtemplates.

Ponadto całość opiera się na linkach bez żadnych wartości liczbowych i muszę jakoś wyświetlić wymagany artykuł. Czy taki warunek jest rzeczowy? $id to zczytany z bazy submenu.link.

[SQL] pobierz, plaintext 
WHERE  articles.submenu = (SELECT submenu.id FROM submenu WHERE submenu.link='$id')
[SQL] pobierz, plaintext 

Nie jest to moja praca, tylko poprawiam czyjeś wypociny i jakoś nie mogę się w tym odnaleźć. Możliwe, że struktura bazy danych jest do poprawienia.

Pozdrawiam i dzięki

[Pilsener]

Z tego co rozumiem, to każdy arykuł posiada własne submenu (?), które to korzysta z szablonu z tabeli subtemplates - nie bardzo to rozumiem, bo wg mnie menu i szablon strony powinien należeć do kategorii/podkategorii lub systemu arykułów jako całości - inne menu i szablon dla każdego artykułu? To bez sensu, zmieniać się powinna jedynie treść artykułów i style, jeśli chcemy zmienić wygląd to zakładamy dla artykułów inną kategorię.

No ale do rzeczy: możesz łatwo utworzyć relacje:
articles -> submenu -> subtemplates

Poczytaj o złączaniu tabel przy pomocy JOIN, robisz zapytanie w stylu:

[SQL] pobierz, plaintext 
SELECT * FROM articles JOIN submenu ON articles.submenu=submenu.id
[SQL] pobierz, plaintext 

(zakładam, że pole submenu w articles to id menu z tabeli submenu)

W ten sposób "podłączasz" tabele submenu, na podobnej zasadzie możesz dodać dowolną liczbę tabel.

[i'm_an_amateur]

Z tego co rozumiem, to każdy artykuł posiada własne submenu (?), które to korzysta z szablonu z tabeli subtemplates

Ni.
Już sobie poradziłem z tym zapytaniem (stosujac dodatkowe zapytanie do bazy danych), ale wyjaśnię problem nie pozostawiając wątpliwości.

Każde menu ma podkategorie. W każdej z tych podkategorii są jakieś artykuły. Każda podkategoria korzysta z innego subtemplate. W tabelce podkategorii jest klucz obcy do tabelki subtemplate. Pobierając artykuł muszę pobrać informację do jakiej należy podkategorii, a dopiero następnie subtemplate, który jest przypisany do tejże podkategorii. Schemacik

Żądanie artykułu -> pobranie informacji z jakiej podkategorii pochodzi -> pobranie informacji z jakiego subtemplate korzysta podkategoria

Proszę wybaczyć liczne powtórzenia słów "każdy", "podkategorie"

Chciałbym jednak wrócić do drugiej części mojego postu.
Zapytałem tam jak wyświetlić właściwy artykuł mając z tablicy $_GET wartość string. Czy dobrą praktyką jest przechowywanie np przy artykule w bazie danych linka do niego? Mam na mysli stringa który w linku jest odpowiedzialny za akurat ten art i go porównywać


Pozdrawiam, i'm_an_amateur

[Pilsener]

Co do ostatniego pytania: NIE. Artykuł powinien zostać wyświetlony na podstawie jego ID, które jest zapisane na końcu adresu, np.
moja-strona.pl/filmy/sensacyjne/zabili;go;i;uciekl,3456.html - 3456 to id artykułu, na jego podstawie pobieramy całą resztę. Oczywiście sposób generowania i odczytywania URLi może się zmienić, ale idea pozostanie ta sama. Pobranie artykułu na podstawie unikalnej nazwy także jej możliwe, ale kłopotliwe i mało wydajne - co, gdy np. ktoś zechce zmienić nazwę artykułu? Poza tym każdy artykuł powinien posiadać coś takiego jak tagi (wpisywane ręcznie lub generowane automatycznie), co zapewnia wsparcie dla SEO.

[i'm_an_amateur]

Zgadzam się co do tagów, wypluwam je także w meta keywords.

W związku z odpowiedzią dotyczącą linków mam pytanie jak odczytywany jest np ten link http://wortal.php.pl/wortal/artykuly/php/a...kontra_oo_w_php


Ten post edytował i'm_an_amateur 25.01.2010, 19:52:23

[Pilsener]

Jest to normalna struktura drzewa, gdzie jedna gałąź = jedna nazwa, tak samo jak w menu nie mogą istnieć dwie pozycje o tej samej nazwie. Jest to dość proste rozwiązanie, wystarczy dać index unique dla nazwy a każdą podkategorię rozdzielasz w adresie /, przerabiasz też tittle na URL - ale takie rozwiązanie ma następujące wady:
- adresy mogą być za długie (zwłaszcza jeśli nazwy podkategorii są długie)
- nie mamy możliwości zróżnicowania słów w adresie od nazw podkategorii
- słowa kluczowe na których nam zależy trafiają na koniec adresu, przez co mają mniejszą moc

Ja używam rozwiązania bardziej wyrafinowanego:
- w adresie używam nazw tylko do określonej głębokości, w tym wypadku byłoby np. wortal.php.pl/wortal/artykuly/programowanie;proceduralne;kontra;oo;w;php,1234.html (do głębokości -2), potem używam ID doklejonego na końcu
- pozwalam zdefiniować nazwę w adresie różną od tej w menu (dla wyszukiwarek adres, dla usera menu)
- słowa kluczowe umieszczam tak blisko początku adresu, jak się da (mają wtedy większą moc), natomiast parametry, identyfikatory etc. na końcu

Są jeszcze kwestie wydajności, konfliktów, ale zakładam, że każdy to ogarnie i używa cache etc, więc nie ma to znaczenia.

Ale nie odbiegajmy od tematu, to już jest bardziej SEO

[i'm_an_amateur]

W takim razie na WordPress się nie wzorować?
http://stackoverflow.com/questions/13213/url-without-id

Korzysta ktoś z Was ze wspomnianego tam sluga?

[Pilsener]

Każdy system ma jakieś wady i zalety, jeśli zależy Ci na prostocie i szybkiej indeksacji treści to WP jest tu bardzo dobrym pomysłem, ze względu na system tagów i linkowania wewnętrznego - dla SEO jest to także bardzo istotne. Wszystko zależy od tego, do czego serwis ma służyć i jak będzie pozycjonowany. I przy przepisywaniu linków radzę wzorować się na Drupalu ładując cały adres do PHP i potem tam go obrabiać - dzięki temu możemy w każdej chwili zmienić zarówno konstrukcję samych adresów, jak i ich interpretację bez modyfikazcji .htaccess czy głębokich przeróbek kodu - wystarczy jedna klasa do odczytywania adresów a druga do ich generowania.