|
LiteDB looks good. Serverless is not required for small projects, but it sure makes installation a lot easier.
|
|
|
|
|
had this issue a couple years ago. Just needed a decent DB that ran locally. I ended up using MariaDB. It just works. The SQL statements can sometimes be abit different but otherwise everything just worked. I ended up using DBeaver as my IDE for the SQL and it was pretty darn good. and because I am like you a person who likes LibreOffice it all seemed to just go together and worked fine on windows I might add.
To err is human to really elephant it up you need a computer
|
|
|
|
|
As mentioned above the latest MS-Access db is .accdb. I think it's licensed as an Office product now and not be used only as a db. At my last job we had a product that used Access as the db. MS let us slide on the licensing because we also did a few reports off the db but warned us we were tiptoeing on the edge.
The application was a testing, scoring, grading application and not very Office-y. When I left they were in the throes of moving it to SQL Server. I'm not entirely sure of the license restrictions (this was ~5 years ago) but it may be worth looking into if you decide to go the Access route.
|
|
|
|
|
I've used 4 databases for standalone desktop work:
- Access: tends to get corrupted, you must remember to compact regularly
- SqlCE: works ok, but may be missing some of the features you'd like; also doesn't do concurrency at all
- Sqlite: powerful, small, embedded - a good choice
- Firebird: Firebird: The true open source database for Windows, Linux, Mac OS X and more - this is honestly a really big hitter for the "standalone database" requirement. Yes, Firebird can run as a server, but it also can run standalone. Good performance, great SQL compliance, good drivers, etc.
I've used 3 of these to maintain a local db which is sync'd up to a master when connectivity allows. Out of all of them, Firebird was hands-down the best, and became what the project eventually used, after starting with SqlCE (and finding concurrency issues) then trying Sqlite (and finding some other issue, which may now be resolved - I think it didn't like multi-process access at the time?), then settling on Firebird, which worked brilliantly.
------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
Which is stupid.
|
|
|
|
|
I second Firebird, works great local standalone. Fast, stored procedures, free. FlameRobin is a free admin tool.
|
|
|
|
|
Whatever your choice, consider a separate Data Access Layer (DAL). That way when you open-source it, users can just point it to whatever their database of choice is. They might to tweak some bits in the DAL but that just improves the product overall and widens its appeal.
|
|
|
|
|
There is only one answer to the question: "What database does this standalone desktop app need to use", and that answer is SQLite.
Any other option is going to require more user management than necessary. If the end-user ever has to ask the question "how to I manage the data for this application" or "how do I install the database for this application", then you have failed the end-user.
|
|
|
|
|
The Local DB version of Sql Express also avoids those problems. It can be installed by the application with no extra interaction with the user.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
That's an extra step, with an extra point of failure, with extra dependencies, some of which will be updated.[1]
Using SQLite removes all of that; can be compiled *into* the application, so the application doesn't have to install anything.
[1] I once had an application break when Windows performed an update that changed one of the libraries SQL express used.
|
|
|
|
|
do you need relational database, or scale of a database engine?
if gonna be a few hounded entries, a JSON file, read at runtime, and parsed into plain old objects, might be just as affective. All your linq/queries still work. If not need encrypting of data, then can easily edit said file in a text editor, and transport, backup of file same as any file.
but then im the weird type that made a comics list in web page/javascript
|
|
|
|
|
I have this agenda application with the same characteristics. I am using SQL Server CE which has the same behaviour as SQLite has but being a Microsoft monolithic database, works very close to SQL Server (Thew big Brother) and it is very easy to migrate your data to the last without much effort.
|
|
|
|
|
When you do smth small, it's not necessary to select "small tools". Why not use MS SQL Express? First, it's small too, but power inside is same as "adult database"! Plus it's good experience for commercial development.
|
|
|
|
|
If you end up needing a fuller set of SQL features, it is now possible to run MariaDB (MySql equivalent) in a local portable mode, with a session initiated/terminated with a discretionary port, from a shellexecute or simillar.
MariaDB.education - Install portable[^]
Paul
|
|
|
|
|
First thing: don’t use Access for anything more than prototyping and local, personal projects.
Second, if you do use Access, check their licensing terms.
Lastly, if you expect to have multiple users using one central database, don’t use Access.
Don’t misundertake me: Access is a great tool for what it is, but it’s definitely not suited for some things.
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Have you considered rolling your own? It really depends on what your project needs are. If you are just storing information and not linking (making relational), then simple serialize/deserialize of JSON files can work very easily and would not have any outside dependencies.
If you are needing relational, LocalDB (SQLExpress) would be a solid choice but does come with a size limit. I think its 10GB now. Used to be 4.
I would not use Access.
|
|
|
|
|
Yep, I considered lighter file formats for storage such as XML and JSON. What I've read so far suggests that appending specific data chunks to these files become heavier as the data increases. And considering that this method needs pulling of entire file to memory, it might get slower over time as the DB size approaches several hundred MBs or even a GB? In contrast, Sqlite driver just performs CRUD operations on the file, so performance might be better?
|
|
|
|
|
There are only two options currently for an embedded, desktop database engine... SQLite, which is the easiest to use with a .NET provider, which is now fully supported by the SQLite Development Group.
To manage your SQLite database, get a copy of the free database manager tool for SQLite, "DB Browser". It has everything you need to create and manage your databases.
The Firebird Database Engine is your second option, using the embedded mode for the database engine setup.
Unlike SQLite, Firebird Embedded provides everything that a standard RDBMS would offer such as stored-procedures.
The best database manager for Firebird is IBExpert's Personal Edition, which is freely available. The interface is not as intuitive as "DB Browser" but it provides all of the necessary tools to manage your Firebird databases.
Firebird is also a tough database engine to work with as the documentation is not nearly as well defined as for other engines. Nonetheless, it is a very powerful engine and if you want to move your application into a multi-user environment, then you can simply use Firebird Server with literally no change in your desktop database structures.
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Consider whether MongoDB is a better choice for a more document centric solution.
|
|
|
|
|
|
SQLite, next question. 
|
|
|
|
|
if you are looking for portability without having to install software on the host machine and do not need to share the DB with another process, go with SQLite. it works fantastic, most languages have support baked in, and you can still pass structured queries. last I read I think there is a 4TB limit.
if the *.mdb gives you something more that SQLite doesn't have, choose that. to be honest I haven't touched an Access db from code in a couple decades, so I'm not all sure what it offers currently.
if you are not worried about portability use SQL express, or a no-SQL DB for document storage. both are good, it all depends on what you plan to do with the data.
|
|
|
|
|
Porter rejected my name tag. (7)
|
|
|
|
|
GATEMAN?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yep, you solved it Paul.
Porter rejected my name tag. (7)
Porter = definition
rejected my = reversal indicator
name tag = gat eman (reversed)
Gateman
Porter
|
|
|
|
|
Not Guinness then 
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
