I am thinking about using Google App Engine.
For my project I will need several data stored in different databases. From what I've been reading so far AppEngine only provides one database to store and track users.
My problem is I need to have multiple databases to store the same data but store only the data related to its criteria.
Is AppEngine the way to go for this? Its a android app I will be using by the way.
Or should I have my own server? If so what would I need to implement?
Can you explain, why you need more than one database.
You can use namespaces to create a multitenancy environment.
https://developers.google.com/appengine/docs/python/multitenancy/multitenancy
Each entity you define (see https://developers.google.com/appengine/docs/python/datastore/entities) is conceptually like a table -- the entity's fields are the equivalent of columns in a table.
So after reading the documentation in the link #Moishe supplied in his answer, i figured out the answer.
I just thought i would post an answer here to save someone some time in the future.
Here is a class called employees that accepts App engines Datastore parameters.
//Class name Employee
class Employee(db.Model):
//Employee information we want to enter into the Employee entity.
first_name = db.StringProperty()
last_name = db.StringProperty()
hire_date = db.DateProperty()
attended_hr_training = db.BooleanProperty()
//Set employees information to the Database Model to be inserted into the Datastore.
employee = Employee(first_name='Antonio',
last_name='Salieri')
employee.hire_date = datetime.datetime.now().date()
employee.attended_hr_training = True
//Like committ..this initiates the insertion of the information you put into the database store mode. This works sorta like androids bundle or SharedPreference you put the information into the datastore and then committ it or save it.
employee.put()
Related
I'm a bit confused on when should I use a room database instead of SharedPreferences or DataStore.
In my case I have an apps that let the user login and currently I store the logged in user data (followers, age, etc.) in a SharedPreferences, is this the correct approach for this kind of case? Should I just create a Room implementation for storing said user data? Thank you
First you need to understand the nature of these two things.
Room DB is schema so you will need to define every properties before you can use it. Such as table name, column name etc.
As it is a DB, you can easily perform a partial update on the corresponding table.
While Shared Prefs is just a key value pair in a xml file.
You insert age as key and 25 as value and that's all.
Even you can use GSON to convert the object to a JSON and store it as plain text like a non SQL DB:
key = login-data, value = {"follower": "sskrts", "age": 25}
Decision
If it just a simple login session data, then I will recommend to use Shared Prefs to cache the data. It is a simpler implementation.
If you are going to store a table of data instead, both works fine, at least in my use case experience. So it will more depends on your preference of schema or non schema DB.
Note that both storage seem to have NO encryption so don't store raw credential info there.
I am a novice android programmer, and I am developing my first android application. I'm trying to figure out if firebase is suitable for my needs.
My app looks like this:
users add the product to the database by filling in the product
fields
products are stored in the database as objects with simple fields (numbers and strings)
users search for a product in the database to compare its fields according to different criteria
users edit (update) product fields
users have their own accounts
My priority is the ease of use.
My question is:
Is Firebase suitable for my needs or is there a more suitable solution?
Do I understand correctly that I am interested in the Cloud Storage product?
users add the product to the database by filling in the product fields
Yes, you can achieve this using either Cloud Firestore or the Realtime Database. In both cases, you can add the data as a Map object or as a custom object of your choice.
products are stored in the database as objects with simple fields (numbers and strings)
Yes, you can achieve that. Here are Cloud Firestore supported data types, as well as Firebase Realtime Database data types.
users search for a product in the database to compare its fields according to different criteria.
None of the above databases supports native indexing or search for text fields, so you can use third-party libraries like Algolia or Elasticsearch.
users edit (update) product fields.
These are basic CRUD operations that are supported by both databases.
users have their own accounts
In this case, you should use Firebase Authentication, a service that works perfectly with both databases.
Is firebase suitable for my needs or is there a more suitable solution.
As I see in your requirements, yes, it suits your needs.
Do I understand correctly that I am interested in the Cloud Storage product?
For storing data (objects) you need to choose one of the above-mentioned databases, or why not even both, and for storing files, you should indeed use Cloud Storage for Firebase.
You could use firestore for this. Although full-text search won't work, you can use algoia/elastic to do full-text search.
My app needs to use data from different websites. On these websites, there is a search with different chemical ingredients.
How can I programmatically copy this data from website to my realm database?
This database on Realm needs to be saved as a table which has 2 columns: ingredient name, description.
First of all, create an ID for each ingredient, receiving ID, Ingredient, Description. It's the best way to avoid conflict.
Second, you need to assemble a crawler, and this goes beyond your android application, maybe a network service that can be done even in java, identifying the information on each site and inserting into your database. So doing turn your android application get this information from the site.
I am developing an App in which now i have to create database for more better user experience. Then i came to know about DB4o which is many times faster tool for creating database than other like SQLite, MySql etc, but the problem is i am not able to find any single example that explains about DB4o and how to create database using Db4o. If anybody has used it, please post an example or send me link.
To store the object in database use
db().store(exercise);
To retrieve All records from database, use
db().query(Object);
To retrieve particular record from database, use
db().queryByExample(Object);
If you need example, Try My blog example using db4o.
In this example, simple student object will be stored in database using db4o. Student object will contain student name, register number, and his age.
Thank you.
Currently I have developed an android application that uses a local sqlite database per installation. The database comes pre-populated with static tables, and the entire point of the application is to allow the user to assign dates/comments with the pre-populated information in each table.
I am looking to bring this online, and move the database to a mysql format, allowing access via desktops and other mobile devices. Is the best way to handle this to assign each new user a new database?
I would strongly avoid creating multiple databases, and instead add relationships to the existing database structure you have with a users table. Each user has an association to each existing object. Keep in mind sharing with other users in the event that you may want to allow one user to see another user's info.
My suggestion is provide an update to the app where after the first launch after updating it pushes their information to your MySQL database and inform the users that they can access their data via other methods now.
how many user to you expect? I would use only one database with a user table instead of hundreds/thousands of databases.
One table for all users (only with user info like id, email, password, etc).
Another table with comments (with user id and his comment), so that you can add as many comments per user as needed. If dates are related to comments put them on this table, else another table for dates as well.