Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- Subject: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- From: Deirdre Saoirse Moen <email@hidden>
- Date: Wed, 13 Jun 2001 09:53:01 -0700
At 8:33 AM -0700 6/13/01, email@hidden wrote:
>>We have found that the return on investment for writing a pile of custom
SQL
isn't generally high enough to justify the effort.
Frankly, I've done a lot of SQL development and I haven't run across
even a complex sql statement (not even the "torture the grad student"
>ones my prof throws at me) that take very long to write.
I have to agree with Deirdre on the point here - I find it's almost ALWAYS
better to write SQL by hand than to use an automated tool, but part of that
is the nature of what I do. The applications I work on deal with millions
of rows of data, so a minor inefficiency can cause real headaches (like
people not getting paid).
At the time when I first learned SQL, I was also working on
millions-of-row tables and joins that could seriously affect
performance.
More recently, I've tended to work on smaller systems that were
designed to scale to larger ones (most recently, on the back end
architecture for the TiVo service).
I have to say that I _HAVE_ seen some complex SQL statments that took quite
a while to write but, again, that's in the nature of the work I do. For
most purposes, writing SQL is very straightforward and not hard. SQL is
pretty simple when you get down to it, and an experienced developer should
be able to pick up the most often-used stuff pretty quickly.
The most complex SQL statement I've ever written was 19 pages long,
joining 23 tables with several levels of nested subqueries. It also
joined the same table to itself five times to generate a report (one
column for each possible field value rather than one column for all
field values). I'm frankly amazed the parser didn't harf (Oracle 6 at
the time).
Let's just say I'd be very surprised if EOF could do it.
>This might surprise you, but I keep all my sql statements IN the
database. Therefore they're maintainable without having to modify and
recompile an app.
This shouldn't surprise anybody. Hardcoding SQL is okay if you're sure it
won't need to change and can't be reused, but outside of a classroom
environment, how often is that giong to be true. This practice is very much
like storing text in resources (a la OS 9) or in localizable property files
(a la OS X). Storing SQL text in a database is commonly (but not
exclusively) used in my industry.
I've also stored them in text files and parsed the file for them.
I've even stored them in the resource fork in the old days when we
had one. :)
>Depends a great deal on the project, wouldn't you admit?
Certainly does. I've worked on projects for which the original statement is
true, but I've worked on many, many more where that statement is laughably
untrue. It's actually a little insulting that someone would suggest that
those of us who want EOF/Cocoa don't know what our own needs are.
Agreed.
Even though I may end up looking like a bad guy again (seems to be
something I'm good at), I have to make a statement that one or two people
are bound to take offense to: Judging the needs of all Cocoa developers
based on your own experience or the past needs of Macintosh developers is
small minded.
I can't agree with you more. Of course, even my own needs and niche
change as a developer. For example, I'll be doing little Mac
development over the next 12-18 months.
I'm not suggesting that Apple focus new development
efforts toward the enterprise, just that it not remove existing items like
EOF; maintaining an existing product or codeline is considerably less
expensive and less work than rewriting if the original design is sound and
the implementation was done well. So, if OS X is a success and Apple begins
to penetrate the enterprise and mid-market space, they will have to start
over, or rely on third parties to bring this functionality back.
Exactly. So why eviscerate something that worked?
Frankly, if they would just give the basic functionality (give us
palettes), I'm more than happy to maintain those adapters I need. Database
vendors usually don't make HUGE changes from release - they sometimes add
some features, change syntax to more closely match standards (primarily
things like outer joins), etc.
There were big changes from Oracle 6 to 7 and 7 to 8. 7 to 8 was
easier to maintain and the interstatement view support (for
statements like below) is improved. I'm less familiar with the
histories of other large SQL databases as I was exposed to them much
later.
But I agree -- sometimes I want my OWN adapter. But I'm the twisted,
weird sort of gal that writes SQL parsers for fun.
--
_Deirdre Stash-o-Matic:
http://weirdre.com http://deirdre.net
"Cannot run out of time.... Is infinite time. You... are finite....
Zathrus... is finite. This... is wrong tool!" -- Zathrus