Baza danych w jednym pliku Embedded

0

Witam,
Jak utworzyć bazę danych InterBase w pliku (Embedded) bez instalacji serwera. Próbowałem z serwerem w IBExpert oraz InterBase IBConsole, ale nie działa mi. Jest jakiś inny program do utworzenia takiej bazy ? A może jakaś inna baza danych. Teraz korzystam z bazy Access i ODBC, ale chciałem coś prostszego. Używam RAD Studio Delphi 10.3, Windows 10 64bit.

Dzięki
Pozdrawiam
tomamiko

2

Zamiast InterBase spróbuj skorzystać z Firebird'a. Można powiedzieć, że jest to fork (założony dawno temu) IB. Po prostu ludzie wzięli źródła IB i zaczęli rozwijać niezależnie. Niestety oba serwery nie są kompatybilne ze sobą. Firebird posiada właśnie wersję Embedded, która obsługuje dokładnie takie same bazy jak wersja zainstalowana na komputerze. Dodatkowo jakbyś chciał w przyszłości podłączyć się do pełnoprawnego serwera nie będzie z tym problemu i zrobisz to nie zmieniając ani jednej linijki kodu w programie. Jak jesteś zaprzyjaźniony z IBExpert'em to będziesz czuł się jak w domu, ponieważ obsługuje on również Firebird'a.

0

Również polecam firebirda. Nie dość, że można bez zmiany programu podłączyć się do serwera a nie od embended, a również prosta jest migracja pliku bazy z embended do serwera, a sam firebird oferuje 4 tryby pracy (w tym embended). @Mr.YaHooo ma racje - Firebird to fork InterBase 6, ale potem rozwój poszedł swoją drogą.

1
tomamiko napisał(a):

Witam,
Jak utworzyć bazę danych InterBase w pliku (Embedded) bez instalacji serwera.

Musisz mieć DLLki z osadzonym serwerem, tu masz info:
https://firebirdsql.org/manual/ufb-cs-embedded.html#ufb-cs-embedded-windows

Próbowałem z serwerem w IBExpert oraz InterBase IBConsole, ale nie działa mi. Jest jakiś inny program do utworzenia takiej bazy ? A może jakaś inna baza danych.

Nie.
Przyczyna jet w braku wiedzy, musisz doczytać.

Teraz korzystam z bazy Access i ODBC, ale chciałem coś prostszego. Używam RAD Studio Delphi 10.3, Windows 10 64bit.

Coś prostszego od Accessa?
To na pewno nie będzie Firebird, ale to dobrze - bo Access to nie serwer i taka sobie baza danych.
Z innych, np. MSSQL - ma swój odpowiednik Embedded nazywa się SQLocalDB.
Jeszcze inne to SQLite, ale... to tak raczej dla tych co dokładnie wiedzą czego potrzebują, bo można się średnio zdziwić z SQLite;-)

Z innych OpenSource to na pewno PostgreSQL.
Ale to już poważna baza danych, a nie wiadomo co tam potrzeba...

0

To ma być prosta baza z 2 tabelami i do max 1 tyś rekordów z ok. 10 kolumnami. Jeden użytkownik. Zależy mi żeby była prosta do przeniesienia na inny komputer. Przenoszę aplikacje i plik bazy i dll lub instaluję.

0

No to moim zdaniem takie Firebird będzie odpowiedni. Nauczysz się czegoś, podstaw SQL'a i to zaprocentuje na przyszłość.

0

Teraz korzystam z bazy Access i ODBC, ale chciałem coś prostszego.

Jest jakiś powód by nie użyć SQLite?

0
siloam napisał(a):

Teraz korzystam z bazy Access i ODBC, ale chciałem coś prostszego.

Jest jakiś powód by nie użyć SQLite?

Tak, to jest jakiś potworek a nie porządna baza relacyjna.
A więc jeśli się uczyć, to na pewno nie zaczynając od SQLite.

2

Też polecam Firebird :)

Tak na marginesie... @wloochacz - SQLite jest używany przez wiele dużych firm w wielu znanych i używanych przez miliony osób projektach/programach :)
https://www.sqlite.org/famous.html

0
skrzat napisał(a):

Też polecam Firebird :)

Tak na marginesie... @wloochacz - SQLite jest używany przez wiele dużych firm w wielu znanych i używanych przez miliony osób projektach/programach :)
https://www.sqlite.org/famous.html

I co z tego?
Ano to z tego, że "wiele dużych firm w wielu znanych i używanych przez miliony osób" nie potrzebuje relacyjnych baz danych, tylko quasi relacyjnego składowiska na dane.
A to nie jest to samo.

Czy coś w tym złego?
Nie.
Ale czy SQLite to dobra baza danych?
Nie, zdecydowanie nie.

1

To ma być prosta baza z 2 tabelami i do max 1 tyś rekordów z ok. 10 kolumnami. Jeden użytkownik. Zależy mi żeby była prosta do przeniesienia na inny komputer. Przenoszę aplikacje i plik bazy i dll lub instaluję.

Sqlite3 lekko da radę. Nie wyważaj otwartych drzwi.

0
siloam napisał(a):

To ma być prosta baza z 2 tabelami i do max 1 tyś rekordów z ok. 10 kolumnami. Jeden użytkownik. Zależy mi żeby była prosta do przeniesienia na inny komputer. Przenoszę aplikacje i plik bazy i dll lub instaluję.

Sqlite3 lekko da radę. Nie wyważaj otwartych drzwi.

Oczywiście @tomamiko SQLite da radę.
Ale jeśli traktujesz ten projekt również jako naukę baz danych i z tymi bazami danych w przyszłości chcesz mieć więcej do czynienia, to absolutnie nie dotykaj SQLite, bo zrobi Ci krzywdę.
Nauczysz się złych praktyk i po co Ci to?

2

@wloochacz: narzędzia dobiera się do zadania, używanie czegoś większego i bardziej złożonego, niż sqlite do tego, co autor chce zrobić to błąd. A krzywdę, to możesz sobie zrobić, jak młotkiem nie trafisz w gwóźdź, tylko w palec. W programowaniu umiejętność poprawnego dobierania narzędzi do zadań to cenna umiejętność.

1
Meini napisał(a):

@wloochacz: narzędzia dobiera się do zadania, używanie czegoś większego i bardziej złożonego, niż sqlite do tego, co autor chce zrobić to błąd.

Po pierwsze, to autor po czasie dopisał wymagania.
A po drugie, Firebird embbeded nie wymaga więcej wiedzy niż SQLite, ale w razie czego posiada pewne możliwości, które quasi-relacyjne składowisko na dane nie posiada.
Poza tym, w środowisku Delphi, użycie Firebirda kosztem SQLite jest zdecydowanie łatwiejsze, ze względu na mnogość informacji tutoriali i narzędzi dla Firebirda.
Ale tego pewnie nie wiesz...

A krzywdę, to możesz sobie zrobić, jak młotkiem nie trafisz w gwóźdź, tylko w palec.

Raczej w życiu nie pracowałeś młotkiem, prawda?
Tylko taki idiota jak np. programista, który nic innego nie potrafi, może trafić się młotkiem w palec przy wbijaniu gwoździ ;-)

W programowaniu umiejętność poprawnego dobierania narzędzi do zadań to cenna umiejętność.

Którą to umiejętność można wykorzystać dopiero wtedy, gdy jest się świadomym wyboru.

1

No, jeżeli SqLite jest kiepsko wspierany w Delphi, to już jest inna para kaloszy. Ale właśnie do takich zastosowań, o których pisze autor powstał SqLite. Ty najwyraźniej albo nie rozumiesz celu jego istnienia i porównujesz go z prawdziwymi relacyjnymi bazami danych, albo masz jakiś inny osobisty uraz.

Trochę sam sobie zaprzeczasz, autor potrzebuje właśnie prostego składowiska na dane, a nie prawdziwego rdbms, a ty piszesz żeby stosować prawdziwy rdbms, bo SqLite to tylko składowisko na dane. Powtórzę jeszcze raz: narzędzia dobiera się minimalnie do celu, który mają spełniać. Jeżeli SqLite wystarczy, to pełny rdbms nie ma tu sensu. Takie jest moje zdanie.

0

Ja bym poszedł dalej - i powiedział, że nie wiem czy to nawet ten SQLite nie jest za dużo - może zwykłe dwa pliki CSV by starczyły. Pytanie, jaki będzie rozrost tych danych i metadanych. Jeśli ma być to statyczne składowisko danych na całe życie programu (bo i tak się zdarza), to bym zupełnie się nie bał, zrobić coś prosto jak budowa cepa.

0
Meini napisał(a):

No, jeżeli SqLite jest kiepsko wspierany w Delphi, to już jest inna para kaloszy.

Nie, nie jest wspierany kiepsko, a po prostu Firebird jest bardziej popularny od lat i siłą rzeczy dla tej bazy jest zdecydowanie więcej wszystkiego dla Delphi.
Tylko tyle i aż tyle.

Ale właśnie do takich zastosowań, o których pisze autor powstał SqLite. Ty najwyraźniej albo nie rozumiesz celu jego istnienia i porównujesz go z prawdziwymi relacyjnymi bazami danych, albo masz jakiś inny osobisty uraz.

Z mojego punktu widzenia to wy nie rozumiecie ograniczeń SQLite i podają tu jakieś argumenty jakie to poważne firmy i super oprogramowanie z niego korzystają.
No i co z tego wynika?
Że korzystają i owszem, jako np. format plików w przypadku Adobe.
Czy to jest standardowe wykorzystanie dla baz danych?
Nie, zdecydowanie nie jest. I tak naprawdę to jest cały czas potwierdzenie tego, o czym mówię.
Że SQLite jest specyficzne i nadaje się do specyficznych zastosowań.

Tylko czy OP ma typowe czy specyficzne potrzeby?
Tego nie wiem, ale Wy możecie zastosować SQLite ;-)

Mam wrażenie graniczące z pewnością, że nikt z promujących SQLite nie programował baz danych na poważnie.
Używacie baz danych i owszem, ale nie programujecie w nich i nie przetwarzacie danych za pomocą SQL w stopniu wykraczającym poza średnio skomplikowane CRUDy.
Takie wrażanie mam ;-)

Zastosowanie SQLite jest OK, pod warunkiem że jest się świadomym jego ułomności.
A nie ma ich mało, ale widać je dopiero wtedy, gdy chce się skorzystać (kuriozalnie zabrzmi, ale to prawda) z możliwości jakie oferują "normalne" bazy danych.

Trochę sam sobie zaprzeczasz, autor potrzebuje właśnie prostego składowiska na dane, a nie prawdziwego rdbms, a ty piszesz żeby stosować prawdziwy rdbms, bo SqLite to tylko składowisko na dane.

Być może potrzebuje prostego składowiska.
Ale nie widzę abym sam sobie zaprzeczał, ja tylko i wyłącznie twierdzę, ze SQLite to bardzo słaba baza danych jest.
I powtarzam, jak komuś to nie przeszkadza i jest tego świadomy, to bardzo proszę.

Powtórzę jeszcze raz: narzędzia dobiera się minimalnie do celu, który mają spełniać. Jeżeli SqLite wystarczy, to pełny rdbms nie ma tu sensu. Takie jest moje zdanie.

Powtarzam; nie ma sensu na rozpoczęcie przygody z bazami danych z poziomu SQLite.

2

Tu nie chodzi o rozpoczęcie przygody, tylko o użycie minimalnego narzędzia spełniającego wymagania. Nikt tu nie promuje SqLite. Mówimy tylko, że do takich akurat zastosowań SqLite powstał i w tym przypadku najlepiej będzie użyć SqLite. W innym może być inaczej. Ile jeszcze razy muszę powtórzyć: umiejętnie dobierajmy narzędzia do potrzeb. Czy myślisz, że Mozilla używa SqLite, bo myśli, że to wspaniała baza danych? Albo Google w Androidzie? I że nie znają jego ograniczeń? Używają, bo akurat w tych zastosowaniach się sprawdza. Tu jest tak samo.

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