: 03. Baza danych

Pary_anime

Tu znajdują się informacje dotyczące bazy danych

Założono współistnienie czterech tabel:

emedia_*_categories

emedia_*_category_descriptions

emedia_*_category_names

emedia_*_category_relations

W miejscu gwiazdki należy wprowadzić elementy, do których odnoszą się kategorie

Celem pierwszej tabeli jest określenie głównych parametrów kategorii takich jak właściciela kategorii, numeru kolejnego kategorii dla wskazanego właściciela kategorii, numer porządkowy oraz oznaczenie co do widoczności danej kategorii.
Tabela powinna zapewnić:

* obsługę wielu niezależnych serwisów.

Celem drugiej tabeli jest wsparcie procesu administracji kategoriami. Znajdujące się tam informacje będą wykorzystywane jedynie przez Administratorów. Ten moduł nie potrzebuje wielojęzyczności, chociaż go nie wyklucza.

Celem trzeciej tabeli jest zapewnienie wielojęzyczności nazw kategorii z jednej strony, a wskazaniem modułu/pliku wywoływanego z drugiej strony. Założono, że w zależności od języka może istnieć konieczność wywołania innego pliku. Kategoria powinna mieć możliwość wpływania na wybór szablonów. Być może wybór pliku będzie wpływał na wybór szablonu.
Tabela powinna zapewnić:

* obsługę wielu języków,

* obsługę wielu niezależnych serwisów.

Ostatnia tabela określa cały mechanizm powiązań pomiędzy kategoriami. Tabela powinna dać możliwość pokazania relacji pomiędzy kategoriami z uwzględnieniem właściciela katalogów.
Tabela powinna zapewnić:

* możliwości przyporządkowania jednej kategorii głównej wielu subkategorii

* możliwość przyporządkowania każdej subkategorii do wielu kategorii głównych
syriusz napisał(a):Założono współistnienie czterech tabel:

W miejscu gwiazdki należy wprowadzić elementy, do których odnoszą się kategorie

czyli co bo nie rozumiem??

Cytat:
Celem pierwszej tabeli jest (...) numeru kolejnego kategorii dla wskazanego właściciela kategorii, numer porządkowy (...)i.

wytlumacz mi po co 2 numery?

Cytat:
Celem trzeciej tabeli jest zapewnienie wielojęzyczności nazw kategorii z jednej strony, a wskazaniem modułu/pliku wywoływanego z drugiej strony. Założono, że w zależności od języka może istnieć konieczność wywołania innego pliku. Kategoria powinna mieć możliwość wpływania na wybór szablonów. Być może wybór pliku będzie wpływał na wybór szablonu.

nadal nie rozumimem po co wielojezycznosc? czy nie mozna tego zrobic nastepujaco:
definiujemy kilka kategorii, kazda dla innego jezyka serwisu. do tych kategorii dolaczamy tylko to co mamy w danym jezyku. i odpada kombinowanie.
wg sposobu zaprezentowanego przez Ciebie, kazda kategoria musi miec wpisy dla kazdego jezyka.
czyli przy 10 jezykach dla kazdej kategorii trzeba dodac 10 wpisow w baze... troche duzo i jak dla mnie niepotrzebne...
co do szablonow to sie zgadzam - kazda kategoria musi miec swoj szablon, w wypadku NULL na przyklad, szablon domyslny
[/quote]

Cytat:
Ostatnia tabela określa cały mechanizm powiązań pomiędzy kategoriami. Tabela powinna dać możliwość pokazania relacji pomiędzy kategoriami z uwzględnieniem właściciela katalogów.

po co uwzgledniac wlasciciela katalogow? i tak nie powiaze nie swojej kategorii ze swoja, bo nie bedzie mial do innych dostepu....

Cytat:
Tabela powinna zapewnić:

* możliwości przyporządkowania jednej kategorii głównej wielu subkategorii

* możliwość przyporządkowania każdej subkategorii do wielu kategorii głównych

malo maslane
Sorry, ale potnę twoją wiadomość. Zwiększy to czytelność.

roodee napisał(a):syriusz napisał(a):W miejscu gwiazdki należy wprowadzić elementy, do których odnoszą się kategorie czyli co bo nie rozumiem??

System zakłada uniwersalność i nie jest przypisana do jakiegokolwiek innego. To oznacza, że będą mogły być wykorzystywane wielokrotnie. W praktyce oznacza to, że może być wykorzystywany przez wiele modułów, które będą inaczej miały ustawione kategorie.

W takiej sytuacji wystarczy w miejsce gwiazdek podstawić nazwę modulu. Np., gdy kategorie beda odnosiły się do artykułów, to w tym miejscu pojawi się słowo artykuly, gdy ksiegowość, to ksiegowosc, itd, itp.

Oczywiście najlepiej byłoby mieć jeden system tabel dla wszystkich modułów. Wystarczyłoby tylko dodać pole "nazwa modułu". Ale nie wiem czy to dobre rozwiązanie. Ułatwiałoby to wiele, ale czy takie tabele nie byłyby zbyt wielkie.

Z drugiej strony (jak mawial skrzypek na dachu) - myślę, że nazwa modulu powinna znaleźć się na końcu nazwy tabeli. To ułatwiłoby administrowanie wszystkimi kategoriami we wszystkich tabelach.

Co o tym myślisz. Które rozwiązanie Ci się podoba?

roodee napisał(a):syriusz napisał(a): Celem pierwszej tabeli jest (...) numeru kolejnego kategorii dla wskazanego właściciela kategorii, numer porządkowy (...) wytlumacz mi po co 2 numery? [...] roodee napisał(a): syriusz napisał(a):Ostatnia tabela określa cały mechanizm powiązań pomiędzy kategoriami. Tabela powinna dać możliwość pokazania relacji pomiędzy kategoriami z uwzględnieniem właściciela katalogów. po co uwzgledniac wlasciciela katalogow? i tak nie powiaze nie swojej kategorii ze swoja, bo nie bedzie mial do innych dostepu....

Słowo właściciel występuje to w znaczeniu loginu odpowiedzialnego za dany serwis, a niekoniecznie rzeczywistego uzytkownika. Może przecież się zdarzyć, że jeden użytkownik posiada kilka serwisów.

Sczytywane parametry ze ścieżki dostępu powinny (moim zdaniem) mieć numery kolejne dla danego własciciela, by w wyniku oprogramowania nie została wczytane elementy z innego niezależnego serwisu pracujacego na tej samej bazie danych, chyba, że taka jest wola właściciela.

Dlatego inna numetracja jest dla włąściciela, a inna dla konserwatora i administratora systemu. Zresztą i tak musi być ID dla całości. O ile w przypadku jednego właściciela jest to jeden i ten sam numer, o tyle w przypadku wielu właścicieli te numery pokrywać się nie będą.

Dlatego relacje mają występować tylko pomiedzy kategoriami właścicieli. Jedynie na poziomie administratora widoczne mogą być wszystkie kategorie wszystkich właścicieli.
roodee napisał(a):syriusz napisał(a): Celem trzeciej tabeli jest zapewnienie wielojęzyczności nazw kategorii z jednej strony, a wskazaniem modułu/pliku wywoływanego z drugiej strony. Założono, że w zależności od języka może istnieć konieczność wywołania innego pliku. Kategoria powinna mieć możliwość wpływania na wybór szablonów. Być może wybór pliku będzie wpływał na wybór szablonu. nadal nie rozumimem po co wielojezycznosc? czy nie mozna tego zrobic nastepujaco:
definiujemy kilka kategorii, kazda dla innego jezyka serwisu. do tych kategorii dolaczamy tylko to co mamy w danym jezyku. i odpada kombinowanie.
wg sposobu zaprezentowanego przez Ciebie, kazda kategoria musi miec wpisy dla kazdego jezyka. Czyli przy 10 jezykach dla kazdej kategorii trzeba dodac 10 wpisow w baze... troche duzo i jak dla mnie niepotrzebne...

Niezupełnie, gdyż brak subkategorii w danym języku spowoduje, że nie będzie istniał do niej link, ewntualnie o długości 0 ("zero") znaków. Metoda Twoja powoduje, że w przypadku serwisów wielojęzycznych rozbudowuje Ci się cała baza. W tym przypadku masz doczynienia z relacją pomiędzy bazami. Nazwa kategorii w danym języku istnieje, gdy jest jej odpowiednik w tym języku. Są natomiast przypadki, że będzie wola poinformowania, że materiał jest dostępny w innych językach i jeśli nie ma go w języku oczekiwanym przez użytkownika, to otrzyma materia ł w języku domyślnym i listę dostępnych wersji językowych. To tak jak w przypadku PHP manualu.
roodee napisał(a): co do szablonow to sie zgadzam - kazda kategoria musi miec swoj szablon, w wypadku NULL na przyklad, szablon domyslny
Bazuje to nieco na Twoim pomysle... Tylko nie do końca rozumiem Twojej idei. Jakoś nie wyobrażam sobie, by można wszystko umieścić w bazie. Obrazki, część zmiennych po prostu się nie da. Mozna oczywiście umieścić informacje o ścieżce do części gifów, kolorach domyślnych, tytule, sloganie, etc.
roodee napisał(a):syriusz napisał(a):Tabela powinna zapewnić:

* możliwości przyporządkowania jednej kategorii głównej wielu subkategorii

* możliwość przyporządkowania każdej subkategorii do wielu kategorii głównych maslo maslane

A ja tak długo nad tym myślałem... W obu przypadkach mamy kategorie i subkategorie, ale w pierwszym jest informacja, że kategorie w niższym poziomie mogą mieć wiele subkategorii, a w drugim że subkategoria może mięć na wyższym poziomie wiele kategorii.

Czyli w jednym przypadku relacja jeden do wielu, a w innym wiele do jednego.

Czy to jest masło maślane?
syriusz napisał(a):
Bazuje to nieco na Twoim pomysle... Tylko nie do końca rozumiem Twojej idei. Jakoś nie wyobrażam sobie, by można wszystko umieścić w bazie. Obrazki, część zmiennych po prostu się nie da. Mozna oczywiście umieścić informacje o ścieżce do części gifów, kolorach domyślnych, tytule, sloganie, etc.

szczerze mowiac to caly czas sie nad tym zastanawiam.
a jako ze tabela templates nie jest z niczym powiazana to wszystko mozna zmienic i pod koniec projektu. na przyklad w templates.body zamiescic tylko link do formularza

nad tym sie zastanowie pod koniec pracy, bo to akurat najmniej wazne...

teraz mysle nad bardziej zaawansowanym rozwiazaniu menu. (menu glowne pojawia sie w jednym miejscu, menu dodatkowe w innym itd....) tylko nie wiem do konca jak sie za to zabrac...
Obawiam sie, ze watek raczej nie aktualny. Ale mam pytanie do baz danych, wiec moze ktos bedzie znal odpowiedz.

Pracuje aktualnie na MySQL 5 i pojawil mi sie pewien problem do rozwiazania. Mianowicie musze na czas trwania polaczenia utworzyc aliasy do tabelek znajdujacych sie w bazie danych. Dodatkowo aliasy musza byc widziane tylko dla tego jednego polaczenia. Ktos ma pomysl?
Ale w czym problem?

Jak było dotychczas? A jak musisz teraz to zapisywać?
Problem juz rozwiazany. Generalnie opisze dokladniej o co chodzi. Robilem wersje wielojezykowa strony i idea byla taka, by dla kazdej wersji jezykowej robic osoba tabelke (z powodow ktorych tutaj nie bede opisywal). Nie chcialem jednak zmieniac kodu zrodlowego strony, a szczegolnie edytowac zapytan.

Jak rozwiazalem... przy starcie strony tworzone sa tebele tymczasowe, nastepnie zapleniam je danymi z aktualnych tabel, a zapytania SELECT kieruje do tabel tymczasowych

W ten sposob wszystko chodzi pieknie, co ciekawe... uzyskalem przyspieszenie dzialania strony o jakies 10 - 30%
No proszę

Przyznam, że rzecz brzmi tak zagadkowo, że nadal budzą się we mnie obawy. Wciąż się boję niespodzianek w MySQL5. Bo nie mam pewności czego się spodziewać. Zreszta PHP5 to jeszcze inna ciekawostka. To już dla wielu programów kompletna katastrofa.

Nie wiem z czym wiązał się Twój problem i konieczość aliasów...
I to mnie bardzo bardzo bardzo bardzo bardzo niepokoi...
Nie bylo mnie przez jakis czas

MySQL5 i PHP5 wnosza duzo nowych, ciekawych nowinek. Jednak jak dla mnie przejscie na nowsze wersje nie sprawily zadnego problemu, a wrecz obiektowosc w PHP5 bardzo dobrze przyjela sie w moich aplikacjach.

Problem ktory ja jednak napotkalem mozna bylo odniesc do PHP4 i MySQL4. Jego podstawa bylo moje lenistwo...

W gotowej stronie musialem wprowadzic obsluge wielu jezykow, ale w taki sposob by tabelki dla roznych jezykow byly rozdzielone (osobno dla PL, osobno dla RU itd.). Nie chcialem jednak bawic sie w zmiane we wszystkich mysql_query tabelki w zaleznosci od wersji jezykowej. Stad tez narodzil sie (po wielu ewolucjach) pomysl, by na poczatku wywolania skryptu stworzyc dla danego polaczenia tabele tymczasowa, skopiowac do niej dane z odpowiednika w wersji jezykowej i odnosic sie juz w zapytaniach do tabeli tymczasowej.

Juz troszeczke rozjasnilem temat?

ps. Co do PHP5 to krew mnie powoli zaczyna zalewac jak przygotowywane strony (za nie male pieniadze) mozna uruchomic tylko w PHP4 :/
Co do Twego problemu to znalazalem w necie takie rozwiązania :

widok i odpowiednie uprawnienia -- ( !!per user, a nie per
session )
l codeDivStart() create temporary table t2 select * from t1

MNie czekan np. przeniesienie forum na MySQL5 i PHP5. No bo w koncu trzeba to zrobić i juz czuję jak mi coś w dołku ściska. Jak na razie robię wszystko, by nie to odwlekać jak najdalej
Dzieki za kod, wynalazlem tez go jakis czas temu Przejscie na MySQL5 i PHP5 nie jest takie strasznie. Z MySQL5 nie ma zadnych problemow. W PHP5 czesc funkcji zachowuje sie troszke inaczej, ale sa to sporadyczne przypadki

Zawsze moge pomoc przy ewentualnych problemach

W PHP5 cenie sobie najbardziej jego obiektowosc - znacznie i zdecydowanie ulatwia ona prace
No i ja z kolejnym pytaniem Moze wiesz cokolwiek na temat kontroli typow w PHP? Chodzi o to, by ustawic, ze co pobierane z bazy danych jest intem, a co innego char'em?

Pozdrawiam

: 03. Baza danych

Pary_anime

Linki

Cytat