my app needs to read some data exported from a SQL database. In addition to reading, the app should also query the database in order to find relations between different data.
Potentially, the amount of data can be very large.
Of course, everything should be responsive and not impact negatively of the user experience.
Here is my doubt: I was going to export the database in XML format and run queries by using XPath but I'm not 100% sure that this approach is going to be efficient enough, especially if the number of records in the database is around thousands.
What can you guys tell me about the efficiency and performance of XPath in iOS? Is that a good solution for large XML database?
Would Sqlite be a better and more efficient approach? By using Sqlite, am I risking to make my app heavy?
Thanks!
You definately should use SQLite over XML in iOS apps. I would recommend the best wrapper for such a database: https://github.com/ccgus/fmdb
With FMDB + making queries in background threads the performance of app shouldn't be affected at all, even with big DB.
Many of my iOS applications use data stored in SQLite databases. I have good trust in SQLite databases.
Some of my databases have more than 30000 elements in tables and applications make complex queries such as filtering/grouping by criteria. It is quite fast.
The best way to create your SQLite data is to export as CSV from your original databases and to import data in a new SQLite database.
You can find an example here.
Related
AFAIK CoreData can be configured to use sqlite in the persistent store.
so as core-data not provides way to query using SQL.
So core-data has sqlite db in background.
Is it safe to access same db using Core-Data and Sqlite c based api same time?
Will it lead to any data corruption is sqllite or any threading issues.
the reason why am I going to use any wrappers such as FMDB or C based API is to query complex data using sql query
It's probably safe but it's still a really bad idea. Core Data defines its own schema, which is undocumented and which is different from what you would use if you designed a SQL schema. So you'd have to create the Core Data model and then reverse-engineer your own schema to make direct SQL calls.
Also, of course, it's going to be an absolute pain in the ass to keep changes in sync across completely different calling styles.
This is a bad idea, even if it doesn't corrupt your data. You will regret using this approach.
I've done this in the past, before concurrency and subquery expressions existed. I had to make Core Data save everything to disk before using sql. It worked then but you never know if it will work in a future OS X. Nowadays I wouldn't do it. If you need complex queries, use Sqlite only or use Core Data and be creative with predicates and fetch requests.
I am creating an app that will show users what the statuses of some devices are. The status can change at any time and the users will be able to refresh the data. I want to use a way of storing the data so users are always able to see the latest state without needing an internet connection and to reduce the loading time.
I am currently deciding between Core data and SQLite.
For my situation, which one should I choose and why?
First of all Core data is not a database. So if you have feeling of database usage in future than move to SQLite.
Core data is a framework that manages object graph. Core data persist that object graph by writing it to disk.
Where as SQLite is a lighter version of SQL, So it limits some complex functionality of SQL language, And yes it is a pure database.
Core data is not a database how ever you can manage object and entities as like database tables and attributes as a columns.
Conclusion:
Go for Core data, it will reduce the time of database connection opening and querying. As I said it is not a database so all database limitations are not in a picture.
Core Data is the best option to use but if somehow you want to port the application to android or windows and want to keep the code similar then you can go for SQLITE as SQLite is supported by all major platforms. Whereas core data is only part of iOS
Using CoreData is always a better option.
Core Data is built on top of SQLite, so you work on SQLite either way :)
Core Data works with Objects so no worries working with Queries.
Complex queries and data retrieval is easier.
Database locks and other sync errors are auto handled.
Finally, it has everything that you require at the moment.
What the best way and how to work with multiples tables in iOS project and does FMDB supports relationships between tables?
Should I use Coredata or the FMDB wrapper?
Whatever you want to do, you can use either Core Data or FMDB + SQLite.
Basically, if one of the follow is true, I suggest using SQLite.
Performance is really important
You already have a huge SQLite database from elsewhere
You plan on making the database cross-platform somehow
Have a look at this blog post to read about the difference between SQLite and Core Data.
However, in most cases Core Data is a better way to go. Core Data is a great framework that helps you keep your consistency (using object graphs) and is really quite easy to use. It has received a bad rep for its performance, but it is actually not that bad. For instance, over-fetching is a common thing that is used to improve performance. This means fetching lots of data and then filtering out the data you actually want. This works great in iOS devices since their RAM is actually really good these days. Use it!
Also, if you plan on using Core Data, you should understand that it is NOT a wrapper for SQLite. You should not be thinking about tables like you normally would. In Core Data you have an object graph with entities instead of tables.
Conclusion:
Use Core Data unless you already have a SQLite database form elsewhere OR performance matters a lot (and I mean a lot).
There is no one good question for this. It's depends on project.
In my opinion if you have already some data which you want to import to the application, and you will facing huge amount of data in your database, you should go for pure sqlite (and maybe FMDB).
If you are connecting to REST, want to use TableViews, starting from empty database CoreData will right answer for you.
FMDB is only a wrapper on sqlite so it will have relations, because sqlite has.
We are currently using postgresql for our production database in rails, great database, but I am building the new version of our application around SQLite. Indeed, we don't use advanced functions of postgres like full text search or PL/SQL. Considering SQLite, I love the idea to move the database playing with just one file, its simple integration in a server and in Rails, and the performance seems really good -> Benchmark
Our application's traffic is relatively high, we got something like 1 200 000 views/day. So, we make a lot of read from the database, but we make a few writes.
What do you think of that ? Feedback from anyone using or trying (like us) to use SQLite like a production database ?
If you do lots of reads and few writes then combine SQLite it with some sort of in-memory cache mechanism (memcache or redis are really good for this). This would help to minimize the number of accesses (reads) to the database. This approach helps on any many-reads-few-writes environment and it helps to not hit SQLite deficiencies - in your specific case.
SQLite is designed for embedded systems. It will work fine with a single user, but doesn't handle concurrent requests very well. 1.2M views per days probably means you'll get plenty of the latter.
For doing only reads I think in theory it can be faster than an out-of-process database server because you do not have to serialize data to memory or network streams, its all accessed in-process. In practice its possible an RDBMS could be faster; for example MySQL has pretty good query caching features and for certain queries that could be an improvement because all your rails process would use this same cache. With sqllite they would not share a cache.
So this is more or less an implementation question, this is the senario I have, basically we have an app which uses MySQL as it's datastore, user accounts, transactions etc, but we want to add in a robust charting feature and the data will be stored in Redis, now basically my question is:
Is it possible, and what are the best practices for integrating another datastore into an app which already depends on another one. Can I use Rack to generate the reports? etc...
I want to turn this into a sort of open discussion because I think the need for a solution like this is going to rise as we see more and more key/value stores that offer benefits far different than a RDBMS, an NoSQL stores as well. They all have their benefits but no one solution covers them all.
Thoughts?
You can have models that do not inherit ActiveRecord::Base. Add your preferred Redis client gem, do whatever config is necessary, and start writing Redis models.
I can try to reopen this topic, because should be very practical.
Have same issue with this. I want to replicate data from SQL to NoSQL. SQL used as main database storage, because data integrity, relations etc. And NoSQL as secondary database storage set for reading. In SQL you have much associations divided to much tables. Many one-to-one association saved in different tables for better readability. This associations should be saved as one document with NoSQL. It gives unbelievable speed. Only one load. Great for data exchange for API.
Do someone positive experience with replication SQL data to more consistent NoSQL documents?