Solely looking at it from a mobile database point of view which is going to synchronize with a remote server,assuming it doesn't really matter if it is relational db or NoSQL,
what would be the better option to go along with?
Client platform is android
My vote would be for CouchDB.. The reason being, as NoSQL, it has good number of advantages. More than anything, you can make the user's data available offline.
Just in case you want further info on usage of CouchDB, I would like to request/suggest you to go through this, this and this.
I want to point out that Oracle Database Mobile Server also makes the data available offline, that's what it's designed to do. In addition to syncing your mobile database, it also offers device mgmt. For more info:
http://www.oracle.com/technetwork/products/database-mobile-server/overview/index.html
I've not used the Couchbase solution, but I do know some of the team over there, and they seem like very smart people.
What it comes down to: if you want/need an Oracle backend, then you should use Oracle Database Mobile Server. If you want to experiment with NoSQL, then Couchbase would be the way to go.
Eric Jensen,
Oracle PM
Related
I will need to connect my Android App (which is being programmed on Android Studio) to a database. What I don't know, and Google is not giving any good answers, is how should I connect this App to a database. I'm looking for a safe way of receiving and sending data.
The options I know are: MySQL database, REST database and SQLite (but SQLite is an offline database, so it is not what I'm looking for).
Any help will be appreciated.
There are many online database that are 'safe' to connect to, MongoDB, Azure, AWS, Firebase, Oracle databases etc. The best one will depend on which bests suits your application. And all these are safe at least to the extent that depends on the providers, you also need to make sure your implementation is safe and best.
Usually the data transfer between an android application and any relational database is done using api. The api can be written using any server side languages like php, java, javascript using node, python etc. You can also connect to firebase firestore or other non relational databases. The choice is yours. For example, if your system is mainly doing read action and not that much write action then you can go with non relational database like MongoDB. If it has a lot of write action then choosing relational database like MySQL, PostgreSQL will be good.
How can I create an android app that uses a mongoDB database locally i.e. Clients can make CRUD operations without connecting to a server. Sort of how SQLite is used, except this time I wanna use mongoDB.
I have checked around and what seems to be my most suitable option is using mongodb java driver, but the problem is how and what am I connecting the mongoClient to? Do I have to sort of start a server or something?
I would suggest using firebase or realm or something that comes with better native mobile support. Couchbase Mobile might be of interest too, but I have not used it. https://developer.couchbase.com/mobile
I've built an Android app based on Couchbase Lite which talks to a Couchbase Database via Sync Gateway. I've now tried to get Couchbase Lite to replicate with a CouchDB 2.0 database, but I am getting the following error:
W/RemoteRequest: com.couchbase.lite.replicator.RemoteRequest {POST,
http://192.168.1.5:5984/_revs_diff}: Got error status: 404 for
http://192.168.1.5:5984/_revs_diff. Reason: Object Not Found
W/Sync: PusherInternal{http://192.168.1.5:5984, push, 12ff9}: Progress:
set error =com.couchbase.lite.replicator.RemoteRequestResponseException:
Object Not Found
Note that for this I am not going through Sync Gateway but rather point Couchbase Lite directly to the CouchDB Url.
I don't know whether I need to go through Sync Gateway or not, but my impression after reading the Couchbase docs on Couchbase lite is that I do not when connecting to a CouchDb database and this post seems to back that up. https://github.com/couchbase/sync_gateway/issues/312
Can someone please confirm whether it is possible for couchbase lite to replicate directly with a CouchDb 2.0 database and if so what is the correct way to set it up?
Also, the app will be used by many sites, a site can be made up of one or more users. The reason I was thinking switching to CouchDb is so that I can have one database per site, something which doesn't seem to be easily doable in Couchbase. However, I have now discovered Channels in Couchbase which allow me to use one database but keep access to documents restricted by site (i.e. a site could have many users and all users should have access to all documents for that site).
What would be the pros and cons of using either separate databases in CouchDb or channels in Couchbase?
Thanks.
As #Hod said different buckets is equivalent to different databases in Couch DB so you can go for that.
Secondly it is definitely encouraged to use sync_gateway's channels property if you can because creating single bucket is preferred over multiple buckets and I have used sync_gateway with couch Lite and Couch server, it works perfectly fine and also with accuracy so I think you should go with sync_gateway and channels instead of creating multiple buckets
A few points in response:
The main thing is I think you can do what you want easily in Couchbase. Buckets in Couchbase Server are somewhat equivalent to separate databases. So you could split your sites that way. Channels in Sync Gateway give you more control for separating data and controlling access, as you've seen.
Couchbase Lite should be able to sync with CouchDB, but this isn't heavily tested. It's hard to tell from your snippet what's going wrong. You might check this post for some ideas: CouchDB: how to use _revs_diff to get document revision ID
Sync Gateway exposes a sort of superset of the CouchDB replication endpoints, so you'll have more flexibility using Couchbase Lite with Sync Gateway.
It seems that mobile local databases with sync capabilities are gaining some momentum in the mobile scene. That kind of approach can replicate data from the backend to the app (and vice-versa) without much effort. You won't have to write all that code in the app and backend to exchange information. It sounds awesome, right?
But, I was wondering in which cases the replication won't be efficient. What are the pros and cons of that approach? I'm particularly worried about too much data consumption on the mobile side and searching for info that's not on the local database.
I would argue that the replication approach available in CouchDB, Couchbase Mobile, PouchDB…actually saves on data consumption because there is a local database on each end of the replication. Instead of storing the data in a cache that would potentially be invalidated in time, the Sync approach looks for the diffs on each side and works out what’s missing and should be sent.
However, the sync approach doesn’t fit all use cases. If we imagine the example of a location based mobile application. There may be a feature to search for content around the user’s location. It wouldn’t make sense to replicate the entire server side database to the device to make that query. You can use REST API calls for those type of queries. And once a user has "bookmarked" locations, use the sync approach to make them accessible to all logged in devices.
In the case of Couchbase Mobile, the filtered sync is handled by the Sync Function and the REST API can be used for queries on the server side database.
I have a database server which collect user&pass of users (by login from website). On android application, I want to check user&pass, but I don't know how I send and receive data.
If you want to query your database, go ahead. Java SE and Android have something called javax.sql that allows you to interact with relational databases. You need a pure Java JDBC driver for the specific database you are querying against.
You have a good chance of being able to import the pure Java (SE) driver into android and having it work, but it's not guaranteed. if the driver uses some library that's available on java SE and not android, you are out of luck (but i don't know what that'd be).
That being said, you might be better off building a web service front end to your database to allow the client to make simplified, specific queries instead of exposing the entire database to the client. This is for security reasons, and also because in general it's better to push off as much work to the server as possible when writing for mobile clients.