NYCPHP Meetup

[inforequest]

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.

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.

For a real estate application, is the base unit of location state, city, 
market area, zip code, GIS coordinates, zone, or what? Practically GIS 
coordinates represent the fnest granularity available and are actually 
required for some mapping applications. But are placename databases 
available by GIS coordinates? No, and they wouldn't be to useful 
anyway.  Somebody will have to pick a basis and it will be based on 
real-world application requirements. Yes, they are thusly translated 
into RESTRICTIONS and theoretically will hinder scalability.When and if 
additional data elements are needed (perhaps increased granularity for 
location parameters in the zip code example) the system will be revealed 
to be not normal and will need to be fixed.  In the context of this 
discussion, data types were being examined as they relate to 
normalization in the database design.

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 cannot have your cake and eat it, too. In other 
words, I prefer to keep the database theorists out of the kitchen.

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.

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

-=john andrews
http://www.seo-fun.com