Re: Help! I can't support normalization

I was in a situation somewhat similar to yours a couple months ago and actually posted a message indicating my frustration. The developers I work with were resistant to assigning identification numbers as primary keys (which resulted in some non-normailized databases) and did not want to use foreign key constraints. Once a week we have meetings and during one of the meetings I did a presentation that illustrated my argument. The presentation went well and overall most people agreed with my arguments. After the meeting most people were at least not resistant to my suggestions and some were planning on adopting them.

If you would like for me to email you a copy of my presentation I would be happy to do that.

As for your first/last name field situation, it may or may not be useful to combine last names and first names. If you always want both the last name and first name presented the exact same way then you may want to combine them in a single field. However, a good argument to separate them is if you don't always want both the first name and last name. You may also want the fields separated if you sometimes display them differently, example: last name, first name or first name last name. Another argument to separate them is if you want to sort the names with either first and last.

Although some developers are resistant to changing their ways, I think that most are open to new ideas if you can support them well.

phantomtoe_at_yahoo.com (Rowan) wrote in message news:<4bbf8d70.0211010748.727d38ef_at_posting.google.com>...
> Greetings all,
>
> I have read with great interest the discussions regarding
> normalization. I understand it. I can do it. Unfortunately, I
> cannot convince the people I work with how important it is. I am a
> newbie and don't know how to support my argument that our database
> must be normalized. When I began at this company three months ago
> soon after graduation I found that the sql server 2000 database was
> completely corrupt. Primary keys were not declared, (let alone
> foreign keys), fields appeared multiple times throughout tables with
> different names, etc. Pretty much every bad thing you could think of
> existed in this database. Reports are very difficult to create. I
> have since redesigned and built a new database and am now in the
> process of reworking the vb application to fit the new database,
> including edi remapping. My problem is that being a newbie, I
> sometimes need to ask for vb help from the other programmer. An
> example is yesterday I was struggling with an aspect of concatenating
> an employee Last Name and a First Name. I displayed a list of
> concatenated names in a datacombo but wanted to store the Employeeid
> in a customer table. When I asked the programmer for help, he said
> just concatenate the names in the field in the employee table and call
> it "name". I said no. He asked why. I didn't have an answer. Could
> anyone give me an answer? I would like a well supported argument to
> put this silliness to rest. I appreciate anyone's thoughts and ideas.
> Please enlighten me!
Received on Fri Nov 01 2002 - 22:02:35 CET