Internetworkers: http://www.ibiblio.org/internetworkers/

["Colleen McCarthy" <cmccarthy1 AT nc.rr.com>]

I agree with Shea and Michael.  Reading these emails has been very
informative!  Colleen

Colleen McCarthy, MT(ASCP), BSEE, MBA, PMP
LIS Administrator
Laboratory Information Services
UNC Hospitals/McLendon Clinical Labs
1106 East Wing
Chapel Hill, NC 27514
email: camccart AT unch.unc.edu
phone: 919-966-2059 beeper 216-1995
fax: 919-966-6407
home phone 919-460-0641




-----Original Message-----
From: internetworkers-bounces AT lists.ibiblio.org
[mailto:internetworkers-bounces AT lists.ibiblio.org]On Behalf Of Michael
D. Thomas
Sent: Wednesday, October 15, 2003 4:45 PM
To: 'Internetworkers: http://www.ibiblio.org/internetworkers/'
Subject: RE: [internetworkers] mySQL learning curve


> The real leap forward for a lot of folks is learning how to build the
db
> and then build PHP/Perl objects that you can populate with queries or
> use as basis for inserts/updates. A lot of the PHP code I've seen (and
> some of the early stuff I wrote, for that matter) would benefit from a
> sane approach to db design /first/ and then a sane approach to object
> design second. But that often takes either having to go back and
maintain
> the awful code you wrote as a novice, or maintaining/extending someone
> else's awful code before they realize the power of using objects, or
the
> pain that can be caused by poor table/query design.

A classic cost of change curve problem... Cost of change increases as
you move forward in your project. Waterfall, RUP and most other people
say it is exponential. Extreme Programming ("don't design, just start
coding") people say it is logarithmic.

There are those that will argue that we shouldn't have both an object
model and a relational model. We can get by with one or the other. In an
all object world, you just store and retrieve objects. You use an object
db or an object-relational mapping to a relational db, such as EJBQL for
Enterprise Java Beans (EJBs) using Container Managed Persistence (CMP).
In an all-relational world, you bind your interface directly to SQL and
a SQL result set of some sort. XSQL and .NET DataSets are example of
this.

In reality, we work with both -- though the all-object argument is
compelling. Now there's a discussion: do we need both? I recently
arrived at the answer "yes," but I'm not very firm on it...

I've found over time that a key tenet of overall systems design is
normalization, or what the Pragmatic Programmers call the Don't Repeat
Yourself (DRY) principle. Just as your database should be as normalized
as possible, so should your code.

Here are some quotes I keep in mind to drive this point home:

"Things should be made as simple as possible, but not any simpler." --
Albert Einstein

'Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away." -- Antoine de Saint-Exupery

"Less code, less bugs." -- Anonymous

Last thought: when thinking of objects vs. relational, there is another
dynamic. You are also mixing types of languages -- imperative and
declarative. Declarative languages are extremely strong at solving
problems in mature domains and manifest a lot of what you want your
imperative code to be. I did a talk at the TriXML conference about
creating your own declarative languages:

http://www.ibiblio.org/mdthomas/downloads/Declarative_Languages_With_XML
.ppt

I'm working up a paper on the different models and am very interested in
continuing these conversations.

Cheers!


---
Come and play at the InterNetWorkers Web site!
http://www.ibiblio.org/internetworkers/
You are currently subscribed to InterNetWorkers mailing list
To unsubscribe visit
http://lists.ibiblio.org/mailman/listinfo/internetworkers