Re: Database Application?
Re: Database Application?
- Subject: Re: Database Application?
- From: Andrew Satori <email@hidden>
- Date: Fri, 15 Dec 2006 16:38:06 -0500
I guess I'll weigh in here.
If your application is single-user, and you don't expect to have
datasets with hundreds of thousands of elements, the CoreData is
absolutely the way to go, I know that it has some issues being
SqlLite, but if you want to think about it in terms of Delphi, it's
very much akin to Delphi's BDE using Paradox tables for the data
store, with the exact same caveats to scaling it to multi-users (eg,
not particularly recommended or easy to manage).
Once you make the decision to go beyond those boundaries though, you
are into a different realm.
At that point, you have to make some determinations as to what you
want in your RDBMS. Does it have to run on Mac OS X, will it always
be on a Mac, do you want a commercial product or open source? I
freely admit that I have a strong bias here. Having spent ~10 years
with Delphi starting with the 1.0 16 bit betas in the pre Windows 95
days, connecting primarily to MSSQL databases, I understand what I
think you want, in a simple, platform native infrastructure to get
your data. The short version is, that Apple doesn't offer one
(today, what Leopard holds, only Apple knows).
I have personally been down this path a few times. The first visit
led nowhere. The second led to the PostgreSQLforMac project (http://
www.postgresqlformac.com). Part of that project is a simple
pgCocoaDB.framework that provides a basic Cocoa library that
functions much like the model you are used to. Unfortunately for me,
and that project, I get VERY little time to work on that project
right now because my work has forced me down this path from a
slightly different direction, in that I had to also support MSSQL and
Oracle as well. That led me down the path from a slightly different
direction, one that is familiar to most Delphi and Windows devs.
ODBC.
The Mac ships with and supports ODBC via the bundled version of
iODBC, maintained by OpenLinkSW. The downside is that the ODBC API
is a C API, not very 'Cocoa'. That's where my third adventure down
this path led me. ODBCKit is a Cocoa framework that exposes an
interface that is intended to be easily understood by both the
Windows converts and the experienced Cocoa devs. While it is not
complete, it is usable, so long as you aren't dealing with BLOB's,
which I am working on support for now.
What you lose in this, is the very nice tools for creating your
entities and relationships like CoreData (maybe if I ODBCKit was a
paid F/T deal I could reverse engineer that and build a CoreODBC
framework that would work with it). That may not be a huge loss,
since, in many cases, working with ODBC also means you are working
with a pre-existing data model. The other issue is Bindings. It's
possible to using bindings with an ODBC recordset for read, but
you'll have to do your own update/insert logic for saving changes,
since there is a method to return a row from a recordset as an
NSMutableDictionary. It is on the list to implement a saveDictionary:
(NSDictionary *)dict toTable:(NSString *)table forKeys:(NSArray *)
keyValues; method that would take a new or modified dictionary and
build the insert/update query from the dictionary to then save
record, again, time permitting.
The project is OpenSource at: https://sourceforge.net/projects/
odbckit and my blog about it is at http://web.mac.com/dru_satori/iWeb/
Words of a Geek/ODBC/ODBC.html
Oh and about my bias, you cannot go wrong with PostgreSQL as a
database engine. It's free, it's fast, it's powerful and it's
portable. While it may not be Oracle in terms of scalability, I
consider it to be among the best RDMS products on the market
regardless of price.
Andy
On Dec 15, 2006, at 1:35 PM, Ferhat Ayaz wrote:
ok, thank you. But CodeData sounds more Cocoa and MacOSX style,
doesn't it? And Valentina is commercial as I could see.
On Dec 15, 2006, at 9:50 AM, Ruslan Zasukhin wrote:
On 12/06/14 11:57 AM, "Scott Stevenson" <email@hidden>
wrote:
I know from Borland Delphi a comfortable usage of Borland Database
Engine. You put just a table component and a dataset, then you can
"bind" your textedit and other controls to the table rows.
Is there a good cocoa technique to do this?
Core Data can certainly do this, but it's a much more general
solution. You'll have to learn a lot more:
http://cocoadevcentral.com/articles/000085.php
I think the FileMaker application is really more what you want, but
I'm not sure it's designed to handle 300,000 items.
If somebody think about having database in hundreds of thousands
of records,
or million or more, then I will express my own point of view and
not only my
see e.g. http://www.paradigmasoft.com/en/testimonials
That CoreData based on SqlLite and SqlLite itself is not good.
I know fans of coreData will prove reverse, but we have a lots of
developers
who say: Valentina Database is up to 100+ times faster.
Just few days ago was feedback from a developer:
SqlLite on db in few GB did his queries in up to 2 minutes.
Valentina the same in < 1 sec
Count the difference self...
Ferhat,
If you have come from Delphi world, then you also find Valentina
comfortable
for use I think. We have native Delphi developers that use
"Valentina COM"
and which think Valentina beat easy as BDE, so e.g. Nexus DB.
--
Best regards,
Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc
Valentina - Joining Worlds of Information
http://www.paradigmasoft.com
[I feel the need: the need for speed]
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden