ďťż
Podstrony
|
telcocafeJestem w trakcie pisania systemu CMS, jednak mam problem.Wszystko musi być oparte o pliki, a nie o bazę danych. Sęk w tym, że nie mam optymalnego i wydajnego pomysłu na rozwiązanie tego. Głównie chodzi o przechowywanie tzw. notatek, które mogą pisać użytkownicy (a nie będzie ich mało) i właśnie bazę userów (wartości typu login, hasło, miasto, o sobie itp.). Myślałem nad przechowywaniem użytkowników w jednym katalogu, każdego w osobnym pliku z IDem w nazwie (np. user24.php) o przykładowej konstrukcji:<? $nick='admin'; $pass=''; //np. hash md5() $o_sobie="przykladowy\r\nopis"; ?> Taka metoda będzie IMO bezpieczniejsza od bazy na np. XML. Ale czy przy liczbie użytkowników sięgającej kilku(dziesięciu) tysięcy, to rozwiązanie będzie optymalne i w miarę wydajne? Czy taka duża ilość plików nie będzie komplikacją? A może rozdzielić profile do katalogów "userA", "userB" ... "userOTH" ? A może przechowywać ich listę w jednym pliku (co wydaje mi się nieoptymalne przy dużej ilości danych) ? I czy XML jest wydajniejszy/bezpieczniejszy? Co radzicie? A może macie lepsze pomysły na rozwiązanie? jest wiele sposobów na przechowywanie danych jednak chyba xml byłby dobry ale spróbuj najpierw przechowywać dane tak: mietek|miecio123 lolek|lolek123 etc. do teksów 'o sobie' możesz tworzyć pliki w jakimś folderze, gdzie nazwa będzie wskazywała na nazwę użytkownika zaś jego zawartością będzie ta treść. Najlepiej według mnie przechowywać dane userów w jednym w pliku php: <?php die('Brak dostepu'); ?> 1|nazwa1|... 2|nazwa2|... chyba xml byłby dobry Dlaczego? ale spróbuj najpierw przechowywać dane tak: mietek|miecio123 lolek|lolek123 Taki sposób jest IMO na prawdę mało wydajny, szczególnie przy liczbie userów rzędu kilku tysięcy użytkowników. Poza tym, ile roboty będzie z explode() i tworzeniem innych zmiennych... A mi na prawdę zależy na jak najbardziej optymalnym kodzie. do teksów 'o sobie' możesz tworzyć pliki w jakimś folderze, gdzie nazwa będzie wskazywała na nazwę użytkownika zaś jego zawartością będzie ta treść. Dostałem dziś info o podobnym pomyśle, jednak ilość różnorodnych pól, różnego typu i tworzenie nowej pary plików nie będzie jakaś super. A nawet jakbym musiał owe dane przechowywać w jednym pliku, to pomyślmy... 1k userów, po jednym zdaniu (~50 znaków) plus nazwy zmiennych itp. to dajmy 60 znaków. Łącznie ok. 60kb. Może to nie jest jakaś ogromna waga pliku, ale przy powiększającej się ilości użytkowników może być problem... (...) Czemu wy polecacie metodę z explode() ? W czym jest wydajna? I biorąc dla przykładu powyższy opis, to linijka z profilem ~500 znaków, co dla 1k userów będzie niemalże pół megabajta... a z tym już mogą być problemy... Ogólnie wizja trzymania wszystkiego w jednym pliku jakoś mi się nie podoba... A do tego to explode... nie wiem :< Jeśli się mylę, poprawcie mnie... @down: o tym także już myślałem. BTW Nie wiem, czy można osiągnąć publikę kilkutysięczną przy pracy na plikach, ale nie ingeruję w to A ja od zawsze myślałem, że strona jest (bądź nie) popularna przez treści, które publikuje... Może się pomyliłem... No jasne! Przecież zwykły, szary user najpierw sprawdza, czy dane są przechowywane są na plikach, czy też nie! Dopiero później zastanawia się, czy wejść/korzystać ze strony... Użytkownik DJ_ProG edytował ten post 29 listopad 2007, 12:52 Ja podsunę pomysł YoYo.pl. Przechowują oni dane stron w tej postaci, np.: folder/a/n/anastazy. Jest to dobre rozwiązanie jeśli pracujesz na plikach i musisz stworzyć ich wiele. W jednym folderze nie tworzy się zbyt wiele plików i wyszukiwanie odpowiednich jest szybkie. Ja dodatkowo korzystam z serialize i unserialize by nie męczyć się z pętlami... BTW Nie wiem, czy można osiągnąć publikę kilkutysięczną przy pracy na plikach, ale nie ingeruję w to :) Poczytaj o mechanizmach jakie są używane przez bazy danych. Jak one zapisują pliki. Najłatwiej i najlepiej w php to będzie robić zapisując każdego użytkownika do osobnego pliku w postaci zserializowanej tabeli (lub obiektu). Nie jest to miłe i ładne, poza tym takie pliki by zajmowały stosunkowo dużo miejsca. Btw, jeśli bazy danych nie chcesz używać bo jej nie masz, to może użyj bazy typu SQLite? Ona operuje na jednym pliku, nie trzeba mieć osobnego serwera i jedyne co potrzebne to wsparcie dla sqlite w php. Pomysł z include - fatalny. Jesteś pewien że jeden user nigdy nie będzie chciał obejrzeć innego? Co się stanie gdy zrobisz taki include dwa razy dla dwóch różnych userów? Ostatnia sprawa: "piszę cms" + "musi być na plikach". Coś tu nie gra, nie sądzisz? Jak piszesz na poważnie to zrób jeden interfejs bazy danych + różne sterowniki (pliki, mysql, pgsql, mssql, oracle i cała reszta), i tak to wykombinuj by te same zapytania (np $db->get(..)) przyjmowały te same parametry i dawały te same wyniki, niezależnie od wybranego sterownika. Next, prawdziwa baza danych zawsze będzie wydajniejsza od najsprytniejszego zapisywania na plikach, choćby dlatego że nie musi działać na tym samym komputerze co serwer web :^ co więcej może używać XX komputerów do realizowania zapytania. co do zapisu andreja_aa: folder/a/n/anastazy - to wcale nie musi być scieżka pliku! Oni najprawdopodobniej (prawie na pewno) stosują mod_rewrite (czyli zamiana url według szablonu na odpowiednie zmienne), tak tez działa wikipedia! (dlaczego jak po ....../wiki/ wpiszesz zdsfhbhufbhj to wyskoczy "artykuł zdsfhbhufbhj nie istnieje", oczywiście jakby ta ścieżka była ścieżką pliku to by wyrzyciło strona nie istnieje) Takie wyjaśnienie Pozdr Piotrek Jestem w trakcie pisania systemu CMS, jednak mam problem. Wszystko musi być oparte o pliki, a nie o bazę danych. Jak dla zabawy to odpuść sobie - czym chwalić się z tego nie będzie. Na zlecenie - odpuść sobie, bo zleceniodawca obrażony przyjdzie gdy pliki się posypią. Kiedyś bawiłem się z txtSQL - czyli taki "lepszy" zapis danych w plikach i działało to fajnie na "bazie" kilkunastu kilobajtów, powyżej gwałtownie spadała wydajność i też pare razy posypało się przy pliku około 1 MB. Tak więc doradzane SQLite to najlepsze rozwiązanie w tej okolicy. Poczytaj o mechanizmach jakie są używane przez bazy danych. Jak one zapisują pliki. Rozważałem rózne sposoby i ostatecznie chciałem napisać parser XML, ale i tak jak pomyślałem o zakładanej liczbie odwiedzin i - po prostu - przechowywanych danych, to złapałem się za głowę... Jak piszesz na poważnie to zrób jeden interfejs bazy danych + różne sterowniki (...) Z tym też sporo kombinowałem, ale założenia projektu nie były ustalone przeze mnie - ja miałem to tylko wykonać, więc wszelkie kombinacje z modułami bazodanowymi wymiękały... Btw, jeśli bazy danych nie chcesz używać bo jej nie masz, to może użyj bazy typu SQLite? Ona operuje na jednym pliku, nie trzeba mieć osobnego serwera i jedyne co potrzebne to wsparcie dla sqlite w php. I to uznałem za sensowne rozwiązanie :) Niestety okazało się, że serwer nie obsługuję tego rozszerzenia :kwasny: Next, prawdziwa baza danych zawsze będzie wydajniejsza od najsprytniejszego zapisywania na plikach (...) Jestem tego świadom, dlatego też tutaj zwróciłem się z tym trudnym problemem... Jak dla zabawy to odpuść sobie - czym chwalić się z tego nie będzie. Na zlecenie - odpuść sobie, bo zleceniodawca obrażony przyjdzie gdy pliki się posypią. Gdy wróciłem do rozmowy o przechowywaniu danych (z propozucją SQLite), okazało się, że jednak zleceniodawca nie ma on nic przeciwko bazie (:blink:). W każdym razie teraz pójdzie z górki ;) Uważam temat za zamknięty i dziękuję za merytoryczną pomoc jedynym kompenentnym osobom: Einzeinbleth i Riklaunimowi :) |
|||
Sitedesign by AltusUmbrae. |