[php] Wybór Miejsca Zapisu Danych...

83.17.37.* napisał:

Baza danych SQL jest lepszym rozwiązaniem na przechowywanie danych, jednak ci, którzy jej na swoich kontach nie posiadają nie mogliby korzystać z CMSa. Aktualnie opieram go na plikach tekstowych, lecz poszukuję dobrego rozwiązania, by użytkownik mógł wybrać, gdzie chce przechowywać dane.

Jednym ze sposobów jest napisanie funkcji zapisujących dla różnych elementów. Nie jest to dobre rozwiązanie, ponieważ nie chciałbym ograniczać SQL'a tylko do MySQL (a gdyby było więcej baz do wyboru, ten plik z funkcjami zajmowałby dużo miejsca).

Jakie rozwiązanie proponujecie?
Może ktoś z was ma dobry pomysł?

Pamiętajcie, że do plików zapisywane są zmienne z wartościami, a do SQL'a wartości.

Jak ktoś z was już coś takiego robił lub wie, jak to zrobić - opiszcie to.
Jeśli znasz linka z opisem takiego czegoś - podaj.

80.53.147.* napisał:

Najlepiej stworzyć po prostu odpowiednie klasy z odpowiednimi metodami i po prostu nimi żonglować.

83.17.37.* napisał:

Klas nie używam i nie znam się na nich...

W zależności od wybranej bazy (katalog plików, MySQL, itd.) dołączany(e) będzie(ą) odpowiedni(e) plik(i) z funkcjami.
Do nich będzie należało poprawne sformatowanie danych w celu przekazania ich dalej do bazy lub pliku, poprawne odczytanie... lub po prostu dołączenie pliku (pliki).

Jak proponujecie? Czy ustawienia także powinny być przechowywane w bazie danych, gdy użytkownik wybrał SQL? Gdyby zawsze były w plikach tekstowych, byłoby prościej, bo tylko dołączyć je funkcją INCLUDE (w przypadku SQL będzie trzeba dodatkową funkcję odczytującą i zamianę wartości na zmienne).

Co muszę jeszcze wiedzieć, o czym muszę pamiętać pisząc te funkcje?

83.30.8.* napisał:

niby idziesz w dobrym kierunku ale, nie do konca.

muisz stworzyc warstwe abstrakcji pomiedzy magazynem danych a twoja aplikacja. a to oznacza ze musisz to zrobic dwupoziomowo.

na poczatku piszesz biblioteke podstawowych operacji dla plikow, mysql'a itd... czyli pobranie danych (selecty, albo fgetsy), zapisanie danych (inserty, fputsy), moze jakies transakcje itd.

majac bibliotke z funkcjami ktore robia to samo dla roznych magazynow danych, mozesz zrobic biblioteke wyzszego poziomu, ktora bedzie korzystala z tych funkcji ktore napisales wczesniej. ta funkcja wywolywalaby odpowiednia funkcje prymitywna w zaleznosci od konfiguracji (sql, pliki).

w ten sposob w aplikacji bedziesz pisal po prostu zapiszDane($dane), a ta funkcja sama powinna wywolac odpowiednia inna funkcje zapiszDoPliku($dane), albo sqlQuery($dane)... oczywsicie wszytkie te funkcje sa twoje.

z grubsza wyjasnilem o co chodzi...

80.53.23.* napisał:

Napisz poprostu wersje pod SQL uzywajac AoDB - do tego służy - oraz drugą wersję dla tekstówek....

83.17.37.* napisał:

Teraz problem dotyczy parametrów tych funkcji.

Założenia/problemy:
1. Nazwa tabeli = nazwa pliku
Tu jest problem. Każdy art będzie zapisany w osobnym pliku, jednak w przypadku SQL'a wszystkie arty będą w tej samej tabeli.
W tym przypadku proponujecie dodanie odpowiedniego parametru do funkcji zapisujących i odczytujących*, czy napisanie specjalnych funkcji dla artów, newsów, itp.?

* Jeśli wartość parametru byłaby np. 1, parametr dot. nazwy tabeli (SQL) w przypadku plików odnosiłby się do nazwy folderu, a ID artu/newsa - do nazwy pliku.

2. Co z ustawieniami? Także przechowywać w bazie (jeśli SQL)?

Jakie ważne parametry powinny zawierać jeszcze funkcje (by potem wiele razy nie poprawiać)?

Reszta później (gdyby były jakieś wątpliwości lub problemy).

213.17.150.* napisał:

jesli nazwa pliku ma byc nazwa tabeli to jak chesz zapisac wiele artykulow w wielu plikach ??
wymysl sobie jakis format zapisu do pliku, lub uzyj formatu csv.
poza tym cos mi sie wydaje ze chcesz sam napisac plikowy odpowiednik bazy danych... to jest bardzo trudne zadanie.... smiem watpic czy podolasz...

00 01 02 03 04 05 06 07 08 09 10 11