Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!uunet!pmafire!mica.inel.gov!gem-hy!cdm From: cdm@gem-hy.Berkeley.EDU (Dale Cook) Newsgroups: comp.databases Subject: Re: Balancing Normalization with Performance Message-ID: <1990Nov27.165657.16019@inel.gov> Date: 27 Nov 90 16:56:57 GMT References: <1092@cortex.med.jhu.edu> <1990Nov20.190315.13505@informix.com> <1990Nov21.185907.10061@inel.gov> <1990Nov27.030450.6251@informix.com> Sender: news@inel.gov Reply-To: cdm@gem-hy.Berkeley.EDU (Dale Cook) Distribution: usa Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho Lines: 108 In article <1990Nov27.030450.6251@informix.com>, randall@informix.com (Randall Rhea) writes: |> In article <1990Nov21.185907.10061@inel.gov> cdm@gem-hy.Berkeley.EDU (Dale Cook) writes: |> >I think you are confusing design with implementation. Database _designs_, |> >IMHO, should always be normalized. |> |> What is "design" and what is "implementation"? Where does one phase begin |> and the other leave off? I've never received a consistent answer to that |> question from the various analysis methods I have come across. Perhaps |> there is a reason for this; often, there is no clear dividing line between |> them. I wondered when someone would catch this. The point I was trying to get across is that you need to seperate logical design considerations (e.g., normalization) from implementation considerations (e.g., denormalization). Fully normalize first, THEN _consider_ denormalization. |> |> >Remember that the goal of the |> >design is to understand your data and represent the data structure *as it |> >logically exists* so that others can understand it as well |> |> Absolutely correct! What I mean by "over-normalization" is a database design |> that does NOT represent the logical structure of the data: normalization |> that makes the data structure *more* difficult to understand. |> I still say a normalized design DOES represent the logical structure of the data. If it makes the structure more difficult to understand, it is because it is counter-intuitive to the "way it's always been done". Programmers have historically taken a process view; it is process considerations which generally force denormalization. |> >|> 1. Any programs that need to look at the string would have to perform |> >|> a sub-query. In some report writer languages, this can be quite difficult. |> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |> >So what? That's why you get the big bucks, isn't it? |> |> So what? I'll tell you "so what" .... You won't get the job done, that's |> "so what". In the real world, we have to complete projects on time and |> under budget. I have spent countless hours tweaking report writers to |> look at the zillions of tables that held the data I needed. You may think |> that "programmer inconvenience" is trivial, but programmer labor expenses |> are often far and away the most expensive piece of a project's budget. |> To get projects done on time and under budget, you need proper estimation. This means taking your environment into consideration. If you have schedules imposed without your input, well, that's a management problem. I absolutely agree that labor is the largest cost element in a project. But don't forget, the largest cost element in the life cycle of a project is maintenance. In the narrow short term view, your concerns are valid. In the long term, they are often proven trivial. (BTW, my "so what" was somewhat tongue-in-cheek as well, but I forgot the smiley :-( ). |> |> In the ideal world, where some database book authors live, we have perfect |> computers, unlimited disk space, plenty of good programmers, unlimited time, |> unlimited funds, and best of all ... a perfect RDBMS tool for the |> development of the system. In the real world, we never have any of these |> things. I know that it's unfortunate when one must change the database |> design (or "implementation") to make up for a bad programming tool. (or |> bad programmers!) However, this is sometimes a painful reality. Hey, you |> gotta get the $#@&# program written using the #&@!* lousy report writer. |> Sometimes, this means the database design must be simplified. If it isn't, |> you don't get the job done. I know, you can always get another report |> writer- provided you have the funds to do so. If not, you're stuck. |> |> My point is that your programming staff and your programming tools must |> be taken into consideration when deciding how the database is to be |> designed/implemented. It's not as trivial as Dale thinks. |> Absolutely. I think we are disagreeing on what constitutes programmer convenience, and the relative importance of same. I don't define convenience to be language shortcommings. This is a serious deficiency and must be considered. I do, however, define convenience to include such nonsense as "Just put the precipitation description in the flight table. You only have one at a time, right? That way, I don't have to access another table...". Don't laugh- it happens. I do not really mean to trivialize legitimate programmer concerns. I've been on both sides of the fence. I have equivalent problems with DBA's who "won't bastardize their pristine databases" under any circumstances. Neither of these views advance the company good. |> Overall, though, Dale makes a lot of valid points. Database design/ |> implementation is not simple. The postings on this net make this |> painfully clear. |> All of Randall's points are valid. The painful part is assigning relative importance to ALL factors, over the life cycle of the project. Programmers, given reasonable tools to work with, are the best equipped to deal with complex queries. Shouldn't their objections to the processing complexities imposed by normalization be given less weight than, say, the concern over the long term sharability of the data? ---Dale Cook cdm@inel.gov ========== long legal disclaimer follows, press n to skip =========== ^L Neither the United States Government or the Idaho National Engineering Laboratory or any of their employees, makes any warranty, whatsoever, implied, or assumes any legal liability or responsibility regarding any information, disclosed, or represents that its use would not infringe privately owned rights. No specific reference constitutes or implies endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions expressed herein do not necessarily reflect those of the United States Government or the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.