I am just starting to study and develop Mac OSX applications, and I'd like to design an app that uses a database.
I'm not opposed to something like MySQL, but I'm looking for something that can be single user and can be stored directly on the device so internet access is not required. I'd prefer not to resort to writing/reading from a file either.
The closest I've come to find is SQLite, which I am familiar with in Android development, but my question is: is that what most OSX developers use?
I am trying to pose this question in a way that is not opinion-driven, as I know there are countless DBMS out there. Is there one that leads the pack as far as being used with OSX?
Higher Abstractions:
Core Data is available on iOS and OSX.
Realm is a popular alternative to Core Data. Some of the features include:
Fast
Memory efficient
Its safe and easy to use across multiple threads (core data can be tricky here).
Like Core Data it uses the Active Record pattern, where persistence methods are defined on the model objects themselves (unlike the DAO pattern, which uses a separate interface).
Lower Abstractions:
FMDB is a nice Objective-C API that sits over the pure C API to sqlite.
Related
I am an novice programmer and I need a little direction.
Here is the concept of what I am looking to do:
Let's say I have an iOS and or OS X app for let's say storing people's names and phone numbers. Now I want to be able to have multiple people to be able to use the same app on different devices and access the same database; read and write values at the same time.
I am moderately well versed with Core Data and I have found that it works well but is not capable of accomplishing what I am trying to do.
Could someone point me in the right direction to find resources where I could learn how to do this? Thanks.
I apologize if the question has been asked before; I tried to do searches but I didn't know exactly what to search/could not find what I was looking for.
It seems that what you want to achieve will require an external database storage, which would provide an API that both your iOS and Mac OS apps will use in order to read/write to this common database.
There are plenty of resources on how to setup a database and an API. A pretty simple (yet heavy) approach would be to create a little web server in the language of your choice (PHP, Ruby on Rails, Node...) that exposes a hosted database, and communicate with that API from your apps. My advice if you are a beginner, would be to have a look at RoR to setup a simple web server/Restful API that exposes a MySQL database: http://guides.rubyonrails.org/getting_started.html.
If this is not the answer you're looking for, maybe you want to use iCloud in order to keep your data in sync between devices. However, this is not applicable in a multi-user land (e.g. this will work fine for multiple devices of the same user).
I have been working on an app that uses Parse as its backend and while this works well, I don't want the app to become too dependent on Parse to work. Having the apps own Core Data implementation is probably the best way to go but the implementation must be flexible so that it can support syncing etc. I have been looking into frameworks like Ensembles, MagicalRecord, iOSDataManager and a number of others. I even looked at FTASync but this has not been updated for years and does not have a good reputation. I felt to ask the community what others may recommend as a good design of a backend system to sync with Parse or other web service. Particularly considering how important the backend is...
Thank you
I have used Ensembles, and I recommend it highly. The open source version is probably fine for your use, with the version 2 version available if you find you need any of the benefits for the paid upgrade.
If you want to see how to build a backend agnostic interface, then I also highly recommend studying the ensembles framework, especially how the interface for the cloud file system interface.
I have implemented my own backend for a specific project, and the interface is quite clear, and extremely useful for teaching one how to design and build such an interface.
I am a beginner iOS developer and looking for a easy to use database wrapper library to use SQLite in iOS (Iphone, Ipad) applications. So far, I have found FMDB.
What do you guys use to make enterprise wide Iphone database application? What is an easy to use and reliable DB wrapper library that I should look into.
Yes, if you need/want direct SQLite interaction, FMDB is an excellent choice. It offers a simple and robust interface to the SQLite C API.
You might also want to consider Core Data, the iOS framework for "object life-cycle and object graph management, including persistence," which generally uses SQLite behind the scenes.
As the Core Data documentation says "Core Data is not a relational database or a relational database management system (RDBMS)." The Core Data Technology Overview clearly delineates precisely what Core Data is and what it is not.
Having said that, for many applications, it offers a number of advantages over interfacing directly with SQLite, itself, and its worthwhile considering Core Data before you simply dive into SQLite programming yourself.
What are the best local iPad databases?
CouchDB or SQLLite? Which is better?
What does Evernote use? What does Foursquare use?
I do not know what databases Evernore or Foursquare use on the iPad.
SQLite is currently the "best" database for mobile because it is already included and it is so small and light-weight. SQLite is one back-end in the Core Data API (which is most likely what Foursquare and Evernote use).
However, CouchDB is also very light-weight but it is not yet easy to use on iOS. If/when it does become easier, it will be ideal for mobile because it supports local, offline operation and has built-in synchronization with the central database.
Choosing from these two requires more thoughts:
For couchdb, the db is document oriented.
It also is using webservices(so you will have to handle these properly) and the basic CRUD is done via REST.
Pro:
If your app wants to replicate data to or from the outside world, couchdb handles this very easily and you have the ability to write couchapps, basically webapps running directly on the couchdbserver. These could be delivered as natve IOS apps, I assume, as it is now possible for Android: link
I am not familiar with basic patterns about handling data in IOS, but using a "driver" to use couchdb should be evaluated as well: http://www.couchone.com/page/couchdb-drivers
I am thinking about using SQLite
It is a self-contained, server less, zero-configuration, transactional SQL database engine and is open source.
Will I gain anything by using Blackfish instead of SQLight ?
Why not Firebird?
http://www.firebirdsql.org
http://www.firebirdfaq.org
"...Firebird is a relational database offering many ANSI SQL standard features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers. It has been used in production systems, under a variety of names, since 1981...."
Stick with FOSS (Free Open Source Software).
Both SQLite and Firebird are excellent choices. Both fill your requirements. Both are very reliable, zero-configuration and support transactions.
Without knowing enough about your intended use, Firebird would be my first choice because it makes possible to migrate to a Client Server deployment with close to zero effort and it has a very robust set of features. It is all about the options.
IMHO Blackfish is not a god choice - "Blackfish SQL runs on both the .NET framework and on the Java platform." - enough said.
Use SQLite.
Much smaller, less overhead, no licensing issues etc.
Laslty, only you can decide which one will do everything you need a db system to do. Which one has all of the features you need to support?
John
I will vote for Sqlite first, because it's compact, lite and fast, but depend on your application you may go with other choices like Firebird or PostgreSql.
for example Sqlite has limitation to one writer at the same time, it may not be problem for most of desktop applications that used by one user, but it will not scale for more uses in future.
you can go with FireBird embedded as solution which will be act like Sqlite, then move to firebird server when you need more users.
In other side BlackFish database, will force you to install .Net framework on your client's machines, which is something isn't good IMO, specially if you need to distribute your application on Internet, beside it will require license when it scale for more than developer edition.
Another thing to consider is how are you going to access your data. If you are using DBX4 for instance, it is very easy to change what database you are looking at. In which case I would suggest trying both (plus any others that people highly recommend you try). On the other hand if you are using the the Interbase or ADO data access components then your ability to change is somewhat more limited.