Szybka lekka baza pod program do faktur

0

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?

0

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.

1

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.

0

Pytanie czy potrzebujesz bazy relacyjnej. Jeżeli niekoniecznie to baza nierelacyjna może okazać się znacznie lepszym rozwiązaniem. Takie Mongo na przykład.

0

firebird ciekawa propozycja muszę trochę o tym poczytać dzięki

1

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:

  • MariaDB / MySQL: prawie jak baza SQL (dziwne różnice w stosunku do innych silników), bywa najszybsza, niekoniecznie najstabilniejsza
  • PostgreSQL: w pełni transakcyjna baza open source
  • Interbase / Firebird: znany głównie w środowisku post-borlandowskim (Embarcadero Delphi/C++, Free Pascal)
0
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 ;-)

0

Czemu C?

0

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ł)

0
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.

0

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.

0

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.

0

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

0
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...

0
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? ;-)

0
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 :)

0

pisz tak od razu aby potem nie przepisywać 90% aplikacji.

słuszna uwaga zrobię tak od razu.

nie twórz warstw pośrednich warstw pośrednich, bo się zagubisz

o to chodzi to nie jest pisanie na czas :) tylko dla wprawy żeby się coś nauczyć

0
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

0
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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1