Pary_anime
1. Projekt dotyczy pelnej obslugi strony przez www z wykorzystaniem
PHP oraz bazy danych.
2. Glowne zalozenie to nieograniczone zagniezdzanie kategorii.
realizowane w systemie parent-child
nazwy kategorii poprzez xxxyyzzz (1,2,3 stopien) lub xxx-yy-zzzz.
drugi jest ciekawszy bo nie ma ograniczenia ilosci, tylko wyrazenia
wyszukujace trzeba zbudowac
3. mozliwosc przyporzadkowywania artykulu do wielu kategorii.
tabela (relacja z articles):
article_category:
article_id | category_id
4. strona zlozona z niezaleznych elementow, identyfikowanych w
szablonach jako bodyXX gdzie xx - numer elemetnu.
tabela:
articles:
article_id | article_subiect | article_body | article_destiny
gdzie article_destiny okresla w ktory element bodyXX ma byc
ladowany artykul.
5. czasem jednak - wg checi dodajacego artykul - klikniecie na dany
artykul moze zmieniac kilka elementow bodyXX
tabela:
article_relations:
article_id | body1 | body2 | ... | bodyXX
gdzie body1, body2 itd. okreslaja co w te miejsca ma byc ladowane:
article - dany artykul
default - pozostaje bez zmian
numer - laduje w to pole artykul o danym numerze
6. mozliwosc osobnego szablonu dla kazdej kategorii - realizowane za
pomoca klasy podobnej to template - sami napiszemy.
6a. utworzenie szablonu strony, pobieranego z bazy w zaleznosci od
wybranej kategorii
tabela:
category_templates
cat_id | cat_template
cat_styles - zawartosc szablonow i styli
jesli wartosc default - korzysta z domyslnych.
cat_id - jesli wiersz z danym id istnieje - laduje arkusze,
jesli nie istnieje - laduje style domyslne (czyli z cat_id = o)
6b. Kilka domyslnych szablonow zrobi moj kumpel Look - powiedzial ze
na przyszly tydzien, wiec beda za miesiac.
7. administracja użytkownikami - nie mam pomysłu jak bardzo sie w to zagłębiać (robić rejestracje? czy tylko dla adminow)
jak cos komus przyjdzie do glowy - dopisujcie[/b]
roodee napisał(a):1. Projekt dotyczy pelnej obslugi strony przez www z wykorzystaniem
PHP oraz bazy danych.
jakiej i czemu?
roodee napisał(a):
2. Glowne zalozenie to nieograniczone zagniezdzanie kategorii.
realizowane w systemie parent-child
parent, zaglebienie, rodzic pierwotny.
roodee napisał(a):
[..]
3. mozliwosc przyporzadkowywania artykulu do wielu kategorii.
tabela (relacja z articles):
wielokrotna. wiec jeszcze jedno id.
roodee napisał(a):
article_category:
article_id | category_id
4. strona zlozona z niezaleznych elementow, identyfikowanych w
szablonach jako bodyXX gdzie xx - numer elemetnu.
oraz szerokosc elementu.roodee napisał(a):
[..]
[ Wulgaryzmom STOP (Ustawa o języku polskim) o szablonach. ]
7. administracja użytkownikami - nie mam pomysłu jak bardzo sie w to zagłębiać (robić rejestracje? czy tylko dla adminow)
pozimy. proste operacje na bitach i jusz.
ps
u mnie system szablonow to 6 tabelek. mysle ze prosciej sie nie da jesli modularne.
roodee napisał(a):
nazwy kategorii poprzez xxx-yy-zzzz.
[ciach] nie ma ograniczenia ilosci, tylko wyrazenia
wyszukujace trzeba zbudowac
Dzieki temu otrzymasz poziom zagniezdzenia. Jak ma(moze) to wygladac juz podalem na p.c.l.php
Cytat:6b. Kilka domyslnych szablonow zrobi moj kumpel Look - powiedzial ze
na przyszly tydzien, wiec beda za miesiac.
Czekamy... czekamy!
Cytat:7. administracja użytkownikami - nie mam pomysłu jak bardzo sie w to zagłębiać (robić rejestracje? czy tylko dla adminow)
Ja jestem pod wrazeniem phpBB (niniejsze forum jest na tym ustawione). Trzeba by ten mechanizm wygrzebac, albo skads wziac. Jestem pod duzym wrazeniem. Daje uprawnienia nie tylko przyporzadkowane uzytkownikom, ale i do poszczegolnych forow. Brakuje mi tylko mozliwosci przyporzadkowania uprawnien bezposrednio do kategorii.
[/quote]
Cytat:roodee napisał(a):6b. Kilka domyslnych szablonow zrobi moj kumpel Look - powiedzial ze na przyszly tydzien,
wiec beda za miesiac.[/b]
gon sie;-)
sam powidziales, ze moga byc za miesiac ;-)
look^
--
ja(a)look.art.pl
look^ napisał(a):gon sie;-)
sam powidziales, ze moga byc za miesiac
siem zdenerwowal chlopak
Cytat:2. Glowne zalozenie to nieograniczone zagniezdzanie kategorii.
realizowane w systemie parent-child
nazwy kategorii poprzez xxxyyzzz (1,2,3 stopien) lub xxx-yy-zzzz.
drugi jest ciekawszy bo nie ma ograniczenia ilosci, tylko wyrazenia
wyszukujace trzeba zbudowac
a jak tu zrobic nieograniczone zagniezdzanie?
przeciez jesli z zalozenia kazda kategoria ma fragment xxx (niech bedzie 999 kombinacji cyfr (zalozenie nieograniczone juz zlamane)) to przy 50 zagniezdzeniach masz juz 150 znakow do opisania kategorii
a jesli domorosly_programista_psycholog postanowi zaglebic sie z 90 poziomow glebiej (czasem inteligencja ludzka moze powalic...) to nawet pole VARCHAR nie obsluzy takiego indexu. I co wtedy?
moze poglowkowac jednak nad auto_increment, przy INT(10) mamy juz miliard (?) kombinacji
..
tak se pomyslalem...
rafal
nicpek napisał(a):Cytat:2. Glowne zalozenie to nieograniczone zagniezdzanie kategorii.
realizowane w systemie parent-child
nazwy kategorii poprzez xxxyyzzz (1,2,3 stopien) lub xxx-yy-zzzz.
drugi jest ciekawszy bo nie ma ograniczenia ilosci, tylko wyrazenia
wyszukujace trzeba zbudowac
a jak tu zrobic nieograniczone zagniezdzanie?
przeciez jesli z zalozenia kazda kategoria ma fragment xxx (niech bedzie 999 kombinacji cyfr (zalozenie nieograniczone juz zlamane)) to przy 50 zagniezdzeniach masz juz 150 znakow do opisania kategorii
a jesli domorosly_programista_psycholog postanowi zaglebic sie z 90 poziomow glebiej (czasem inteligencja ludzka moze powalic...) to nawet pole VARCHAR nie obsluzy takiego indexu. I co wtedy?
moze poglowkowac jednak nad auto_increment, przy INT(10) mamy juz miliard (?) kombinacji
wlasnie tutaj problem
codeDivStart() pierwsza mozliwosc:
01
04
05
02
06
03
mamy niewielkie liczby, zero ograniczen (no - kilka miliardow kategorii sie nie zmiesci) , ale nie ma wyraznej struktury i przez to trudniej odnajdywac kategorie podrzedne
codeDivStart() druga możliwosc
01
0105
010507
02
0203
04
0406
id podkategorii na "glebokosci" = 30 ma juz 90 znakow (przy ograniczeniu do 99 podkategorii)
ulatwia to bardzo wyszukiwanie ale ograniczy mozliwa glebokosc podkategorii oraz ilosc samych kategorii na jednym poziomie
codeDivStart() trzecia mozliwosc
01
01-05
01-05-07
01-05-07-1234
02
02-03
04
04-06
id kategorii jeszcze bardziej sie wydluzy, ale znika problem ograniczenia ilosci kategorii na jednym poziomie.
mimo wszystko bylbym za rozwiazaniem 3 (chyba ze jest lepsze), bo nie widzialem jeszcze serwisu, ktory mialby poddzialy 50 stopni wglab i na kazdym stopniu kilkaset artykulow
Cytat: codeDivStart() pierwsza mozliwosc:
01
04
05
02
06
03
mamy niewielkie liczby, zero ograniczen (no - kilka miliardow kategorii sie nie zmiesci) , ale nie ma wyraznej struktury i przez to trudniej odnajdywac kategorie podrzedne
struktura dla ciebie malo czytelna, ale prosta jak drut do wyszukiwania i zarzadzania, najgorzej jest z usuwaniem w glab (szukam sposobu szybkiego i malo_zasobo_zernego..)
o tej zasadzie juz rozmawialismy. rekord ma kolejny id i id_parent.
szukasz wszystkiego pod nim? przeszukujac liczby wybierasz te rekordy ktore maja id_parent = szukany_id. i finito..
tylko jak to usunac w glab? bo mi petle nie chca rekurencyjnie dzialac. moze ktos ma zrodlo funkcji ktora dziala na takiej zasadzie, to chetnie sie zapoznam w celu wyrwania pomyslu na to..
Cytat:
codeDivStart() druga możliwosc
01
0105
010507
02
0203
04
0406
id podkategorii na "glebokosci" = 30 ma juz 90 znakow (przy ograniczeniu do 99 podkategorii)
ulatwia to bardzo wyszukiwanie ale ograniczy mozliwa glebokosc podkategorii oraz ilosc samych kategorii na jednym poziomie
sposob niezly, ale w dynamicznym serwisie szybko moze sie skonczyc zakres. user projektu bedzie dodawal i usuwal kategorie, a wtedy bez funkcji ktora moze wstawiac nowe kategorie w miejsce usunietych, kombinacja mozliwosci szybko moze sie wyczerpac. Z drugiej strony wstawianie w miejsce usunietych niesie ze soba mozliwosc utraty ciaglosci,nie mowiac o teroetycznie 'niemozliwym' do napisania systemie zarzadzania taka operacja.
wedlug mnie, sposob jeszcze mniej fortunny niz poprzedni..
Cytat:
codeDivStart() trzecia mozliwosc
01
01-05
01-05-07
01-05-07-1234
02
02-03
04
04-06
id kategorii jeszcze bardziej sie wydluzy, ale znika problem ograniczenia ilosci kategorii na jednym poziomie.
w jakiejs madrej publikacji wyczytalem, ze wyszukiwanie po indeksach cyfrowych (patrz pomysl nr. 1) jest duzo efektywniejsze i szybsze niz z zastosowaniem LIKE. chyba cos w tym jest.
a ze ma to byc projekt profesjonalny i nietuzinkowy, znajdzmy jakis kompromis.
wedlug mnie sposob pierwszy jest najlepszy i najmniej ograniczony pod warunkiem opracowania dobrego systemy usuwania drzewa kategorii wglab. u mnie funkcja dziala do drugiego poziomu. znaczy nie potrafi wrocic (nie kontynuuje) do petli nadrzednej po zaglebieniu sie jakas glebsza.
Cytat:mimo wszystko bylbym za rozwiazaniem 3 (chyba ze jest lepsze), bo nie widzialem jeszcze serwisu, ktory mialby poddzialy 50 stopni wglab i na kazdym stopniu kilkaset artykulow
ja tez nie widzialem, ale jesli kiedys ten system wykorzysta jakas interia lub inny onet?
skad wiesz co chlopakom wpadnie do glowy?
sie napisalem...
Cytat:caly ten powyzszy tekst...
qrde, nie zalogowalem sie...
jakby co to mnie opieprzac, ja to splodzilem..
narazie
Anonimek napisał(a):
struktura dla ciebie malo czytelna, ale prosta jak drut do wyszukiwania i zarzadzania, najgorzej jest z usuwaniem w glab (szukam sposobu szybkiego i malo_zasobo_zernego..)
piszac o czytelnosci mialem na mysli wlasnie prostote wyszukiwania (LIKE)
tak wiec pozostajemy przy rozwiazaniu pierwszym (auto_increment)
a rekurencja do wyszukiwania to albo:
wyszukiwanie wszystkich w glab i ladowanie wszystkich category_id do tablicy jakiejs i potem usuwanie wszystkiego
albo rekurencja:
delete ($arg)
wyszukiwanie wszystkich gdzie parent_id = $arg i uruchamianie f_cji z kazdym wynikiem wyszukiwania
kasowanie poszczegolnych kategorii z category_id = $arg
f-cja zadziala tak ze najpierw uruchomi sie ilestam razy az dojdzie do konca i potem od konca zacznie usuwac kategorie...
przez noc albo jutro postaram sie napisac cosik
Cytat:piszac o czytelnosci mialem na mysli wlasnie prostote wyszukiwania (LIKE)
tak wiec pozostajemy przy rozwiazaniu pierwszym (auto_increment)
a rekurencja do wyszukiwania to albo:
wyszukiwanie wszystkich w glab i ladowanie wszystkich category_id do tablicy jakiejs i potem usuwanie wszystkiego
albo rekurencja:
delete ($arg)
wyszukiwanie wszystkich gdzie parent_id = $arg i uruchamianie f_cji z kazdym wynikiem wyszukiwania
kasowanie poszczegolnych kategorii z category_id = $arg
f-cja zadziala tak ze najpierw uruchomi sie ilestam razy az dojdzie do konca i potem od konca zacznie usuwac kategorie...
przez noc albo jutro postaram sie napisac cosik
mysle ze wlasnie ten sposob bedzie najlepszy dla bazy.nurtowalo mnie t kasowanie i niedzialanie funkcji nad ktorymi siedzialem wczoraj do 3 w nocy. sprobuj cos napisac, zapoznam sie z tym i zoptymalizujem
ja nie mam narazie czasu (dzisiaj) wiec chetni jutro spojrze.
co do bazy, to do zarzadzania jest to chyba najlepszy sposob. zaglebie sie w gotowe rozwiazania (phpnuke, ariadne) i zobaczymy jak tam tojest rozwiazane. pozatym jak wspomnialem, wszystkie indeksy robisz na polach INT(10). smiertelnik nie jest w stanie tego zapchac...
A może by tak wykorzystać więzy integralno¶ci? Ponoć w jakie¶ tabeli w mysql można założyć kaskadowe kasowanie.
Po co więc pisać to ręcznie? No. chyba, że dla sportu.
Odno¶nie założeń dotycz±cych kategorii.
Ogromn± zalet± systemu id/id_nadrzedne jest elastyczno¶ć (pisałem o tym na pcl.php).
Duż± wad± jest liczenie "ile jest artykułów w kategorii" (ł±cznie z podkategoriami). Można zatem zrobić tak:
id_kategorii | id_nadrzedne | ilosc_art
przy czym ilosc_art to ilo¶ć artykułów we wszystkich kategoriach podrzędnych. Dodanie b±dĽ usunięcie artykułu powoduje przeliczenie pola ilosc_art we wszystkich kategoriach nadrzednych.
ms napisał(a):A może by tak wykorzystać więzy integralno¶ci? Ponoć w jakie¶ tabeli w mysql można założyć kaskadowe kasowanie.
Po co więc pisać to ręcznie? No. chyba, że dla sportu.
no wlasnie, rozwiazanie ma byc uniwersalne, wiec nie bardzo.
ladowane moduly maja byc zalezne od zastosowanej bazy danych, ale chyba nie bedziemy tez robic w zaleznosci od wersji.
przy innych bardziej zaawansowanych mozna stosowac ciut inna filozofie i jesli inna to umozliwia, to swietnie. w mysql'u przy zalozeniu wersji starszych (ktore moga widniec na serwerach przyszlego uzytkownika) taki numerek nie przejdzie
niefajnie.
musze na kilka dni wyjechac - jakies chorobsko mnie dopadlo i jadem na badania...
bede w domu to cos popisze i wysle, tylko nie smiac sie jak nie bedzie dzialalo bo nie mam tam neta i to co zrobie to bedzie robota "na pale" w notatniku
Dlaczego twierdzisz, ze ms napisał(a):Duż± wad± jest liczenie "ile jest artykułów w kategorii" (ł±cznie z podkategoriami). Można zatem zrobić tak:
id_kategorii | id_nadrzedne | ilosc_art
przy czym ilosc_art to ilo¶ć artykułów we wszystkich kategoriach podrzędnych. ?
Moje doswiadczenia ida w innym kierunku. Czesto zdarza sie, ze szybszym rozwiazaniem jest kasowanie artykułów bezpo¶rednio z bazy danych. Wowczas nigdy nie bedziesz pewien ile artykułów naprawde jest. Szybciej bedziesz mial bledna liczbe artykulow niz Ci sie wydaje.
Jest i inny problem... Brak tranzakcji MySQL. Owszem mozna ten problem ominac, ale zawsze moze sie zdarzyc nieprzewidziany blad, ktory spowoduje, ze liczba artykulow w ww. tabeli bedzie rozna od rzeczywistej.
Wciaz mysle, ze rownozedny system kategorii zalatwic moze ten problem, tzn
id_kategorii | id_nadrzedne | kategoria_ksiegowa
Wyjasniam czym jest dla mnie kategoria ksiegowa. Pewnie ktos zna lepsza nazwe. Wyglada ona tak:
A-B-C-D-E-F-..........
gdzie:
A - kategoria najwyzszego poziomu
B- kategoria podrzedna w stosunku do A
C- kategoria podrzedna w stosunku do B
D- kategoria podrzedna w stosunku do C
E- kategoria podrzedna w stosunku do D
itd
Daje Ci to mozliwosc zliczania artykulow w dowolny sposob przy pomocy finkcji count(). A dodatkowo masz mozliwosc obserwowania stopni zagniezdzenia
nicpek napisał(a):
no wlasnie, rozwiazanie ma byc uniwersalne, wiec nie bardzo.
ladowane moduly maja byc zalezne od zastosowanej bazy danych, ale chyba nie bedziemy tez robic w zaleznosci od wersji.
przy innych bardziej zaawansowanych mozna stosowac ciut inna filozofie i jesli inna to umozliwia, to swietnie. w mysql'u przy zalozeniu wersji starszych (ktore moga widniec na serwerach przyszlego uzytkownika) taki numerek nie przejdzie
Zaraz, zaraz. Przecież "System Obsługi Stron WWW" nie powstanie jutro (ani pojutrze), tylko za czas jaki¶. Wiesz jaka będzie wtedy wersja mysql?
A może zrobić system obsługiwany przez mysql w wersji 1.0? Nie mozna przesadzać. Jeżeli obecny mysql umożliwia więzy integralno¶ci, nie widzę powodu aby ich nie używać.
Sl@o napisał(a):Dlaczego twierdzisz, ze ???
Probuję obronić pomysł na rozwi±zanie katagorii poprzez
id/id_nadrzedne
rezlizowane na polach typu int.
Wykazuję jedyn±, znan± mi słab± stronę tego rozwi±zania i podpowiadam rozwi±zanie.
Sl@o napisał(a):
Moje doswiadczenia ida w innym kierunku. Czesto zdarza sie, ze szybszym rozwiazaniem jest kasowanie artykułów bezpo¶rednio z bazy danych. Wowczas nigdy nie bedziesz pewien ile artykułów naprawde jest. Szybciej bedziesz mial bledna liczbe artykulow niz Ci sie wydaje.
I to jest wł±snie bł±d. Po to tworzy się w systemach panele administracyjne, żeby nie grzebać "ręcznie" w bazie. Nie widzę też problemu aby dodać funkcję, która przeliczy wszytkie artykuły.
Sl@o napisał(a):
Jest i inny problem... Brak tranzakcji MySQL.
Ba, ale dzięki temu baza jest szybka.
Sl@o napisał(a):
Daje Ci to mozliwosc zliczania artykulow w dowolny sposob przy pomocy finkcji count(). A dodatkowo masz mozliwosc obserwowania stopni zagniezdzenia
A jak w tym przypadku wyobrzażasz sobie przeniesienie drzewa podkategorii do innej kategorii głównej? Albo stworzenie kategorii głównej z podkategorii?
PS.
Jakby co to ostatni niepodpisany post jest mój.
ms napisał(a):Probuję obronić pomysł na rozwi±zanie katagorii poprzez
id/id_nadrzedne rezlizowane na polach typu int.Ja tego nie neguje. A wlasciwie dlaczego int?
ms napisał(a):I to jest wł±snie bł±d. Po to tworzy się w systemach panele administracyjne, żeby nie grzebać "ręcznie" w bazie. Nie widzę też problemu aby dodać funkcję, która przeliczy wszytkie artykuły. Zazwyczaj z shella jest po prostu szybciej. No tu wychodza moje doswiadczenia linuxowe . Faktem jest, ze zazwyczaj koncowy uzytkownik nie musi rozumiec czym jest php, baza dancyh, serwer, etc.
Co do funkcji przeliczajacej... Sl@o napisał(a):A-B-C-D-E-F
daje Ci mozliwosc szybkiego odpowiedzenia ile znajduje sie artykulow
w kategorii:
A wraz ze wszystkimi kategoriami podrzednymi wszystkich poziomow zagniezdzenia
B wraz ze wszystkimi kategoriami podrzednymi wszystkich poziomow zagniezdzenia
C wraz ze wszystkimi kategoriami podrzednymi wszystkich poziomow zagniezdzenia
...etc.
Co mogloby dac wyniki np:
A=5972
B=3511
C=945
D=132
...etc.
Mysle, ze musialaby byc potwornie rozbudowana funkcja i juz lepszy bylby licznik w bazie... Chyba, ze masz jakies rozwiazania, ktore liczyloby szybko.
ms napisał(a):A jak w tym przypadku wyobrzażasz sobie przeniesienie drzewa podkategorii do innej kategorii głównej? Albo stworzenie kategorii głównej z podkategorii?
Hmm. Tu dales mi wiele do myslenia Faktycznie moje doswiadczenia sa raczej z systemami ksiegowymi, biznesowymi, typu sklep, system ksiegowy, etc. Tam pewna systematyka wrecz narzucona jest przez prawo. Mozna oczywiscie cos zmieniac, ale raczej z odpowiednim wyprzedzeniem zdarzen, a nie post factum.
We wskazanym przeze mnie rozwiazaniu stworzenie kategorii głównej z podkategorii i odbywac sie musialoby poprzez zmiane symbolu kategorii. Proponowalem taka budowe tabeli:
Sl@o napisał(a):id_kategorii | id_nadrzedne | kategoria_ksiegowa
W takim przypadku
Sl@o napisał(a):A-B-C-D-E-F-..........
zmieniliby sie np. na
AB-C-D-E-F-..........
i juz masz kategorie wyzej zagniezdzona.
W przypadku calego drzewka trzeba zastosowac funkje zastap()
Nie zalezy mi jednak na usunieciu lub rezygnacji z Twojej propozycji. Jest ona powszechniejsza i lepiej udukumentowana. Widze jednak, ze za oboma metodami sa za i przeciw. Dlatego probuje te medoty pozenic.
A moze kategie_ksiegowa zastosowac pomocnicza (moze nawet w innej tabeli) i zachowac licznik. Wowczas z poziomu administratora bylaby mozliwa kontrola integralnosci bazy?
Cytat:Zaraz, zaraz. Przecież "System Obsługi Stron WWW" nie powstanie jutro (ani pojutrze), tylko za czas jaki¶. Wiesz jaka będzie wtedy wersja mysql?
A może zrobić system obsługiwany przez mysql w wersji 1.0? Nie mozna przesadzać. Jeżeli obecny mysql umożliwia więzy integralno¶ci, nie widzę powodu aby ich nie używać.
wiem ze nie powstanie jutro.
wiadomo, kazdy klient napewno zechce wykorzystac ten system, ale nie kazdemy provider wrzuci najnowsza baze danych. ustalamy minimalne wymagania (apache 1.x, php4.x i mysql 3.x oraz reszte baz) i tego sie trzymamy. jesli system powstanie za pol roku, to dobrze. Kazdy z nas ma gdzies serwer u jakiegos komercyjnego dostawcy. Zrobmy male rozeznanie i dowiedzmy sie, kto ma jakie parametry. Oczywiscie bez 'nazwisk' , wystarcza wersje.
mozna poprosic grupe o sprawdzenie itd.
Nie interesuja nas serwery typu lisy, krasnale i inne tego typu instalowane w zacisznych pieleszach pokoi na poddaszu.
mozemy sprawdzic teraz, wyciagnac wnioski i na podstawie tego tworzyc ustalic co mozna i co nam to daje.
kieruje glownie do Sl@o
widze ze powoli najwazniejszym probleme staje sie ilosc kategorii podkategorii i podpodkategorii.
w sumie to nie wiem dlaczego, mysle ze nie to jest najistotniejsze (mysle ze nawet bardzo malo istotne - czysta statystyka) a wlasnie powiazania. A te najszybciej zadzialaja na prostych niepowtarzalnych indeksach.
tabela kategorii, tabela artykulow i tabela powiazan miedzy artykulem a kategoria. Szybciej wyszukiwac w tym sie juz chyba nie da.
i nie tworzysz pola VARCHAR(255) aby przechowac kilkadziesiat podkategorii, tylko INT(10) na iles tam miliardow kolejnych rekordow. zauwaz tez, ze jesli stworzysz glowna kategorie A, potem kolejne B, C itd. to jesli zechcesz usunac pierwsza (A), to usuniesz i co dalej? napiszesz silnie skomplikowany skrypt ktory sprawdzi jakie litery sie zwolnily i w to miejsce bedzie wstawial nowe? nie do zrobienia. maly krzaczek i relacje sie sypia. przy indeksie auto_increment problem odpada. nie szukasz dziur, nie interesuja cie. predzej kometa walnie w nas niz wykorzystasz mozliwosci dodawania nowych indeksow.
nie wspomne poraz kolejny o predkosci szukania w polach int i cyfrowych indeksach a wyszukiwaniem z zastosowaniem LIKE i nieokreslonych dlugosci (teoretuzyje teraz, nie znam roznicy predkosci, ale juz kilka razy czytalem, aby w skomplikowanych projektach indeksowac a nie korzystac a like..)
baza szuka po indeksach, porownuje liczby ze soba i na podstawie tego wyrywa podkategorie lub jesli zwrocilo 0 wierszy to artykul). koniec.
usuwasz kategorie, to usuwasz z tabeli kategoria powiazania miedzy nia a zaleznymi kategoriami/artykulami i usuwasz jej powiazanie z kategoria powyzej. koniec.
teraz tylko musimy zrobic usuwanie podkategorii i juz
Sl@o napisał(a):Dlatego probuje te medoty pozenic.
Zasadniczo jestem zwolennikiem teorii "albo rybka albo pipka", ale zawsze można spróbować.
nicpek napisał(a):kieruje glownie do Sl@o
Co za krzywy usmiech
Cytat:widze ze powoli najwazniejszym probleme staje sie ilosc kategorii podkategorii i podpodkategorii.
w sumie to nie wiem dlaczego, mysle ze nie to jest najistotniejsze (mysle ze nawet bardzo malo istotne - czysta statystyka) a wlasnie powiazania. A te najszybciej zadzialaja na prostych niepowtarzalnych indeksach....
Chcialem, by zostalo stworzone cos bardziej uniwersalnego.
Od dawna mysle o stworzeniu w OpenSource sytemu biznesowo-ksiegowego dla malych i srednich firm internetowych. Cos w rodzaju malego CRM (zbieralem w tym czasie dokumentacje i sam robilem nowa). W takim systemie uklad kategorii musi byc zblizony do modelu zaproponowanego przeze mnie. Czy mam racje?
Byc moze lepiej w takim razie stworzyc dwa systemy menu, chociaz myslalem, ze to strata czasu.
Za system menu w tym akurat projekcie pokrajac sie nie dam. Sa inne rzeczy, ktorych bede bronil do upadlego. Ale mysle, ze Was przekonam
Jesli jestescie pewni, ze taki system zalatwi problem i wykona wszystko o czym wspomianlem, to juz nie bede szukal dziury w calym, a sie wezme za standard kodowania.
Co myslicie o temacie-ogloszeniu? Byc moze lepiej zorganizowaloby to prace. Pojawic moglyby sie tematy blokowane, gdzie gromadzilaby sie dokumentacja.
