04-29-2009 10:29 PM
I'm considering porting my iPhone apps to Blackberry and need some sort of sql database to store data.
I read around and it doesn't look that there is built-in one, right?
The persistence store is not acceptable solution for me.
Any ideas when and what database may be coming to this platform?
I read somewhere that RIM is planning to have sqlite...
04-30-2009 01:35 AM
UltraLite®J mentioned as FREE DEVELOPMENT SOFTWARE FOR BLACKBERRY.
May be its only free for developers and need to pay for use by end users.
04-30-2009 01:53 AM
Yes, it's only free to develop with. The moment you go to production and release the code you need to license it (not cheap).
A friend at Sybase confirmed for me that the ULJ database just uses the persistent store so frankly it's just bloat ware since it adds yet another layer of code to make an app bigger and slower. The only benefit is it's MobiLink sync server support.
04-30-2009 02:00 AM
Why can’t we have built-in database like any other platform?
iPhone has it, Windows Mobile has it, Symbian has it, why not Blackberry, anyone form RIM?
Would Apache Derby work?
04-30-2009 03:30 AM
What exactly qualifies as a Database and why can't you use persistent store? Personally I've had good luck with
persistent B-trees for most of what I would consider database stuff. You won't have any magic to get ACID
performance and in many cases you won't have multiple users or even threads. For any apps that come to mind,
address book or GPS interest points, this seems to be quite reasonable way to go.
If you really need to make an SQL query, I guess you could dig up a parser somewhere and make a couple tables
to translate field names etc. But, I don't see where it is anything other than a level of bloat ware as other poster suggested.
Sure, for highly dynamic data with many possible conflicts in reads and writes, and additional resources to give you
the ACID features that are important for reliabiliy, you really need a tested product that has provided all of these features.
For storing temp or cached data on a device with limited IO capability and overall resources that will be accessed by
only a few different users, I still don't see what a DB contributes. Generally, it would seem people who reqeust a DB
really just need a persistent datastructure.The only time I've had a problem with this is when updating an
app and I have modified the classes contained in the persistent records but it wouldn't be hard to
devise strategies to export and import data if you needed to preserve data.
I've been using a class I call BonsaiDB ( little trees ) that let's me get the lookup features ( indexes ) I need
for a given situation without having to make an SQL query or even have overhead of multi-user synchronization unless
needed. Since I can usually make some decent guess on a search strategy due to nature of the app, anything
an SQL interface may be able to do seems questionable. I don't need to copy a lookup result from some thing
like an object array into some new appspecific structure or do any other temporary formatting steps.
I'm still making up the interface as I go a long( and hoping to fix implementation issues whenever it becomes an issue)
but generally returning iterators in response to a look up has worked quite well with keys confined to long and String.
04-30-2009 04:15 AM
From your introduction B-trees seem to be interesting.
I will look on it after some time. If you can give any more information about your implementation for better understanding, then please provide us.
04-30-2009 04:40 AM
marchywka I need SQL/Relational database for few reasons: