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 2 years ago.
Improve this question
I'm working on a 'mental wellness' app, functionality for which includes things such as making journal entries (typed and voice recorded), recording affirmations, creating to-do lists, setting goals/targets etc.
My question is, should I store the user data from the above such actions locally, which gives the user a greater sense of control over their privacy or should I store it on our server in an encrypted DB?
My initial instinct was to go both to allow users to use to do things such as make journal entries even without internet connection, which can then send that data to server/DB once online again. But wasn't sure if this was a major drawback in terms of users privacy i.e. their 'private' journal entries being on our server/DB, albeit encrypted and widely used facilities i.e. AWS, Firebase, Azure. The obvious benefit of having it on server side DB is that they can use different devices such as phone and tablet or can have access if they move to a new device e.g. get a new phone.
But then the alternative I thought of was having users data all stored locally on device and then allowing them to sync to their iCloud or Google Drive or having the app auto sync. Is this a good alternative or compromise?
Is there a preformative benefit one way or the other?
I would appreciate your feedback on what you would consider the best route from both a user experience perspective as well as the technical best practice.
Many Thanks
Related
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 5 years ago.
Improve this question
This question is a little more generic, a brainstorm one. I'm about to develop a small website, and I still don't know if it’s better for me to store my “Text” (to fill Labels, Messages, etc) data on the Database or just on the frontend.
I know that for a fact, consulting the BackEnd Database is slower than just searching a specific file, but it’s also better to update the list later-on (when the website is developed) by just running a script.
I want to know some opinions, experiences, advantages and disadvantages about both.
Edit: For the technologies, i was thinking in using ExtJS with a Java Backend, I'm not quite sure about the BD yet.
Consider what data you are storing and the purpose of your website.
Advantages of front end storage: quicker
Advantages of database storage: more secure/structured
If your strings are sensitive then I would secure them in your database. Any client information, including "Text" data should be stored on the back end. If the strings are only relevant to you as the site owner then I don't see a problem with storing them on the front end.
Also perhaps specify which technologies you are using to build this site to get more specific responses.
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 6 years ago.
Improve this question
For a small start-up mobile app/website what options are there for storing its data? I.e. Physical server or cloud hosted data base such as azure.
Any other options or insight would be helpful thank you!
Edit:
For some background I'm looking at something that users could regularly upload data to and consumers could query to find results through an app or website.
I guess it depends on your work load and also on the your choice of data store. Generally, SQL based storage are costlier on cloud based solution due to the fact that those can be only vertically upgraded whereas no-sql ones are cheaper.
So according to me you should first decide on your choice of data-store, which depends on following factors:
The type of data; is your data structured or it falls under non-structured category?
Operations that you will perform on the data. Do you have any transactional use-cases?
Write/Read pattern; is it a read heavy use case or a write heavy one ?
These factors should help you decide on an appropriate data-store. Each database has its own set of advantages and disadvantages. The trick is to choose one based on your use cases and above mentioned factors.
Hope it helps.
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
I realise that cookies are stored on the client side, but what I’m thinking about doing is; instead of storing the actual data in the cookie I just store an ID which matches some id in a ServerSideCookie table in my database(Kinda the same way as sessions)
I wondering pros and cons of doing this.
One obvious pro is that this solution is not limited to 4k of data.
Another pro will be that storing data on the server will be less vulnerable than storing it on the client side.
Third pro is that I do not have to worry about cross browser issues.
Con might be that it is slower, although I have not benchmarked this.
I would greatly appreciate some input.
Thanks in advance, Sigurd.
In my opinion, both are valuable depending on context.
On the server
Advantage: no limit on data
Minus: size matters when you have a lot of users. for example 1M user x 2k data = 2G data that is sent back and forth over the wire
Minus: you cannot store info in case you have not an authenticated user
On the client
Advantage: no need to make a trip to the server, you have it locally. it worths for example when you store something related to UI preference of the user (current language, type of view: grid or gallery, etc)
Minus: you cannot store user sensitive data (e.g. card numbers)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've done a lot of research into which architectural database approach is the best, and in the end, I'd prefer the separate database approach. However, most hosting providers are not happy with this (take Azure, with a 150 DB limitation).
My idea now, is to just start with a single database/single schema, use a tenant ID in each column to separate data, and then when it gets too big/slow, look for scaling options.
Is this a bad idea? Should I keep data separated from the start? I feel like security wise it doesn't matter much as long as I verify that the data i'm calling/retrieving belongs to the calling customer.
Also, isn't scaling later on going to be easier with a single big database, as oppposed to having 5000 small databases?
Thanks!
For cloud hosting I think a single multi tenant database is the way to go.
I had the same problem some times ago and opted for one database per tenant since our clients wanted to keep the option of hosting the database on their server. Since we had one code base and many databases on several servers, we had to roll a synchronizing solution to insure that all the schema stayed the same.
We also had some business logic in stored procedures and had to figure a way to distinguish the procedures that had global logic from those that had a logic specific to this database.
it worked but it was awkward and I wish we could have used a single database
Anyway, like said before each way has pluses and minuses, you just have to decide what is the most important to you and work around the minuses
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to figure out if http://docs.phonegap.com/en/1.2.0/phonegap_storage_storage.md.html can handle versioning, conflicts, etc. similar to CouchDB's capabilities.
I'm building a mobile app wherein friends can share data. This data will be manipulated (add, edit, delete) when the app is online or offline. During offline operations, the data changes will be stored locally -- and then sync to a central database when it goes online (and everyone else will sync to that central database).
Obviously, there will be versioning, conflicts, etc. issues. CouchDB supposedly handles this well. However, I want to know if PhoneGap's storage is sufficient for my needs. Will it work or not?
sqlite has plenty of power for this kinda stuff, though even localstorage is pretty powerful unless you are manipulating data with heavy javascript. I say try localstorage first as it's very very easy to handle.