Currently i have an application that creates 2 types of models (let's call them A and B).
A has a 1:N relationship with B, and right now i have a database implemented in both the handheld and the wearable to store those models.
The problem is, I need both of those data storage synchronised and I'm not entirely sure how to accomplish this. I have seen many docs referring to the dataApi where they suggest that you save your data in a DataItem object, which will get synchronised each time the wear connects.
What I'm not 100% sure about this approach is:
Is DataApi a reliable data storage? (enough to replace SQLite Database in both handheld and wear)
Can the DataApi support search operations (for example, all B objects that object A has)? and if so, how can you do that search?
Considering that each DataItem corresponds to an entity, is there a limit in how many DataItems can i save?
Documentation on the subject seems a bit lacking at the moment, so i'm not sure if DataApi is the correct implementation i need or if i have to send raw data in a message to sync databases.
For first question
Is DataApi a reliable data storage? (enough to replace SQLite Database
in both handheld and wear)
The DataApi is not recommended for a complete replacement for SQLite database as said in the SO answer https://stackoverflow.com/a/34137544/6452886
Related
I am doing homework on restAPI using Go and MongoDB. But I'm still wondering:
As for whether I should create a dictionary to store data at the model level, it will help me to retrieve data much faster without accessing MongoDB. But the big problem here is to synchronize the data under MongoDB and in the dictionary that I created.
In file models/account.go I have a struct Account and in MongoDB I also have a collection Account to save all account information of the website. Should I create Accountlist to store all the data in the database to increase performance?.
Source as below:
var AccountList map[int]*Account
type Account struct {
ID int
UserName string
Password string
Email string
Role string
}
As with many things in software, "It Depends".
There's not enough information about the systems involved, how often the data is being queried, mutated, and so on to give a concrete answer. But because this is for homework, we can give scenarios.
The root of your question is this: should you cache results from the database?
Is it really needed?
Academically, it's OK to over-optimize. You get to play with technologies and understand how they work. In the real world, we should understand where the need for something is before implementing it. The more complex a solution is, the more important making a correct trade-off becomes.
Caching is best when you're going to use the results more often than they're going to change, and fetching from storage is expensive.
"Expensive" can vary. One operation measured in seconds can be expensive. But so can tens, hundreds, or thousands of operations close together measured in 100ms.
How should you do it?
You called out a couple drawbacks. Most importantly:
But the big problem here is to synchronize the data under MongoDB and in the dictionary that I created.
Synchronization is the most important thing for any distributed system.
It doesn't matter how you cache values if you have one server instance. But once you start adding instances, things get complex.
A common pattern for caching is to use a distributed key-value store. They allow you to store results which can be shared across applications — and invalidate them.
Application checks to see if the key exists in the store.
If so, use it.
If not, fetch from origin and update the cache for next time.
Separately, invalidate the key any time data needs updating.
There are a bunch of products to use. Redis is popular, memcached works. But since you're using Go, checkout groupcache: https://github.com/mailgun/groupcache. It was written by Google to simplify dl.google.com, and extended by Mailgun to support TTLs.
I have some Json Data I am getting from an API, I want to store it for later use, in case the user has no Internet connection. But I am not sure what my best option is to save it.
I was thinking about using sqflite, but in my use case I will need to fully replace all entries, so I would have to delete and rewrite about 300 columns, split between 5 tables, pretty regularly and I am not sure if that is ideal.
I also considered just saving the Json file to device storage or even using shared preferences.
Do any of you have experience/ideas on what my best option would be? Will sqflite be slow if I use it? Thank you
I think using sqflite would be the best option when it comes to persisting data if you want to create an offline cache for the user.
Using shared preferences would be slower as NSUserDefaults and its Android counterpart are not designed for high performance read/write operations therefore any insert, update and query operations would be slower in general if you handle big amounts of data.
Saving the Json file to device storage would be in my opinion the lest performant option if you have to query it afterwards as you would have to serialise/deserialise whereas if you use the database you'll be able to quickly query data and instantiate your on model objects etc. I'd recommend you to follow a layered approach if possible (using a Repository to feed your View Models or Blocs etc and a separate DB Manager/Service etc.
I'm not sure if stack-overflow is a right platform to ask the title question. I'm in dilemma as to which front-end and back-end stack should i consider for developing a health related web application?
I heartily appreciate any suggestions or recommendations. Thanks.
You will need to have a look at your data, if it is relational, I would personally go for a SQL server such Microsoft SQL Server, MySQL or Postgres. If your data is non-relational you can go for something like Mongo.
Here is an image that explains how relational data and non-relational data work:
I'm not saying that MongoDB is bad, it all depends on your data and how you would like to structure your data. Obviously when you're working with healthcare data such as patient data there are certain laws you need to adhere to, especially in the United States with HIPPA, but I am sure almost every country has one of those.
The implications might be that you need to encrypt any data stored in the database, and that's one of the benefits of a relational database as most of them have either TDE (Transparent Data Encryption) or Encryption at Rest. Which means that your data is secured when in use and when not in use, respectively.
When it comes to the front-end you can look at Javascript frameworks such as Angular, Vue, React and then for your backend you can choose pretty much anything that you know well such as NodeJS or .NET Core or Go, pick your poison, each of them have their advantages and drawbacks so you will need to investigate your options before committing to one or the other.
It depends on your data structures. You can use MongoDB with dynamic schemas that eliminates the need for a predefined data structure. So you can use MongoDB when you have a dynamic dataset which is less relational. In the other hand, MongoDB is natively scalable. So you can store a large amount of data without much trouble.
Use a relational DB system when you have highly relational entities. SQL enables you to have complex transactions between entities with high reliability.
MongoDB/NoSQL
High write load
Unstable Schemas
Can handle big amount of data
High availability
SQL
Data structure fits for tables and row
Strict relationships among entities
Complex queries
Frequent updates in a large number of records
I need to know what should I use to store the property?
I'm still confused. Should I use SQLit or core data?
I will have a lot of data, user data and real estate data. It will also appear in the map.
Core Data contains sqlite as a storage facility. It's not an actual database, but rather a graph database.
SQLite on the other hand is a database. Different methodology, can be used for small chunks of data (I use it extensively) efficiently and mostly to implement a pure RDBMS system (with primary/foreign key, unions, and stuff like this, SQL powered).
For Core Data, you use graph relationships (which means objects connected to other objects by references).
The outcome is the same, different programming though, depending on the complexity you want to have (or actually have designed) in your app, so lay down your plans to see which one suits you. For SQLite I recommend FMDB wrapper, since it's easier instead of doing 2 to 3 checks for every SQL statement.
Your app seems interesting, and since it's real estate based you might want to spice it up a little bit later with a small technology called "augmented reality" :)
Is Core Data still a good option to use for the iOS even if they data will only be quite temporary. i.e – data being sent up to a server in the cloud once within range of a network, and then never needed again on the mobile device.
You don't have to use Core Data to persist data.
If you don't want to persist the data at all, you can define an in-memory store which never writes to disk.
Core Data's true function is the management of an object graph i.e. it handles the relationships between objects. It's real advantage is the ability to automatically handle complexity.
That complexity can arise from the data objects themselves or from their needed relationships to controller or view objects. Either way, Core Data makes it easy to tie all the objects together without great gobs of custom code. Where the objects end up being persisted or even persisted at all, is really secondary.
Yes, if there could ever be a large number of records (e.g. user is overseas, doesn't have a data connection), use Core Data. The point of the Core Data abstraction is just this - if you only have 10 records max, ever, it may just use a flat file of data, or maybe a Sqlite database if more than that -- by "handing the problem" over to Core Data, you make storage decisions Apple's problem, and for free you'll get all the optimizations that Apple'll throw into the Core Data framework in the coming years.
Core Data is complex when you first look at it. Apple's API docs aren't bad, but there are a few "gotchas". If you've worked with anything like the Entity ORM framework, etc, it's really easy to pick up.
Alternatively, if you're reasonably certain that you're only going to get 5-10 records, and the data is anything that conforms to NSCoder, you could just archive it and save it, and then unarchive it when you launch the app. Also, if it's array data, a plist is pretty nice.
The approach I take is to insert entities into a NIL context and provide a base class for insertion into a valid context when I wish to persist them. Code can be found here... Temporary Core Data