Are there any other database engines that could be used on the iPhone, besides sqlite3? Something like textDb is for PHP, single-file and no server.
There are a slew of alternatives to SQLite, but there is little point to using them as others have pointed out.
Before pointing out some alternatives, some points:
First, SQLite is an excellent single-file, non-client-server, small-footprint SQL database. The performance is excellent, it is a relatively tiny runtime, and it is thoroughly fast. There isn't an embeddable SQL-interpreting alternative that is either all around technically superior or anywhere near as popular.
Secondly, if you are doing persistency in an iPhone application, you should very likely be using CoreData. There are certainly reasons not to, but they are pretty uncommon. Beyond being a higher level mapping to a relational store that is quite adeptly integrated with Cocoa Touch, Core Data solves a number of very difficult problems above and beyond persistency; object graph management, efficient memory use (i.e. push stuff out of memory when no longer needed), and undo support, to name a few.
Finally, if you do decide to use some other database persistency layer, keep in mind that the iPhone 3G and prior is an extremely memory constrained runtime environment. The very presence of any kind of additional library can significantly reduce the working memory available to your app. Whatever solution you choose, make sure it is optimized to use as little memory as possible.
So, seriously, if you are looking to not use SQLite or CoreData it is either because you have a very rare case where they aren't appropriate or because you are being curious. If curious, well... good for you!
If you are looking for alternatives, the SQLite documentation includes a set of links to similar products.
Pretty sparse list and it isn't because the author is hiding anything. There simply isn't a lot of motivation in the industry to try and re-invent this particular wheel because SQLite does a really good job. There is a reason why Google, Adobe, GE, FireFox, Microsoft, Sun, REALBasic, Skype, Symbian, Apple, and others have pretty much standardized on SQLite to solve their non-client/server relational persistency needs; it just works.
If you're looking for an alternative, I would say Core Data.
I had the same question for a long time and even used SQLite in some projects. After speaking with an Apple Engineer though, he pointed out that Core Data could do everything that I was using SQLite for (mainly just storing information and accessing it in a few different ways).
I would start with the with Core Data Programming Guide and see how it works for what you're looking to do.
I think your problem is that you are thinking of a software library more like a software product. People want choice between Internet browsers for all sorts of reasons. But when you have a software library, it's pretty much set up for one purpose. If it doesn't fulfill that purpose well enough, it shouldn't be a library.
Do you not like NSObject? Do you not like the Core Foundation library? Then write your own. However, to drag up an unfortunately overused analogy, don't reinvent the wheel, unless your job is making new and innovative wheels.
SQLite does perform acceptably, and so it is supplied as a library on the iPhone platform. SQLite works for what I need it to do. If it doesn't work for you, then maybe you have some reason you'd like to share?
Freedom of choice is fine if you want to choose between Internet browsers, but I would think that as a programmer, one should have a very specific reason for going out of their way, spending valuable time to fix something that already works. Even with my choice of Internet browser, I have specific reasons I choose one over another.
No. Everyone seems to be happy with SQLite.
Related
iPhone 3.0 support the Core Data, it seems a great tool for developer. But SQL statement seems it is easier to get start, but core data is easier for maintaining db. But I'm considering the SQL statement, because it seems have better performance. I am consider which one is better for iPhone development, any suggestion?
The answer is actually much simpler than either of those blog posts make it appear. The rule is:
If you are developing for any OS X platform;
If you are not accessing a proprietary format; and
If your persistence file does not need to be read on a non OS-X platform
Then you should go with Core Data. It is that simple. Core Data gives you so many features and the ease of use compared to straight SQL makes the choice simple. As far as performance, that is a red herring. Where it counts, Core Data can and does easily out perform custom code accessing a SQLite database. However, performance on Cocoa Touch is actually a secondary concern.
The primary concern is memory. You have a tiny amount of memory in which to work with on Cocoa Touch and your data model can easily blow that out. Core Data solves that issue. It watches how much memory it is using and will drop objects out of memory automatically when it receives a memory warning. All of that fairly complex code you would have to write yourself if you used SQLite directly.
Less time coding your data model means you have more time making your application great.
This provides a reasonable list of the pros and cons of either approach: http://maniacdev.com/2009/09/iphone-sqlite-vs-core-data-–-which-to-choose/
The recommendation is to use Core Data as it makes things so much easier in the long term.
There is an in-depth explanation of the differences between the 2 here: http://cocoawithlove.com/2010/02/differences-between-core-data-and.html
That's a great read. The 2 approaches are different and both have their pros and cons.
By using somebody else's works you advertize the authors of those works (At least, among other programmers). Do you think it is cool?
This line of questioning could go up one more level and become "Programming Languages: Do you think it's cool to use those?" Because someone(s) wrote those too. I can continue this up to the types of computers, to the components, etc...
Monet did not make the brushes or the paint or the canvas (well maybe, not sure). But who creates those building blocks is not quite what stands out at the end.
Languages/Frameworks/etc were built and released to be utilized by the masses (or make money for the creators).
I think it's always cool. Be more efficient, reduce redundancy, promote other useful code.
If you're trying to learn though, reading and understanding the framework you're using is very helpful. There are always other things you can be programming and learning, not necessarily reinventing the wheel.
If using their work has saved you time reimplementing the same thing (but with more bugs) then don't they deserve credit?
Or put another way, stealing other peoples' work without credit (or paying them, depending on whether we're talking about free or commercial software here) isn't cool.
Of course, nobody's stopping you from writing your own framework, if that's what you want to do...
It depends on what kind of programming you're doing.
Are you doing it to achieve a finished program? Then a framework could save you a lot of time.
Are you doing it to create something truly original? Then a framework might simply tie you into an existing way of thinking.
Rembrandt made his own paints. Michelangelo selected his own marble from the quarry. Alan Kay said "People who are really serious about software should make their own hardware". The Excel team famously has their own compiler. The iPhone ain't just an alternate firmware for the Blackberry. ISTM if you want to be at the very top of your game, you've got to get down and dirty with the nitty gritty of it.
I don't know anything about advertising, other programmers, or what's "cool", so I can't respond to those parts of your question.
I've seen several approaches, and each seem to have significant plusses and minuses. I'm learning iPhone development, I'm building a relatively simple app, which, at it's core, is really not much more than CRUD operations on 3 or four related entities.
I'm used to ActiveRecord-type object persistence. The implementations for Cocoa Touch that I read about online are commonly referred to as extremely slow.
Most of the examples I see online (specifically the Pragmatic Programmers screencasts) have SQL hardcoded into the controller class, which doesn't seem... right to me. Seems very old school (but maybe old school is best in this case).
I know we can't discuss SDK 3.0 here, but it's common knowledge that CoreData is coming for the iPhone, that would of course limit my audience (I'm not sure I really care about that this much. It will be an app for sale, but I'm not planning on it replacing my career)
I have not tried Gus Mueller's FMDB yet, but I have read good things.
What are some of your experiences, what works, and what doesn't. Where would you recommend that a (still pretty novice) iPhone programmer invest their time?
Right now there's a lot of semi-raw SQL encoded in apps because there's no built-in system for higher level work. FMDB is a nice way to do this but it just wraps the SQLite calls into something more Objective-C like. It's great for some situations but obviously not for everything.
If you're familiar with ActiveRecord then SQLite Persistent Objects may be useful to you, because it's intended to be similar to ActiveRecord. I haven't used either so I couldn't tell you how similar it actually is. If that doesn't seem right for some reason, it's probably best at this point to target 3.0 and make use of Core Data.
Coming from a non-SQL background, I've been having a hard time absorbing SQLite3 for the past few days. Has anyone had any good results using any of the SQLite3 wrapper APIs out there? Do they work reliably? Which is best? I am also hearing buzz about Core Data coming to the iPhone. Not sure whether that info is trustworthy or not but maybe some of you know: will there be a Core Data for the iPhone at some point?
FMDB is easy to use and abstracts some of the SQLite nastiness away from you, but still exposes the SQL.
I have used it in a project, but subclassed it to add my own partially-OO layer. The advantage of this approach is that if I need more speed or something I did not foresee (triggers for example), I can make it happen. With Core Data, there is no "bypassing" available and I have to rely on Core Data's optimizations, memory use, etc.
Another difference is the Core Data will allow your app to remain fully OO. With FMDB or other database solution, you're always tied closely to the organization of the database. It's a design decision, and not one you can change later.
If you're only just starting now, I would use Core Data.
I spent some time last year looking at the various wrappers at the time. I didn't use any of them in the end.
I think the NDA was still in place when I was looking so I may have missed the best ones, but I found that most were very thin wrappers. For my purposes this meant that it added an external dependency, didn't save much typing and I would probably still have had to dive down to using sqlite function calls sometimes anyway. Just didn't seem worth it.
Why not target CoreData using the 3.0 SDK?
If for some reason you need to support 2.x, you should look at SQLitePersistentObject. It's slow and has some bugs but it is VERY easy to use. Sadly it is no longer under active development by the author.
Additionally:
Some time ago, with a small sample project (2.x) I used fmdb. As far as I remember it was pretty easy to use. However, it required SQL knowledge.
At what level of complexity is it mandatory to switch to an existing framework for web development?
What measurement of complexity is practical for web development? Code length? Feature list? Database Size?
If you work on several different sites then by using a common framework across all of them you can spend time working on the code rather than trying to remember what is located where and why.
I'd always use a framework of some sort, even if it's your own, as the uniformity will help you structure your project. Unless it's a one page static HTML project.
There is no mandatory limit however.
I don't think there is a level of complexity that necessitates a framework. For me whenever I am writing a dynamic site I immediately consider a framework, and if it will save me time, I use it(it almost always does, and I almost always do).
Consider that the question may be faulty. Many of the most complex websites don't use any popular, preexisting, framework. Google has their own web server and their own custom way of doing things, as does Amazon, and probably lots of other sites.
If a framework makes your task easier, or provides added value, go for it. However, when you get that framework you are tied to a new dependancy. I'm starting to essentially recreate a Joel on Software post, so I will redirect you here for more on adding unneeded dependencies to your code:
http://www.joelonsoftware.com/articles/fog0000000007.html
All factors matter. You should measure how much time you can save using 3rd party framework and compare it to the risks of using other's code
Never "mandatory." Some problems are not well solved by any framework. It would be suggestible to switch to a framework when most of the code you are implementing has already be implemented by the framework in question in a way that suits your particular application. This saves you time, energy, and will most likely be more stable than the fresh code you would have written.
This is really two questions, you realize. :-) The answer to the first one is that it's never mandatory, but honestly, parsing HTML request parameters directly is pretty horrible right from the start. I don't want to do it even once, so I tend to go toward a framework relatively early on.
As far as what measurement is practical, well, what are you worried about? All of the descriptions that you list have value. Database size matters primarily for scaling, in my opinion (you can write a very simple app if you have a very simple schema, even if there are hundreds of thousands of rows in the database). The feature list will probably determine the number and complexity of UI pages, which will in turn help to dictate the code length.
There are frameworks that are there for getting moving very quickly with a simple blog, django or RoR all the way to enterprise full-stack applications Zope. Not to be tied to just the buzz world, you also have ASP.Net and J2EE, etc.
All frameworks and libraries are tools at your disposal. Determine which ones will make your life easier for your given project and use them.
I would say the reverse is true. At some point, your project gets so expansive, that you actually get slowed down by the shortcomings of the framework. For sufficiently large projects you may, in fact, be better off developing your own framework, to meet your own needs. I have seen many times where people were held back in the decisions they could make, or the work they could produce, because they were trying to do something that the framework didn't anticipate. And doing these things that the framework doesn't anticipate can be very troublesome. The nice thing about making your own framework, is that it can evolve with your project, to be a help to you system, instead of a hindrance.
So, to conclude, small projects should be use existing frameworks. Large projects should contain their own framework.