Okay, at work I'm having a big disagreement with the project management team who has no database experience at all. Here is the issue.
We have 10 product lines, in each product line there are certain number of attribute names, such as height, weight, color, price and so on. We have a total of 670 attribute names for all 10 product lines. The project management team is wanting to create a master file in excel that contains all 670 attribute names, regardless if the attribute name pertains to the product line or not. So let's say 'Widget A' has only 70 attribute names, they want to still add the other 600 attribute names and enter a dash for the value (You can only import if the value has a character in the field). We have to import each product line one-by-one since that is what the software requires.
To me, this is not the proper way to build a database since we are creating a database that will have hundreds of thousands of null characters. They say this is normalizing the databse, and I told them it is he complete opposite of normalizing a database.
I agree with Rudy's suggestion about using multiple subtype tables. But if it's just a temporary piece of work to do the migration then do whatever works for you and gets the job done most effectively.
8) Not really. My problem is that they are not going to do the work, I am. This is going to take hours, upon hours and accomplish the same thing.
...for which you are getting paid, I assume.
The question you should be focusing on, and which should be driving your design, is how you are going to manage the addition of new product lines and attributes once the database is in production.
If it's not practically useful, then it's practically useless.
I would rather not comment on the reponders so far, but this needs to be stated in order to avoid confusion. There is a lot of misinformation, weird and changing understandings of what Normalisation is. There have been textbooks written about if for almost 30 years, so I will not be "explaining" what it is or getting into "debates". Unfortunately, some responders at this site have not read or understood or practised any of them, but they post responses anyway, and argue with established experts.
You have asked a simple, straight-forward question, to an expert (you did ask for that), the answer is simple and straight-forward:
1 You are right.
It is not just your point about nulls; it is the total lack of Normalisation; and the massive maintenance burden that will follow.
2 The Project Manager is grossly wrong.
Typically these people want to do things in the only way they know. It is the bane of developers/DBAs (classy managers understand that they need to manage people whose work they do not understand; idiots want to tell their more technically qualified staff how to do their job).
How you handle that, is a separate issue. Get everything in writing, including your warnings about the method and the outcome. Print this post. Email it to the auditors now, do not wait for the poverbial to hit the fan. There is a certain undeniable insanity is telling you to implement some unqualified persons design. As long as the instructions are in writing, and attributed to the boss, along with your serious concerns, then there is no danger in implementing the insanity, just step back before it crashes.
Last edited by Derek Asirvadem; 08-27-09 at 12:43.
I welcomed you back to the forum. You said you hoped everyone here had grown up and barely paused to write several novels before taking two opportunities to open hostilities with snipes at people that have been helping A LOT of professionals in your absence.
Please be respectful in your conduct. I would expect that any action taken this time round would be much swifter.
GETTING BACK TO THE BUSINESS AT HAND . . .
Here is a suggestion which might help organise the required data without a lot of work.
Set up an MS Access database with a master file and with a subfile for each of your attributes. The subfile only holds the keys of the master records which have that attribute (though there is a bonus in that you could add fields to hold attribute-specific data if you wanted to). Your form in Access would contain fields for the master file, plus a listbox allowing multiple entries, where the attributes are listed. You select them simply by clicking on them and the subfiles are updated automatically.
Output from the system would be driven by queries which export the data to the Excel files desired by management. The nice thing is that the queries can filter out most of the null data which will make the Excel tables more readable.
More sophisticated data extraction can be handled by VBA functions called up by the Queries.
I hope this helps.