tak się zastanawiałem, czy przejście Quickcart na SQLite nie byłoby dobrym pomysłem. Znacznie łatwiejsze zarządzanie bazami danych bez kombinowania z toną plików.
Myślicie, że to zły pomysł? W sumie już teraz bardzo wiele serwerów, zwłaszcza płatnych na których przeważnie stoją strony i sklepy posiadają obsługę tej bazy danych. Jest szybka, stabilna i lepiej się odnaleźć w kodzie.
Dziekuje za sugestie. Moze troche informacji by nakreslic sytuacje:
Ok rok temu i 3 lata temu zrobilismy ankiete w ktorej ludzie wymieniali rzeczy, ktore im przeszkadzaja w naszych narzedziach i bylo pytanie m.in. czy jest to baza danych oparta o pliki plaskie (mozna bylo wybrac wiecej odpowiedzi niz 1). Okazuje sie, ze 3 i ok rok temu ok 10% ludzi zaglosowalo na to, ze przeszkadza im taka baza danych.
3 lata temu takze przed zrobieniem przelomowej wersji Quick.Cart v3.0 pytalismy sie ludzi jaka wersje bazy danych by preferowali: - 57% wolaloby MySQL - SQLite wybralo ok 4% ludzi - 38% ludzi wybralo pliki plaskie - 2% ludzi wybralo inna nie wymieniona powyzej baze danych
Wiec biorac to wszystko w calosc okazuje sie, ze mimo iz ok 63% ludzi wolaloby inna baze danych niz pliki plaskie to jednak nie wielu z nich przeszkadza to, ze narzedzie jest oparte o pliki plaskie.
Trzeba jednak wziasc pod uwage to, ze 38% ludzi chce nadal pliki plaskie i obawiam sie tego, ze jednym z kilku argumentow czemu ludzie korzystaja z naszych narzedzie sa wlasnie "pliki plaskie".
Trafilismy w nisze i nie jest naszym celem zaspokajanie wszystkich potrzeb co nie znaczy, ze nie jestesmy otwarci na propozycje. Mysle, ze najlepszym rozwiazaniem jest stworzenie wersji alternatywnej jakies pol roku przed wydaniem wersji "przelomowej". Do tego czasu mielibysmy juz spore badanie na ile pliki plaskie a na ile baza np. MySQL w przypadku naszych narzedzi cieszy sie zainteresowaniem.
Stworzenie dwoch wersji narzedzia dla roznych baz danych jest dla nas dosc problematyczne gdyz co innego miec silnik, ktory dziala o MySQL lub PostgreSQL a nawet SQLite a co innego silnik, ktory dziala na plikach plaskich i na jakiejs bazie SQL'owej.
O ile w przypadku pierwszym wiekszosc zapytan SQL laduje do jakiejs biblioteki, ktora wystarczy TYLKO podmienic w zaleznosci od typu bazy danych to w przypadku drugim nie jest to juz takie proste, gdyz zapytan SQL'owych do plikow plaskich nie ma i naklad pracy przy wydawaniu kazdej nowej wersji bylby znaczny i tak duzy, ze majac Quick.Cart'a i Quick.Cms'a czulibysmy sie jakbysmy mieli nie 2 ale 3 a nawet 4 narzedzia.
Dlatego tez rozsadnym wyjsciem jest zrobienie proby przy wydaniu ostatniej wersji przed nastepna przelomowa i sprawdzenie zainteresowania ...
Ciezko teraz okreslic kiedy ta "ostatnia przed przelomowa" wersja by wyszla. Ledwo minelo 8 miesiecy od wydania wersji v4.0. Wiec mozliwe, ze jeszcze conajmniej 1.5 roku do wydania kolejnego przelomu.
Witam No tak, badania mówią same za siebie. Nie będę starał się tego negować. Samo przejście na inną bazę danych to sporo pracy potrzebnej do przerobienia systemu. To fakt. Jednak tak się zastanawiam dlaczego takie wyniki. Może to kwestia niewiedzy części głosujących. Możliwe, że czasami ludzie usłyszą mysql a sqlite i myślą, że to to samo. Tak samo jak dla niektórych Javascript i Java to prawdopodobnie to samo.
Nie staram się tu przekonywać na siłę. Co będzie to i tak zależy od zespołu OS.
Jak dla mnie Mysql nie jest dobrym pomysłem, bo to instalacja/wgranie bazy to nie jest takie proste. Trzeba się czasami namotać by poprawnie wgrać dane zwłaszcza jeśli chce się mieć odpowiednie kodowanie znaków. A gdy później przyjdzie nam przekopiować/ przenieść bazę na inny serwer to znów zaczyna się jazda.
Przy SqLite ma się w większości przypadków jeden plik z danymi. Jeden wspólny. Struktura jest taka jak w Mysql, ale ten plik jest na serwerze. Nie trzeba parsować poszczególnych plików, stosować jakiś znaków rozgraniczenia danych. Tym wszystkim zajmuje się serwer sqlite. A gdy będziemy chcieli przenieść sklep gdzieś indziej wtedy kopiujemy całą zawartość naszego katalogu i koniec. Przy backupie danych również jest to najlepsze i najprostsze rozwiązanie.
Proste rozwiązanie bo i łatwo zrobić backup i łatwo też przechowywać dane no i składnia mysql również dobrze się sprawdza bez konieczności zagłębiania się w kombinowania w rozdzielanie znaków i takie tam ;)
Warto pomyśleć o tym ponieważ za jakiś gdy systemy się rozrosną wtedy można będzie się pogubić ;)
Czy wiadomo coś na temat wersji opartej o bazę danych? @ treewood odnośnie badań, to mogło być tak, że SQLite jest po prostu bardzo mało znane i stąd tak niski odsetek chętnych.
> "Trzeba jednak wziasc pod uwage to, ze 38% ludzi chce nadal pliki plaskie i obawiam sie tego, ze jednym z kilku argumentow czemu ludzie korzystaja z naszych narzedzie sa wlasnie "pliki plaskie"." Być może decyduje o tym łatwość przenoszenia danych, ale SQLite zapewnia to samo. Odpadłoby wiele problemów związanych z wydajnością plików płaskich.
Edycję danych można wykonać w bardzo wygodnym SQLiteManager w przeglądarce Firefox.
Jeszcze taki argument za SQLitem: Aside from performance benefits which I can't be bothered to prove at the moment, here's a simple list of advantages of using SQLite rather than flat file: -You can query items as you wish -- don't need to load all of them and select which ones you need. -Record deletion is a much less painful process. No rewriting of whole files into wherever. -Updating a record is as easy as removing or creating one. -Have you ever tried doing cross-referencing lookups on a flat file? Just.Not.Worth.It. To summarize, it's every advantage a Database has over a text file.
MySQL'a bym odrzucił - wymaga zdecydowanie więcej pracy od SQLite'a. Do tego jeszcze dochodzą kwestie licencyjne.
Minęły 3 lata od ostatniej rozmowy na ten temat. Od paru miesięcy pracujemy nad Quick.Cms v6.0, który będzie funkcjonowal na bazie SQLite. Wkrótce udostępnimy wersję beta do testów naszym testerom (partnerom). Myślę, że jesienią będziecie mogli zobaczyć efekt naszej pracy.
Fanów wersji opartej o pliki płaskie chcę uspokoić, że planujemy równocześnie rozwijać dwie wersje: Quick.Cms v6.x i v5.x. Ta pierwsza oparta o SQLite, a v5.x nadal o pliki płaskie. Rozwój wersji opartej o pliki płaskie będzie głównie związany z poprawkami błędów i drobnymi modyfikacjami. Webmasterzy więc będą mieli sporo czasu (myślę, że ok 6 miesięcy od wydania wersji przełomowej, gdyż do tego czasu będziemy robili aktualizacje wersji opartej o pliki płaskie), aby przenieść się na pracę z nową i przełomową pod wieloma względami (nie tylko bazie danych) wersją skryptu.
W sprawie Quick.Cart v7.x nie mamy jeszcze sprecyzowanych planów.
