Somebody please put me out of my misery
-
Normalization IS a good idea, at least in my case. Because all the business logic would have been far more complicated if the data were not normalized. Imagine having to update all customer orders of a particular customer, when a single attribute of that customer changes. (Oh you know this) :) But my frustration is, people not letting the professional handle the problem. This is exactly what has happened in my case. Because of this guy thinks that he knows better than the software guy, we have a crappy form in an application where everything else is pretty much elegantly structured. I feel like a web designer, who ends up adding a purple marquee to his newly created, metro style website, because customer wants it desperately.
krumia wrote:
I feel like a web designer, who ends up adding a purple marquee to his newly created, metro style website, because customer wants it desperately.
Hands up anyone who hasn't bee to that place. (It shouldn't take long to count zero hands.)
I wanna be a eunuchs developer! Pass me a bread knife!
-
A 'simple object model' should map pretty easily to a properly normalised database. (Class → table, property → column, object property → foreign key lookup column.) If you can design one, you can design the other.
Yup. The advantage being that you put the object model together based on pure common sense, rather than follow arcane processes where you're not supposed to think, just do.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Ok - I'm not picking a fight here, I'm genuinely interested - am I missing something?
Mark Wallace wrote:
An object model takes a tenth of the time to design (in many cases, the required time can be counted in minutes, rather than hours).
I disagree - it takes me around the same time to design an object model to designing the DB to store it in. As someone said below, roughly a class would map to a table, a property to a column etc. In the same way I wouldn't have (for example) the Sex of a person stored as a string as a property of a class, i wouldn't do so as a column in a table (assuming that a) the sex is a limited list of n possibilities, and b) that sex is pertinent to my application in some way more than being descriptive.
Mark Wallace wrote:
The old argument about "customer's name not being stored twice" has never washed.
washed, cleaned and brighter than white. If you store the customer's name against every order he makes, and you want to send a letter to each customer - how you going to do it?Who do you address it to? do you send a letter to each individual missspelling?
Mark Wallace wrote:
Many smaller databases ("smaller" relating to the number of fields, rather than records) would better be stored in a single table,
I genuinely don't understand unless you are talking REALY small - like an address book application - and even then, what about State and Country - do you want people to type these in each time rather than being able to select from a list?
Mark Wallace wrote:
it would be pretty obvious if there were duplication.
To whom? In any case what has this to do with normalisation? If each record in an order table stores teh customer's complete details, and I have had 10,000 orders, are you just saying you'll scan the table to look for duplicate surnames rather than having a customer table?
Mark Wallace wrote:
Unless your head is somewhat unscrewed, it's pretty nigh-on impossible to duplicate a field when setting up an object model
to paraphrase; it is hard to create a non-normalised object model? Is that what you're saying? surely it is no harder than creating a non normalised database? it's the same thing surely? its a model - one in some OO language and one in SQL or similar.
_Maxxx_ wrote:
store comma separated strings in a column?
I came across this in an old foxpro application apparently due to a limit of 255 columns. They stored record details there, and we had to analyze RBAR to get what the customer needed...one of the more difficult exports I have had to write! :(
"Go forth into the source" - Neal Morse
-
I thought normalization was a good idea... One of our customers need practically all the data in the database to be shown in one WinForm. He wants to show following: 1. Inventory information (number of items at hand, number reserved, and about 50 other columns) 2. Item characteristics (we can have different characteristics for different items. For example Thickness and Color for polythene, Thickness-Color-Texture for Glass) 3. Order information 4. Some other sh*t Somehow I have managed to put all this to a WinForm, as a grid. The features of the new form include: 1. About 400 columns per row. (Wish the user luck, may he find it very easy to find information) 2. The database view have 8 tables (Oracle) joined, two of them pivoted. 3. We have about 100 records (inventory items) for testing, and the execution time for the database view is nearly 1 second. I can't wait until this goes in the production environment, where thousands of inventory items are handled. Apparently normalization was a bad idea.
krumia wrote:
One of our customers need practically all the data in the database to be shown in one WinForm.
I would suspect that someone has confused the meaning of the words 'want' and 'need'. I would also suppose that an analysis of the actual business process would reveal that it was an uninformed 'want' as well.