Re: mysql question
Re: mysql question
- Subject: Re: mysql question
- From: Serge Cohen <email@hidden>
- Date: Fri, 19 Sep 2003 22:07:51 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dan;
I would quiet agree with your points, particularly on the overhead of
using some kind client/server architecture when you want to deal with
'small' files (in which case... for sure you want to avoid
client/server), or deal with some data which doesn't need to be
distributed (it is never used by more than one user -and always the
same one-).
In the mean time, some of the problems you are raising are (partly)
resolved:
About the single application use of a database: you can use libmysqld,
which will very easily start a server thread for you, so you don't need
to start a server process (or to keep a server process running).
About exporting/importing the DB... the most interest of using a proper
SQL server is to avoid this. All the info stays on the server machine,
you just make a connection (which BTW can now be using SSL if you are
worried by security issues).
As well... if you are looking for couple of client using the same DB
server, it's not that much work to configure MySQL security (and indeed
I would think it is the same for other DB, like PostgreSQL).
At last, concerning the difficulty of using the C API of MySQL... there
is already a Cocoa based framework which wraps the C API, you can find
it here :
http://mysql-cocoa.sourceforge.net/ (of which I'm the maintainer). You
can make it an embedded framework so that it is used while being
included in your application bundle (so that the client part of MySQL
is directly installed together with your application, avoiding that the
user as to do more than just copy the application).
So, I would summarise my point of view as:
If you're looking for a client/server architecture (and have no problem
with GPL), than, using MySQL as the server is a good solution. (still
if your looking for a small application, you might use the libmysqld -
-thread server-... but then you might be interested in looking into
SQLLite...).
Serge.
PS: As the author/maintainer of MySQL wrapper for Cocoa I'm obviously
biased...
Le vendredi, 19 sep 2003, ` 15:49 Europe/Amsterdam, Dan Posluns a icrit
:
On Friday, September 19, 2003, at 12:11 AM,
email@hidden wrote:
I'm wondering if anyone has any reasons for a Cocoa program not to
make
use of MySQL (or PostgreSQL). I have a project which is intended to
use
thousands of large text chunks per project (and potentially to open
many projects at the same time). I was thinking of storing the text,
along with some other info, in MySQL, since only a small number of
items will ever be used / in memory at any one time. I'm assuming this
would help with speed, but have no benchmarks to fall back on.
I think it depends largely on your target audience. For in-house
development it's probably a quick and effective solution to many
problems, but if you ever intend to distribute the software there are
some considerations you need to take into account:
- Unless your software falls under GPL, there is a hefty licensing fee
for using MySQL.
- MySQL is designed around being an enterprise-level solution (ie.
processing multiple queries from multiple connections from multiple
computers, etc.). It is probably not the most efficient way to store
data for a single application - kind of like using a sledgehammer to
crack open a walnut. Unless your program starts and stops the MySQL
daemon every time it launches/quits, it will be consuming unnecessary
system resources as well.
- Your application's data will be less portable. Instead of just
dragging your Cocoa document onto another disk, etc. you will have to
export the database from MySQL and re-import it into the new location.
- Installing and configuring privileges in MySQL is a pretty large
additional chore for your distribution system. End users may not want
to be running a database server on their machine, either.
If your main concern is efficiency in handling large files, consider
using NSFileHandle instead of NSFileWrapper and just use the
offsetInFile and readDataOfLength methods to make sure you are only
accessing the parts of the file that you need. Store an index and
table structures (if needed) at the beginning of your file and load
them in when you open the document so you know where to look. (It may
seem like a bit more work, but if you can use the MySQL C API then you
can do this.)
If you're really into well-structured programming, you can always
design an interface with your general data access routines, then
create a MySQL class to implement it as well as another class for
traditional file access. Then your program can just choose between
whichever class it wants to use.
Dan.
--
Dan Posluns, B. Eng. & Scty. (Software Engineering and Society)
email@hidden - ICQ: 35758902
http://www.danposluns.com
"Only when the last tree has been cut down, only when the last river
has been poisoned, only when the last fish has been caught - only then
will you realize that money cannot be eaten."
- Cree prophecy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
- ----------------------------------------------------
Serge Cohen
GPG Key ID: 9CBB58FB
- ----------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE/a2IL5EPeG5y7WPsRAiXZAJwIKmuJSS3DO+48eroC8hz/baXBtQCg99Qz
zl0sGPLeoeZo+1hb+iDi8WA=
=XT9j
-----END PGP SIGNATURE-----
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.