[ameat]

So i am a web developer by day but have been itching to use java or learn obj c and cocoa to develop a desktop application, and i think i finally have an idea of something that would be useful to me and potentially others...basically something along the lines of the project management app called iwork.

anyways, i was wondering if it's possible to use a relational database such as mysql embedded into a cocoa app, or if there are methods for going about using a relational database type setup for data storage. i realize that there are other solutions such as serializing objects or using xml but it seems like any complicated db schema implemented in a flat way would kill the beauty of a relational database's ability to select data efficiently.

can anyone offer advice on this? thanks

amit

[proton]

You may want to look at SQLite, it's a fully embeddable database engine. There's a Cocoa wrapper available from Blackhole Media that may also help you.

- proton

[ameat]

Originally posted by proton:
You may want to look at SQLite, it's a fully embeddable database engine. There's a Cocoa wrapper available from Blackhole Media that may also help you.

- proton

thanks, i'm assuming that there's a java interface to this as well?

also, for any other developers, are there any other common ways for dealing with data storage in an application other than a relational database? i guess technically you could map your objects to any data source, db or whatever...but for instance, i would want an interface in this app where i could display something akin to a smart playlist, where a user wants to display all of their associated tasks within a project, or all of the tasks that involved programming (or some other field).

i guess the best analogy would be to viewing by genre in itunes. apple stores the itunes database in a flat xml file...i'm guessing they just parse over it at some point for the data? how often? and what happens when you add a genre type which is really a global option, does that data get stores elsewhere? if not, how do they build the listing of genre types? they can't possibly parse the xml looking for unique values...that would take extremely too long.

anyways, any suggestions or common solutions to these questions would be extremely helpful.

thanks

[Brass]

I did read somewhere that someone was developing an Objective C interface for MySQL. I don't remember if they were doing Java as well, and I don't know if it's finished.

Sorry to be so vague. I'm very interested in this sort of thing as well, as it would make a lot easier work of a couple of applications I'm considering. However, I've not really looked into it in any depth.

[jobim]

Originally posted by ameat:
also, for any other developers, are there any other common ways for dealing with data storage in an application other than a relational database?

Good 'ole fashion files. They always work. Which is like saying the key to writing a good book is using a pencil. The key is the structure your files.

If you don't imagine having lots of things to store, you could go the XML route, storing essentially a list in XML on disk, reading all of it in at once and then simply looking up deaserialized structures/objects when you need them. Having XML files permits others to examine and modify your data using any off the shelf XML editor. Java has plenty of XML/Java binding frameworks. With the JDK comes JAXB, which is actually solid in WSDP 1.2. If you go Cocoa or C/C++, you can easily find SAX and DOM parsers. And when you need to save your data, simply write it all out formatted as XML. Easy enough. Finally, if you have structured data you're saving, I'd suggest using XML schema.

XML can cause a problem if you have tons of data. In that case I'd suggest custom files with data structured in a way that can be quickly and easily read into memory and then indexed. Essentially storing hashes and trees on disk work, or in some partial form that can be easily reconstructed when your app starts up. And don't discount storing sorted lists and using binary searching: simple and fast. I'm currently doing similar stuff in Java for an app I have. I build up indexes using int arrays to my information, and then keep a raw form in memory that is much fewer bytes than on object version. I build up objects and return them, backed by an LRU cache to control object count. One of many methods.

If you have vasts amount of data you can't keep in memory all at once, try looking into using B-Trees.

i guess technically you could map your objects to any data source, db or whatever...but for instance, i would want an interface in this app where i could display something akin to a smart playlist, where a user wants to display all of their associated tasks within a project, or all of the tasks that involved programming (or some other field).

How you serailize your objects out to disk or db won't affect what you can do with your objects once you deserailize them in memory. So regardless of how you store them, once in memory you can do what you like.

i guess the best analogy would be to viewing by genre in itunes. apple stores the itunes database in a flat xml file...i'm guessing they just parse over it at some point for the data? how often? and what happens when you add a genre type which is really a global option, does that data get stores elsewhere? if not, how do they build the listing of genre types? they can't possibly parse the xml looking for unique values...that would take extremely too long.

I'm guessing iTunes probably reads it all into memory and simply writes it out when it needs to save changes. While I like XML, it can be a huge bloat and waste. However, just because the file is in XML, iTunes I'm sure stores it in memory in a much more compact form.

Hope some of this helps.

[ameat]

Originally posted by jobim:
Hope some of this helps.

definitely, it gave me a bit to brainstorm. i guess i'm a bit memory phobic when it comes to holding large amounts of data...but then again i guess it would be just text.

i still like the idea of using xml though. whether it be for end users to tweak by hand, or if i wanted to perhaps create a web based version (which actually makes the prospect of developing this in java a better idea because i can then reuse the base classes and simply change the display...though this was an excuse to learn obj c), xml allows for that data to be portable...

thanks for your help
amit

[socalmac]

Originally posted by ameat:
thanks, i'm assuming that there's a java interface to this as well?

Not sure why you would want a java interface on this database? It looks like a very strait forward database for use when embedding in C/C++ and objective-c... However, there are other embeddable databasess to use for java that would not need to go though a JNI type layer. I would look to those first.. Google will get you there.

good luck.

[ameat]

Originally posted by socalmac:
Not sure why you would want a java interface on this database? It looks like a very strait forward database for use when embedding in C/C++ and objective-c... However, there are other embeddable databasess to use for java that would not need to go though a JNI type layer. I would look to those first.. Google will get you there.

good luck.

...pardon the foolish question, i hadn't even closely read the page. being new to desktop development, i assumed it was something like an embedable mysql, with the ability to access it with any number of interfaces. i now realize that it is a c library...

[teknologika]

<rant>
This is one of my pet hates about developing on the mac. On windows with ADO, and two free (MDB and MSDE)database engines, you can easily add database support to any application.

On Windows ODBC drivers are supplied gratis by all the database manufacturers, yet on the mac you have to buy a third party driver even if you want to connect from MS Excel to MS SQL server.

Apple has some GREAT technology in this area, but it is all tied up in WebObjects and not available to the developer masses which seems crazy to me.

I for one would prefer for apple to charge $10 more for Mac OS X and have WebObjects and an engine like OpenBase bundled, so that any developer can use them in their apps and really make application development and adoption in the business space easy.

Connecting an application to a database should be the simplest, easiest thing to do, you shouldn't need to use a database specific api or a different api for each development language.
</rant>

Sorry but I had to get that off my chest.

[scotty]

Originally posted by ameat:
...pardon the foolish question, i hadn't even closely read the page. being new to desktop development, i assumed it was something like an embedable mysql, with the ability to access it with any number of interfaces. i now realize that it is a c library...

If you want a Java library, I guess this is what you want: HSQLDB, http://hsqldb.sourceforge.net/ - based on the old Hypersonic SQL engine. It is a small and embeddable database engine (SQL) written in Java.