Re: Lengthy questions from a newbie
Re: Lengthy questions from a newbie
- Subject: Re: Lengthy questions from a newbie
- From: Keary Suska <email@hidden>
- Date: Tue, 20 Jun 2006 10:44:21 -0600
on 6/19/06 4:41 PM, email@hidden purportedly said:
> 1) Painless database connection. We'd love to use MySQL and it's
> speed/price/scalability, but there seems to be no widely available framework
> for connecting to MySQL DBs from cocoa, except a product from Serge Cohen,
> which is undocumented/unexampled : http://mysql-cocoa.sourceforge.net/.
> WebObjects is too flimsy (as far as we can determine with mostly web-based
> apps). And our code, the way it currently stands using the MySQL C-API, is
> littered with more cString commands then I can stand. It requires 3/4 full
> lines of code to take the NSString from a text box and dump it into a C-style
> SQL statement. Our applications require a couple hundred SQL skeletons; its a
> pain. There HAS to be an easier way. Am I missing something basic?
I wouldn't recommend MySQL. MySQL does *not* scale well and has poor data
integrity enforcement. Also, the speed benefits of MySQL are significantly
reduced if you require transaction support. For a mature, robust, and
enterprise-quality RDBMS that is totally and *always* free (which MySQL
isn't), I recommend PostgreSQL.
There is no escaping C string conversion issues, since AFAIK there are no
Cocoa-native API's. If you use a "wrapper" API (such as MySQL-Cocoa), the
API likely hides this from you, but you may have to watch out for
performance issues. NSStrings are huge and slow. In some test I have run
with large data sets (10k or so), where about 2.5mb of raw data becomes
about 30mb of memory as NSArrays of NSStrings. With large data sets, you may
be better off keeping C strings until you need them as NSStrings.
Fortunately, PostgreSQL supports prepared statements, which not only improve
performance but enhance query re-use and resist SQL injection.
The only significant drawback I find to PostgreSQL is that there is no way
to determine the progress of a running query.
> 2) Remote views. Another major feature that has us stumped: building a
> separate mini-application that allows users on a remote system to fully
> interact (in a controlled manner) with the primary interface.
As suggested, you could develop a client-server system using distributed
objects, which could be quite a task, or you could have a mini-app that
interacts with the DB back-end. If you need a separate interface to be
updated in a "live" manner--i.e. updated automatically every time a change
is made--the latter option may pose some challenges. You could have the main
interface "poll" for changes, for instance. If you were using PostgreSQL,
you could use its asynchronous notification system to notify the "main"
interface of changes and so to refresh its list.
Hope this helps,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden