Regarding native_db:
vs regular db (e.g. oracle, postgres etc) what are the advantages and disadvantages of using it and can native_db be used as a replacement of typical DBs?
Something like native_db, sqlite are saved locally, normally oracle, postgres, mysql are deployed in separate machines.
So it's good if:
- the data doesn't need to be accessed by different users.
- the data set you need to storage are small.
- you need great performance on IO
You can think native_db as something like a local file or memory, the reason to save there is the same reason to use native_db rather typical DBs.
But I mean like what are the benefits of native_db when doing CRUD and cons of it compared to sqlite in terms of useage?
native_db and sqlite are both embedded databases (the database engine runs in the same address space as the application, unlike managed DBs like Postgres that run inside a dedicated OS process). Their pros and cons boil down to API and performance, both being subjective towards what kind of application you are writing. One pro of sqlite is that it is one of the most widely used libraries on the planet and is lauded for its code quality and test suite.
I don't mean if its for embedded vs server use, I just mean if I am coding and I am trying to use a database, lets compare just sqlite and native_db for the sake of argument I want to know what are the pros and cons of both of them, yes sqlite is more mature but what else?
If you are starting from scratch, you can probably use either, there are various trade-offs.
But company large databases go back a long time, the ones I am working with are about 25 and 8 years old ( I created both! ). It is generally a lot of work, and risky, to migrate to a new database, even if the one you are working with isn't ideal.
I mean the native_db readme has a pretty decent overview of the unique features, and a warning that it's not stable yet, and links to benchmarks and API docs. It's different enough from SQL databases that it's tricky to suggest what might be more specifically relevant to you without knowing what your situation is.
The best I could say in general is that traditional server databases are about long term persistence, connection management and administration, while SQLite is really better thought of as a file format for local application state (I've seen it suggested for a Photoshop-like image format, for example). In that vein, this approach is pulling the database even closer from a file API to being part of your application design, where application features would be directly implemented with the database API.
Are there any alternatives to native_db that is similar?
Similar in what specific ways? SQLite is similar in many ways.
No I am talking about native_db if there are similar libraries to native_db as it doesn't seem like much development has happened recently.
Are you saying sqlite is similar to native_db in many ways? Cause from my understanding with sqlite you still have to use the sql syntax select * from table whereas native_db does not have that syntax unless you used something like seaorm.
Depends what you mean by "similar" as has been said, but I'd say most of the #embedded-database tagged crates count:
What you're implying is that you want something with the same data binding API as native_db -- that is the similarity you want with native_db when considering other dbs. You'll probably have to look through the list of embedded dbs (as @simonbuchan mentioned) to see if one qualifies, since you're not getting that answer from anyone here.
Also, it may help to understand why you don't want to use SQLite with seaorm or another ORM. In my opinion, a db that only allows data binding to native language types, and does not support SQL, is often a dead end. The requirements for using stored data usually change over time, and SQL gives you a way to meet those changing requirements.
EDIT: Of course, you can always create your own query layer on top of a DB without a query language. But since SQLite already does have a query language, it can save a lot of effort.
Not to speak for the OP, but the general assumption of an embedded database is precisely that it's very specific to the operation of an application, and therefore anything severe enough to require a complete change to the structure would be only a fraction of that change's impact to the rest of the codebase.
In general I'd argue you're not even getting much portability from using "SQL" given how careful you need to be to stick to a common subset and that you need to do a bunch of work to migrate the data out anyway... but that's a different topic! In practice I think most people just slap an ORM or the like onto the database so it looks like an "native" DB anyway, and which actually increases the portability (at the cost of your sanity when something inevitably goes wrong)
(To be honest I'm a bit surprised I've not seen any RDMBs effectively push some of the query planner work over the pipe to the client and have the actual protocol be non-textual. That would make sense if the inherent assumption is the client is extremely transient but then all the connection management stuff is all assuming the opposite...)
Correct.
Seaorm afaik does not allow nested queries, for example:
struct Person
{
name: Name,
age: u32,
}
struct Name
{
first: String,
last: String,
}
fn main()
{
let name = Person{Name: {first: "john", last: "Doe"}, age: 25};
}
You will need to "flatten" before you can query.
I know for sure native_db does support this. One major drawback with native_db is that it looks like development may have been ceased.
Yes true sql is nice and handy to have and not against it. There is kiteSQL which integrates an ORM but again not sure if it supports nested queries.