Witam,
Zastanawiam się czego użyć program ma działać możliwie szybko, mało "ważyć", i radzić sobie z bazą do 10tys produktów będę też chciał zrobić integracje z prestashop. Aha ważna też jest prosta implementacja w C. (na razie pisze dla w prawy ale kto wie chce zrobić to w miarę dobrze)
Zastanawiałem się nad SQLite jakie są wasze propozycje?
Trudno zaproponować cokolwiek na podstawie ogólnikowej specyfikacji. SQLite na mniejszą funkcjonalność, więc teoretycznie powinien być szybszy, ale bez
testów na konkretnych danych i zapytaniach, ciężko wróżyć. Co więcej, czesto bazy się zmienia w trakicie projektu, co oznacza, że w ogóle trudno jest
dobrać optymlanie bazę. Można użyć jakiejś warstwy pośredniej, która umożliwa łatwą wymianę bazy na inną, ale nie wykorzystuje ona wszystkich
możliwości danej bazy.
A ja zaryzykuję (pomimo takich szczątkowych informacji które udzielił pytający) i polecę Firebirda. Posiada on wersję Embedded która nie wymaga instalacji żadnego serwera. A w razie jakby trzeba było się przełączyć na pełnoprawny serwer instalujemy serwer i nic więcej nie zmieniamy poza wskazaniem bazy w programie. Co więcej sama biblioteka udostępnia API napisane w czystym C, więc chyba o to o co chodzi pytającemu.
10 tys produktów - OK, ale ile transakcji dziennie?
SQLite jest z tego co wiem jednostanowiskowy, na pewno wystarczy?
Jeśli to ma być wielostanowiskowe, to do wyboru są 3 B/O:
vpiotr napisał(a):
10 tys produktów - OK, ale ile transakcji dziennie?
SQLite jest z tego co wiem jednostanowiskowy, na pewno wystarczy?
Niezupełnie;
http://www.sqlite.org/whentouse.html
Co nie znaczy, że to zawsze dobre rozwiązanie - zależy.
Aczkolwiek, jeśli to miałaby być server side database, czyli dostęp z aplikacji nie bezpośrednio do bazy danych, a przez dedykowaną usługę SOA, to może to być killer ;-)
http://blog.synopse.info/post/2012/09/14/Updated-mORMot-benchmarks-on-another-HW-configuration
No, ale tu już się ciut zapędziłem ;-)
A czemu nie C :) (żeby nie było akurat w tym temacie nie ma dyskusji będę pisał w C i koniec )
Pisze dla wprawy czyli for fun. Ale chce już napisać dobrze może coś z tego wyjdzie.
no tu macie racje mimo że myślałem o programie 1 stanowiskowym to mądrze było by skorzystać z rozwiązania które pozwoli mi w przyszłości zaimplementować obsługę wielu stanowisk.
Co do 10 tys produktów to założyłem że tyle ma przeciętny sklep to założę też że 100 transakcji dziennie. (oczywiście powinienem pisać tak żeby był w stanie obsłużyć jak najlepiej jak najwięcej transakcji i dowolną liczbę produktów i pewnie tak się będę starał)
xvc napisał(a):
Co do 10 tys produktów to założyłem że tyle ma przeciętny sklep to założę też że 100 transakcji dziennie. (oczywiście powinienem pisać tak żeby był w stanie obsłużyć jak najlepiej jak najwięcej transakcji i dowolną liczbę produktów i pewnie tak się będę starał)
Akurat moim zdaniem przy takiej ilości danych nie masz się co przejmować za bardzo, ponieważ to jest mała ilość danych jak dla dzisiejszych serwerów. Mój system na domowym laptopie pod wirtualką radzi sobie wyśmienicie jak mam 300 000 pozycji dokumentów w bazie oraz jakieś 30 000 produktów.
Jeśli do bazy są wysyłane proste zapytania, nie częściej niż kilkadziesiąt razy na sekundę, to może być miliard rekordów i baza będzie wyrabiała.
Uważaj żebyś sobie nie utrudnił zadania. Baza może pod wieloma względami zastąpić serwer, sama jest serwerem. Oczywiście nie taka baza jak SQLite. Jeśli potem ekstremalna wydajność nie będzie Ci potrzebna, to rób od razu na mysql, postgresie, mssqlu, itd.
Pozdrawiam
artur_bredzki napisał(a):
Jeśli do bazy są wysyłane proste zapytania, nie częściej niż kilkadziesiąt razy na sekundę, to może być miliard rekordów i baza będzie wyrabiała.
Pytanie co oznacza proste zapytanie?
xvc napisał(a):
Nie wiem czy to dobrze czy nie zdecydowałem się na sqlite. I wymyśliłem sobie że w razie rozbudowy ew przerobie na jeden główny [klient/serwer] + kilka [klientów] i to główny będzie po prostu kolejkował zapytania.
Moim zdaniem średnie rozwiązanie. Jeśli to jest Twoja 1 poważna aplikacja nie twórz warstw pośrednich, bo się zagubisz. Jednak jeśli już tak mocno chcesz to rób, jednak pisz tak od razu aby potem nie przepisywać 90% aplikacji.
artur_bredzki napisał(a):
Uważaj żebyś sobie nie utrudnił zadania.
Z tym się zgodzę.
artur_bredzki napisał(a):
Baza może pod wieloma względami zastąpić serwer, sama jest serwerem.
Co Ty gadasz. Od kiedy baza jest serwerem. Baza to baza, serwer to serwer. Baza tylko trzyma dane i to jest plik, bądź kilka. Więc jak to może być serwer...
Mr.YaHooo napisał(a):
artur_bredzki napisał(a):
Baza może pod wieloma względami zastąpić serwer, sama jest serwerem.
Co Ty gadasz. Od kiedy baza jest serwerem. Baza to baza, serwer to serwer. Baza tylko trzyma dane i to jest plik, bądź kilka. Więc jak to może być serwer...
Raczej, co Ty gadasz?
Przecież każdy RDBMS C/S to jest serwer baz danych. Serwer! I każdy!
Przecież nie "gadasz" z plikiem zawierającym bazę (lub bazy) danych, tylko z serwerem prawda?
Nowoczesne RDBMSy to daleko więcej, niż zwykłe składowisko danych w plikach i sam doskonale o tym wiesz.
Zatem, co Ty gadasz? ;-)
wloochacz napisał(a):
Raczej, co Ty gadasz?
Przecież każdy RDBMS C/S to jest serwer baz danych. Serwer! I każdy!
Przecież nie "gadasz" z plikiem zawierającym bazę (lub bazy) danych, tylko z serwerem prawda?
Nowoczesne RDBMSy to daleko więcej, niż zwykłe składowisko danych w plikach i sam doskonale o tym wiesz.
Zatem, co Ty gadasz? ;-)
Tak to jest serwer bazodanowy. Ale nie róbmy tak, że baza danych == serwer, bo to nie prawda. Ja wiem, że to jest kwestia nazewnictwa. Jednak przychylam się do tego, że baza danych != serwer. Baza to tylko (np. wiki)
Baza danych – zbiór danych zapisanych zgodnie z określonymi regułami.
Natomiast serwer
Serwer – program świadczący usługi na rzecz innych programów, zazwyczaj korzystających z innych komputerów połączonych w sieć.
Oczywiście w dzisiejszych nowoczesnych RDBMS jedno nie jest w stanie istnieć bez drugiego. Czepiam się tylko nazewnictwa.
I właśnie to, że aplikacja gada nie z plikiem, a z serwerem odróżnia serwer od bazy danych. Analogicznie można powiedzieć, że serwer IIS/Apache czy co tam jeszcze sobie ktoś chce to strona www :)
artur_bredzki napisał(a):
Baza może pod wieloma względami zastąpić serwer, sama jest serwerem.
Co Ty gadasz. Od kiedy baza jest serwerem. Baza to baza, serwer to serwer. Baza tylko trzyma dane i to jest plik, bądź kilka. Więc jak to może być serwer...</quote>
Bazę, jak każdą inną aplikację, można wtedy nazwać serwerem, gdy pełni rolę serwera w trakice komunikacji z innymi aplikacjami.
https://pl.wikipedia.org/wiki/Serwer
Pozdrawiam
xvc napisał(a):
o to chodzi to nie jest pisanie na czas :) tylko dla wprawy żeby się coś nauczyć
To w takim razie możesz robić to w bardziej rozbudowany sposób.
SQLite 
C 
moneyopędza automatem czego nie opędzadecimal? Pytam, bo może czegoś nie wiem, a chętnie się dowiem.moneyjest wydajniejszy w porównaniu ze zwyczajnymnumeric. Inna sprawa, że ten typ potrafi "pilnować" kwot resztkowych (groszowych). Co prawda w 99% przypadków nie ma to znaczenia, ale czasami trafia się niedziesiętny system monetarny i ze zwykłymnumericmamy problem.vpiotrwybitnym, ale dla mnie to nie są żadne optymalizacje tylko standardowa różnica pomiędzy typem stało a zmienno przecinkowym. Problem z "resztkami" (i zaokrągleniami przy agregacjach) jest znany każdemu żółtodziobowi, który próbował robić to z typami zmiennoprzecinkowymi. Prawdziwy horror-szoł się z tego robi... Poza tym, z linka przesłanego przez @vpiotr jasno wynika, żemoneyw PGSQL jestdeprecatedi jednoznacznie zalecany jestnumeric.vpiotr