Wybór sklepu os do rozbudowy

[jakub0004]

Witam wszystkich,

Od 3 lat działam na oscommerce. W tym czasie praktycznie w pełni dostosowałem go do swoich potrzeb. Niestety od jakiegoś czasu coraz bardziej zauważam mankamenty tego systemu takie jak :

- bezsensownie skonstruowane zapytania do bazy (sklep ma ok 15 tyś produktów) wystarczy że 20 osób przegląda kategorie a sklep się przycina.

- sklep się dość trudno pozycjonuje i indeksuje w googlach.

Szukam jakiegoś nowoczesnego skryptu sklepu (open source - darmowego lub taniego) do dalszej rozbudowy.

Grzebie juz od kilku tygodni w internecie znalazłem kilka skryptów:

prestashop prestasop (wydaje mi sie ok)

magento magentocommerce (raczej ok ale straszna to kobyła nie wiem jak serwer da radę)

Co sądzicie o tych dwóch systemach?? Ewentualnie co moglibyście mi polecić innego?

[breja]

W tym czasie praktycznie w pełni dostosowałem go do swoich potrzeb

title mogles zrobic ladniejsze tylko sam tytul + ew ktorka nazwa ksiegarni bo tak jak teraz to na samym koncu masz to co najwazniejsze i prawie tego nie widac ;p

co do skryptow strasznie ciezka sprawa tez szukalem jakis czas temu i nic mi nie pasowalo.

[k3rn3l]

zoptymalizuj sobie zapytania które CI najbaradziej obciazaja sklep.

Nie szkoda Ci czasu poswieconego na poznawanie tego systemu ?

[jakub0004]

zoptymalizuj sobie zapytania które CI najbaradziej obciazaja sklep.

Nie szkoda Ci czasu poswieconego na poznawanie tego systemu ?

To co można było zrobić wykonałem. Są rzeczy których nie da się zmienieć bez całkowitej przebudowy bazy danych np:

Aby wyświetlić kartę produktu oscommerce generuje około 7 zapytań do różnych tabeli w bazie a przy korzystaniu z pól dodatkowych liczba ta się zwiększa --

z tego co patrzyłem presta shop ma dane produktów tylko w trzech tabelach (tabela produktów, tabela opisów, tabele przypisania produktu do kategorii).

title mogles zrobic ladniejsze tylko sam tytul

A to ze względu na pozycjonowanie, przynajmniej tymczasowo

[k3rn3l]

Aby wyświetlić kartę produktu oscommerce generuje około 7 zapytań do różnych tabeli w bazie a przy korzystaniu z pól dodatkowych liczba ta się zwiększa --

Widzisz, jeśli spjrzysz w kod, to niektóre moduły które można załadować wyciągają jeszcze raz na nowo title, description, etc. Więc masz to wszystko x2.

Wszystko idzie zoptymalizować a ja nie kojarzę w którym miejscu jest 7 zapytań, żeby wyciągnąć informację o produkcie.

Swego czasu przerabiałem i optymalizowałem sporo zapytań w oscommerce i raczej jak jesteś biegły i tyle w nim siedzisz, to bez problemu zoptymalizujez zapytania.

[orzech_85]

Ja niedawno zacząłem przygode z Presta Shop i poznaje jej funkcjonalności. Jest to sklep open source i na mnie wywarł naprawde duże i pozytywne wrażnienie.

Jedynym minusem jest to że jest on znany na zachodzie jednak w Polsce dopiero powstaje "grupa wsprcia". Kilka m-cy wystarczyło aby przetłumaczyć skrypt i co najważniejsze dostosować go to polskich realiów ecommerce.

[jakub0004]

Aby wyświetlić kartę produktu oscommerce generuje około 7 zapytań do różnych tabeli w bazie a przy korzystaniu z pól dodatkowych liczba ta się zwiększa --

Widzisz, jeśli spjrzysz w kod, to niektóre moduły które można załadować wyciągają jeszcze raz na nowo title, description, etc. Więc masz to wszystko x2.

Wszystko idzie zoptymalizować a ja nie kojarzę w którym miejscu jest 7 zapytań, żeby wyciągnąć informację o produkcie.

Swego czasu przerabiałem i optymalizowałem sporo zapytań w oscommerce i raczej jak jesteś biegły i tyle w nim siedzisz, to bez problemu zoptymalizujez zapytania.

Zapytania przy wyświetlaniu strony produktu (products_info.php): odrębne zapytania do tabel products, products_description, products_extra_fields, products_to_products_extra_field, manufacturers, manufacturers_description --- już jest 6 zapytań a jeszcze chyba coś pominąłem

Myślałem aby połączyć tabele z polami dodatkowymi (Products_extra_fields) i tabele z opisami produktóe (products_description) dobry to pomysł?

[jakub0004]

Ja niedawno zacząłem przygode z Presta Shop i poznaje jej funkcjonalności. Jest to sklep open source i na mnie wywarł naprawde duże i pozytywne wrażnienie.

Jedynym minusem jest to że jest on znany na zachodzie jednak w Polsce dopiero powstaje "grupa wsprcia". Kilka m-cy wystarczyło aby przetłumaczyć skrypt i co najważniejsze dostosować go to polskich realiów ecommerce.

Testowałem sklep na swoim serwerze, wszystko chodziło dość szybko. Ciekawe jak bedzie to wyglądać przy rzeczywistym obciążeniu sklepu.

Wielki minus, że nie ma gotowego modułu pozwalającego zamawiać bez rejestracji (w osc nazywało się to chyba purchase without account).

Myślę, że w polskich warunkach takie rozwiązanie jest niezbędne.

Plusem jest duża ilość gotowych modułów.

Jest narazie presta jest na pierwszym miejscu wśród sklepów nad którymi się zastanawiam.

[orzech_85]

Powstanie modułu dla presty pozwalającego kupować bez rejestracji to tylko kwestia czasu. Natomiast jeśli ktoś ściąga aktualną (najnowszą) polską wersję z repozytorium polskiej strony Presty, to są tam już praktycznie wszystkie spolszczone moduły pozwalające na uruchomienie sklepu w polskich warunkach. Nie trzeba nawet zbytnio się rozglądać za innymi modułami. Niestety większość dodatkowych modułów jest w chwili obecnej dostępnych tylko w jęz. ang.

[Sc0rp0w]

Ja osobiście postawiłbym na Magento pod dwoma warunkami:

-sklep przynosi wystarczające dochody, aby utrzymać serwer dedykowany

-jesteś gotów zapłacić komuś obeznanemu z systemem za wdrożenie, dostosowanie istniejących modułów + stworzenie nowych, których jeszcze nie ma.

Patrząc po skali przedsięwzięcia firmy Varien, wydaje się, że to tylko kwestia czasu, aż Magento zdyskwalifikuje pozostałe platformy...

[giker]

Przecież produkty się za często nie zmieniają - cechować to poprostu.

[k3rn3l]

Aby wyświetlić kartę produktu oscommerce generuje około 7 zapytań do różnych tabeli w bazie a przy korzystaniu z pól dodatkowych liczba ta się zwiększa --

Widzisz, jeśli spjrzysz w kod, to niektóre moduły które można załadować wyciągają jeszcze raz na nowo title, description, etc. Więc masz to wszystko x2.

Wszystko idzie zoptymalizować a ja nie kojarzę w którym miejscu jest 7 zapytań, żeby wyciągnąć informację o produkcie.

Swego czasu przerabiałem i optymalizowałem sporo zapytań w oscommerce i raczej jak jesteś biegły i tyle w nim siedzisz, to bez problemu zoptymalizujez zapytania.

Zapytania przy wyświetlaniu strony produktu (products_info.php): odrębne zapytania do tabel products, products_description, products_extra_fields, products_to_products_extra_field, manufacturers, manufacturers_description --- już jest 6 zapytań a jeszcze chyba coś pominąłem

Myślałem aby połączyć tabele z polami dodatkowymi (Products_extra_fields) i tabele z opisami produktóe (products_description) dobry to pomysł?

No można połączyć te tabele jednym zapytaniem.

Z extra fields jedynie będzie roblem bo masz wiele krotek do jednego produktu, ale i tak można to wyciągnąć.

Wszystkie zapytania w oscommerce lecą przez jedną funkcję załóż sobie tam jakiś licznik i zacznij optymalizować najpierw ilość zapytań jakie ogólnie są generowany po kilka razy.

Np. odpytanie o title, description, menu, w produkcie o kategorię.

Kilka razy jest powyciągane to samo (w zależności od modułu).

Dowiedz się od swojego hostingodawcy jakie zapytania generują największe obciążenie poustawiaj odpowiednie indexy i działaj dalej lub jak nie dasz rady to przejdź na inny soft, ale uwierz mi, że żaden soft nie jest receptą na wszystko.

[slawek22]

Od 3 lat działam na oscommerce.

Współczuję, większego g**a niż OSC w życiu na oczy nie widziałem. "FATAL ERROR: register_globals is disabled in php.ini, please enable it!" epic fail!

Jesteś pewien, że obciążenie masz na bazie danych? Codebase tego jest ogromny, nieoptymalny i źle napisany. Raz optymalizowałem sklep na tym, apache/php ubijał dedyka a nie SQL, nawet po instalacji xcache (co prawda w sklepie z dużą ilością wyświetleń i małą ilością produktów).

Ja output z tego skryptu cacheowałem w bazie z pominięciem całości kodu sklepu (bo optymalizacja SQL nic nie dała, z resztą generował jakieś 10% obciążenia) + kopie sesji w memcached. Przynajmniej na dedyku klasy R900 z dyskami SAS.

Myślałem aby połączyć tabele z polami dodatkowymi (Products_extra_fields) i tabele z opisami produktóe (products_description) dobry to pomysł?

Mi się wydaje, że nie bo 1 prawdopodobnie dużo to nie da 2 - pewnie jakaś inna funkcja się wysypie. Jeśli zostawisz pozostałe tabele ale połączysz w product_info.php pewnie będziesz miał problem z zachowaniem spójności danych.

[jakub0004]

Dzięki. Mam chyba w phpmyadmin jakies statystyki.

Powstanie modułu dla presty pozwalającego kupować bez rejestracji to tylko kwestia czasu. Natomiast jeśli ktoś ściąga aktualną (najnowszą) polską wersję z repozytorium polskiej strony Presty, to są tam już praktycznie wszystkie spolszczone moduły pozwalające na uruchomienie sklepu w polskich warunkach. Nie trzeba nawet zbytnio się rozglądać za innymi modułami. Niestety większość dodatkowych modułów jest w chwili obecnej dostępnych tylko w jęz. ang.

no ale kiedy powstanie....pewnie trzeba będzie samemu dorobić o ile dam sobie radę.

Jesteś pewien, że obciążenie masz na bazie danych? .

Raczej tak, przeglądałem w phpmyadmin statystyki sporo tabel ma wywalone na czerwono znacznie dłuższy czas wykonania zapytań.

Jesteś pewien, że obciążenie masz na bazie danych?

tak w kilku tabelach (sprawadzałem w statystykach phpmyadminie) jest znacznie dłuższy czas wykonywania zapytań.

Od 3 lat działam na oscommerce.

Współczuję, większego g**a niż OSC w życiu na oczy nie widziałem. "FATAL ERROR: register_globals is disabled in php.ini, please enable it!" epic fail!

Jesteś pewien, że obciążenie masz na bazie danych? Codebase tego jest ogromny, nieoptymalny i źle napisany. Raz optymalizowałem sklep na tym, apache/php ubijał dedyka a nie SQL, nawet po instalacji xcache (co prawda w sklepie z dużą ilością wyświetleń i małą ilością produktów).

Ja output z tego skryptu cacheowałem w bazie z pominięciem całości kodu sklepu (bo optymalizacja SQL nic nie dała, z resztą generował jakieś 10% obciążenia) + kopie sesji w memcached. Przynajmniej na dedyku klasy R900 z dyskami SAS.

Myślałem aby połączyć tabele z polami dodatkowymi (Products_extra_fields) i tabele z opisami produktóe (products_description) dobry to pomysł?

Mi się wydaje, że nie bo 1 prawdopodobnie dużo to nie da 2 - pewnie jakaś inna funkcja się wysypie. Jeśli zostawisz pozostałe tabele ale połączysz w product_info.php pewnie będziesz miał problem z zachowaniem spójności danych.

Tak jest wydłużony czas zapytania do kilku tabel

[marekmaz]

A czy interesuje Cię sprzedaż również poza granicami Polski?