NYCPHP Meetup

[Kenneth Downs]

> Tim Gales tgales-at-tgaconnect.com |nyphp dev/internal group use| wrote:
>
>> It strikes me that normalization of data follows a strict path --first
>> normal, second normal, and so on.
>>
>>That is, there is not such a thing as  "more than one 'right way' " to
>> normalize data -- not even with Perl packages
>>
>>
>
> Show me a "fully normalized" database supporting a web app, done close
> to schedule and budget. I double dog dare ya.

How about ahead of schedule?  That's how ours go.  The trick is to know
well the disparate nature of both web and data, and have a tool that gives
each its due and creates the proper interface between them.  Using heavily
Object-Oriented techniques will not get you there, and may hold you back.

>
> I do NOT recommend de-normalizing. Dan's commments were on summary table
> built and managed by the dbms... and the coder now had to code to those
> instead of the db tables. That's great, IMHO, because it guarantees
> interity to the degree that the dbms can maintain it (presumably better
> than the developer can). I do believe there are multiple ways to
> normalize, because you have to select a base data unit around which you
> build your app (and normalize your database). Some hard-core database
> guys fallback on semantics here -- they assume there is no data except
> what is specified in the data model. Sure.. in that case, full norm is
> the only option. But I don't think it's a realistic (nor particularly
> helpful) perspective.

Not sure what you mean here.

I've found it easier to use a handful of plain-English terms. So when
talking to customers I don't talk about "models", it's more like "What do
you want to keep track of?"  Then its questions like, "will one price go
for all products in the category, or do separate items get separate
prices?"  These questions lead directly to table design and table design
drives the rest of the process.

<snip>

>
> In my view, you need to base that on experience, choosing data
> structures that permit the application to accomplish it's goals, while
> being normalized.

You choose data structures that accurately record what needs to be
recorded, the application is simply an interface to that data.

> You cannot have your cake and eat it, too. In other
> words, I prefer to keep the database theorists out of the kitchen.

Dare I say that's why you are not delivering on time or budget? (ducking)

It is true that you must determine who is "master" of the app, is it all
about the code, or all about the data?  If it is all about getting the
record-keeping down accurately, then you must insist on a proper database
design, then the application fits over the table structure like latex. 
Those who are more coder than db dude don't like this idea and want to
shape the database to the code -- bad idea.


>
> There is more than one way to normalize, because there are multiple ways
> to define the data set. That's my point. In addressing the developers'
> needs, the database design seems to come later. But of course we need a
> solid database design to start; it has to be done first... hence the
> recursive puzzle.But should we start with full normalized form? We would
> never get development started.

Let me ask about cost.  Is the recursive puzzle a problem because it is
expensive?  Does it yield the correct result?  Could it be that it would
not be a problem if it were cheaper?

>
> I love database guys... as much as I love graphic designers. But I won't
> let either one tell me how to code ;-)

I love coders, but I never let a coder take an architect's role.

>
> -=john andrews
> http://www.seo-fun.com
>
>
>
>
> _______________________________________________
> New York PHP Talk Mailing List
> AMP Technology
> Supporting Apache, MySQL and PHP
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.nyphp.org
>


-- 
Kenneth Downs
Secure Data Software
631-379-0010
ken at secdat.com
PO Box 708
East Setauket, NY 11733