ďťż

Wybór miejsca zapisu danych... SQL, pliki... Jak to zrobić?

Podstrony

telcocafe

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.
Użytkownik Ferrari edytował ten post 14 marzec 2005, 14:36

Dobry sposób... Właściwie obsługa pozostałych baz danych możnaby było ściągać jako dodatki.

Jest jednak drugi, gorszy problem. Praktyczne zastosowanie.
Funkcje dla każdej czynności (zarządzanie menu, nowościami itd...), których byłoby może nawet ok. 50-100 to trochę za dużo.
Czy ktoś z was ma lepsze rozwiązanie? Jak nie będzie lepszego, pozostanie to, które podałem powyżej (rozdzielę funkcje na pliki).

Nie znam się dobrze na SQL.

Jak to zrobić za pomocą KLAS? Możliwe to jest? I na ile skuteczne w tym przypadku?
Użytkownik Ferrari edytował ten post 14 marzec 2005, 15:38
no w takich wypadkach robi się powiedzmy drivery danych dla bazy danych i dla plików tekstowych (możesz zrobić różne wersje driverów dla różnych baz danych i różnych sposobów zapisu w plikach tekstowych)

i taki driver jest hermetyczny tzn. jak korzystasz z niego w kodzie to cię nie interesuje jak coś się dzieje, wiesz tylko że się zapisuje/odczytuje i jaki będzie format danych jeśli coś odczytujesz

polecam wzorzec projektowy MVC - tam będzie to część modelu

PS. oczywiście obiektowo to trzeba zrobić bo inaczej by było syfiasto
Użytkownik marekr edytował ten post 14 marzec 2005, 16:58

By zaoszczędzić miejsce, rzeczywiście można by napisać odpowiednie funkcje odpowiadające za zapis, odczyt itd....

Dostęp do bazy danych jest trochę inny, niż do plików.

PLIKI - zawartość pliku jest najpierw przygotowywana, zapisanie do niego wykonywane jest na końcu.
BAZA - na początku łączysz się, na końcu rozłączasz (to nie sprawi problemu), jednak tu jest trochę inaczej... Wydajesz polecenie zmiany pewnego pola - jest to już wykonywane.

O czym muszę pamiętać tworząc funkcje odnoszące się do wykonania pewnych poleceń (i na SQL i plikach)?

Jeszcze jedno...
Jak myślicie? Czy ustawienia także powinienem trzymać w bazie SQL, czy zawsze w pliku tekstowym (.php) [wygodniej, bo od razu zmienne]?
:excl:

Zna się ktoś na tym?
Użytkownik Ferrari edytował ten post 14 marzec 2005, 22:48
zobacz mojego RkCMF. Tam jest abstrakcyjna baza danych i można go instalować obecnie na MySQL, SQLite*, Interbase*, Postgresql** i innych (* - testing, ** - not tested) i m.in. można napisać drivera wykorzystującego pliki tekstowe korzystając z klasy txtSQL (tylko że to padnie na średniej stronie)

Właściwa treść!!!
To, co wyżej się tu nie liczy. Piszę to tutaj, by o CMSie nie tworzyć nowego tematu.

Czy jest sens tworzenia obsługi większej ilości SQLi niż MySQL, który jest najpopularniejszy?
Napiszcie, dlaczego.
Obsługa zapisywania danych tylko w MySQL i .php uprościłaby sprawę.

Edytowane...

Pozostaje obsługa wielu baz SQL, lecz nadają się te, których składnia jest podobna. Pomocne w tym będą funkcje PHP, które same złożą zapytanie.
Użytkownik Ferrari edytował ten post 01 maj 2005, 14:22

Sitedesign by AltusUmbrae.

Darmowy hosting zapewnia PRV.PL