I want to develop a Nutrition Recommender Smart Phone App. Details of project are following.
This app will:
•
guide patients about the choices of food and diet plan according to
their health issues.
provide a list of dieting plans
recommend healthy food choices for men, women, toddlers, kids etc.
according to their age, weight and health condition
• have the calorie calculator
have some good articles about diet and foods
inform people about the nutrition importance of different
vegetables, fruits, beverages, grains, oils, dairy etc.
share some innovative ideas about breakfast, lunch and dinner.
But I don’t know how to design database to implement above functionality. Can someone guide me how many tables should I create and what tables relationship exist?.
Introduction
First of all, this is very basic what you wrote us. You should start specifiing those things and get more into details. For example for a diet plan you can think about the properties such plan could have. Properties are e.g. the length of the plan, the nutrition you need and maybe some sport-excercises. Just some samples. Then you may split up the nutrition in one table and so on. Now you can think about if you want to do all the database stuff on your own, or use a framework. Actually the whole database stuff seen in MySQL and so on is done on a webserver, because of security leaks on the client (decompiling, traffic reading, ...). If you want to save data on the local storage or in a local db (SQLite would be you choice) then you should also think about if you want to use an API for that (e.g. RoomAPI by Android Jetpack)
General thing
You should get your self a clear mind which architecture you want to use. You can store data on a webserver and transfer the data via web-interfaces e.g. REST with JSON or XML. You can also store data on the local device in a file or in a database (which is basically also a file with specific interface requirements). You have to decide and consider you require the exchange on multiple devices or just for one device on it's own.
Planning your structures
After you know which architecture you want to use, you can start planning. First of all I would suggest you to get an abstract view of your project. That means just writing down what you want to have and then start writing down the corresponding properties. For a diet-plan this may be the name of the plan, the length, required nutrition and so on... After that you may know, oh okay, I also need a table with the food and you will see (automatically) that there will be a connection. If you see the connection just draw a line connecting those. In an ideal situation you already know the relation of this connection (One to many, Many to one, Many to Many, One to One, see this stackoverflow article: Difference Between One-to-Many, Many-to-One and Many-to-Many?).
Implementing your structures
Anything I do is handcrafted
In the case you want to do all on your own you may use a gui tool for databases to design your database. You can also use commands to do that, what need much more effort. You can decide on your own and on your knowledge.
Pro for gui
Easy to use
Fast creation of the tables
Contra for gui
May use some cryptic names for indexes and keys
"May don't let you look behind the scenes"
I rely on APIs
You can also rely on APIs. That means often, that you can program the class according to your plan, then annotate it and the connections/relations would be managed by the api. Such abstraction-layer is Room for Android or Doctrine for PHP, those are just samples and there are much more.
Conclusion
How you get the data into the database and out of the database is your thing. You could rely on easy use of APIs or get your things done by yourself. It should be a little guide for you to understand database design.
P.S.: If someone has things to edit, do that! I would appreciate that!
Cheers Tarik.
Related
I want to make an android app that have two sites, one is for customer and the other one is for driver and operator. I'm a little confused how to do this. I thought I would make two projects but have one database.
How do I do this? Or is there a better way? Please forgive this stupid question. I'm still learning btw.
There is NO hard rule.
Largely depends on why or why not?
Architectural Patterns and Design Patterns are not meant for avoiding duplication or tight-coupling. They are not rules. These are very matured well tried and well tested convenience patterns.
Many times there will be redundancy or tight-coupling by policy or by business rule or legislation or efficiencies or to avoid maintenance complexity.
To answer your question…
E.g. You require an application which has large data input say to 10–50 Lakh records per 24 hours. These records need to be processed and reports updated ASAP before the end of Calendar day which is 12 midnight.
It makes sense to have the two different projects with a common database:
Which processes the data and generates reports in the background even possibly based on a scheduler
A UI based application which allows users to input data and view reports.
Something like an email or sms campaign.
In this case both projects will be accessing the same database or databases. You may have master data on an RDBMS server and trasactional data on NoSQL database for analytics and reports etc.
In QA or at the end of delivery you will anyways know what went right or wrong with your architecture and design.
You may want to discuss these things with your applications architect. Have a good academic relation with your applications and solutions architect. It will give you great insights.
My goal is to collect health and family related data through interview some patients. So I'll provide every information about every view or question in database. like view type (radio button,edit text ,spinner...), data type (text or number), data length, whether it has any media (image, audio, video) regarding this question. Questions might have a dependency (visibility or value) on other question. I have tried so far and what I got that for small number of questions its okay. But when its about 100 or 150 or more questions, performance is not good. Since I am running lots of sql query and refreshing view manually. I mean on event (onSelect, onChange, onChecked.....) I am saving data to db, changing other question's visibility, value. So far lots of requirement have been added to my app. Can you suggest me about coding structure , library so that I can improve the performance? What are the things that should be used in this app? I have attached some pictures so that you can get a idea.
View Demo https://i.stack.imgur.com/ZCGuz.png
Dependency https://i.stack.imgur.com/j2nzj.png
Required field validation https://i.stack.imgur.com/tFuOH.png
You could use Google Firebase services. There are some huge advantages compared to sql especially with app development. It's optimized for many queries and therefore it's speed is impressive. You can just a Firebase account and use it(Although with limited resources). I would really that you add the firebase library to your project. Also with sensible health and personal data should stay private and as far as I know there are literally always security issues with Apache2 or nginx or php or mysql/mariadb so just do it the easy more reliable and more secure way. I hope I helped you out. :)
I plan to write an Android app that allows the users to share little pieces of information about a place, e.g., a bar, restaurant or the like. I'm now looking into what is the best way to store such data. I'm particularly concerned about retrieval: When showing a (Google) Map, I'd like to overlay it with said information, so I'll need to be able to make geospatial queries to the database.
Is this possible with the Google Cloud Datastore, for example? What are the alternatives?
Datastore does not have support for geospatial properties per se, but you can easily create a convenience class to work with it. In App Engine, there is a property GeoPt just for this purpose both in the Java and Python libraries.
If you are interested in geo queries there is not much that Datastore can do for you, but there is an interesting lib in Python to deal with that, geomodel. The problems are still on performance and costs. The operations performed there, although optimized, are heavy.
There's one last alternative. Search API allows you to perform geo queries. The only drawback of this are costs and limited free tier.
You can try a quadkey. Its similar to a geohash or a geocell. Translate the points to a binary and interleave it and treat it as base-4 number. It comes it looks like a space filling curve and it has the same properties. Here is a good article about quadkeys:https://msdn.microsoft.com/en-us/library/bb259689.aspx.
You might want to look at Postgresql and even PostGIS for storing geo data. They are fairly efficient, scalable and fast. I've used Postgresql with geodata for many years and on very busy websites and Android apps. If all you need is to locate things near other things, Postgresql works great. If you want to find things within polygons or do more complex queries, PostGIS has a lot of great functions.
Postgresql and PostGIS are both open source and free.
If you want amazing performance, use an SSD and a machine with enough memory to hold the entire database. You'll be amazed at how fast that setup is.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So far I've made dozens of apps which use database. I did not go too deep into database logic and how to structure it, but made it as simple as possible and by the rules.
For example, my database logic usually consists of one database class which extends SQLiteOpenHelper. Then I make CRUD methods for each table. Each time I have to deal with a database, I make a special AsyncTask and within it deal with the database. And this is it.
Talking to some developers, I was told that my logic structure should be more complex, more OOP. I tried finding samples on the net but they all were directed towards explaining how to deal with the database. I even reviewed some open source projects but they had the logic similar to mine.
Can you help me? How should I make database logic more OOP? I guess they mentioned that I should be able to reuse this logic in the future, changing only the lowest part which deals with a specific database and its tables.
This is a slightly subjective question, so here's a subjective answer. There is not one correct way to do it imho, I can only speak about how I personally like to work (the big project version, for small projects there's another story). For you or your team it might be different.
For the reference, I work mostly agile, e.g. requirements can change. APIs within the code can change (and do that quite often). This - of course - influences what I consider as useful and what I consider as not useful for my personal work.
Also, I like to work without big frameworks, whereever possible. That's why there is no framework in the model explained below.
I divide database work into three parts to work with: (quite some similatities with the MVC pattern)
The actual database backend (which can execute SQL). Can contain own code for cross-platform work.
The storage class(es), that takes care of storing application-specific information. Each piece of information can be read and set from storage classes, (example: interface AddressBook provides access to elements of the type interface Contact, which have getters and setters for some stuff. The implementation translates that to a single table in the backend).
The application code, which performs actual work and is splitted up further depending on the application (example: stuff providing an address book GUI, etc.).
Why do I split that way? Well, one reason is the ease to switch to a new storage or database backend. If I discover that there could be more preformance when restructuring tables so that new requirements can be met, I update the storage classes. That way I do not have to touch any application logic (example: adding a 1:n table for email addresses to the address book. The new table and its relations do not affect any code within the application, it can recive a list of email addresses from a contact, and add or remove them with ease).
One other reason is that the application code is easy to read (as it consists of, well, application code), while storage code is also easy to read (as it only takes care of storing, caching and similar stuff).
The third reason is that in the case I wish to add another storage mechanism (for example when switching to a platform with a built-in database backend or when adding optional web services) - I can use all OOP mechanisms on the three layers; multiple storages for example can coexist within the same application, so that the user could choose between storing data locally (storage with database backend) or in the cloud.
I hope this answer gave you a little insight of some possibilities with OOP in database-related parts of your application. Again, this is not the one correct way to do it, just one I found working quite well.
Try ORMLite
Object Relational Mapping Lite (ORM Lite) provides some lightweight functionality for persisting Java objects to SQL databases while avoiding the complexity and overhead of more standard ORM packages. It supports a number of SQL databases using JDBC and also supports Sqlite with native calls to Android OS database APIs.
http://ormlite.com/sqlite_java_android_orm.shtml
http://sourabhsaldi.blogspot.in/2012/10/ormlite-tutorial.html
I am making a dictionary kind of an app which uses SQLite. I have a single table that keeps the pair of foreign words and their translations. I want to sync this table with a particular spreadsheet in Google Docs.
I ve found this awesome library to retrieve and manipulate GoogleSpreadsheets, so at least I am covered for that. But I donT feel comfortable about the sync. Now,
Can I use a SyncAdapter to do this sync between my SQLite and a GoogleSpreadsheet? If yes, how would I go about it? Would I retrieve and manipulate the rows of the spreadsheet in the onPerformSync or smth?
What could be the other alternatives for such a scenario? Should I maybe use a normal service to do the check when the user requests it (in the main activity, for example) ?
On the Google I/O vids (particularly on Android REST client apps ) they seem pretty persuasive for using the SyncAdapter but I am not sure if it could help me without an actual REST service.
Thanks in advance..
One good reason to use the Android SyncAdapter, ContentProvider and SyncManager is that you will benefit from the Google system knowledge that is useful for preserving battery life and other resources. Some of this content is in the video you link to. For example, exponential back-off logic to prevent wasteful attempts at synchronizing.
There is some good info about battery life preservation by conserving cell radio power in today's Google I/O 2012 talk "Making Good Apps Great: More Advanced Topics for Expert Android Developers." While not mentioned explicitly, I think that the SyncManager is likely to have the battery conserving properties that are mentioned in this video.
Based on my reading (not actually implementing anything) of the APIs and other resources such as the com.example.android.samplesync package, it seems that the pattern is flexible enough to adapt to your program needs.
The team I'm working with has implemented custom sync for our android app but I can tell you we didn't consider this option because we were committed to writing as much logic as possible to run with the WebView. I wouldn't necessarily recommend that, but that's beyond the scope here.