The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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.
Hi Krumia, Yes in many situations the customer is "King," and they want what they want.
But, unfortunately, it seems that, historically, Kings never end-up being blamed when what they insisted be done is a failure. Somebody else must "take the fall."
You did your duty by raising questions, proposing alternatives; I just hope you have a traceable e-mail-and-paper-trail (yes, make printed copies, keep them off-site, save the e-mails to cd or whatever, and keep them off-site) of your suggestions and/or reservations about the customer's demands, so if anyone tries to blame you for a non-performant solution:
You got your ass covered. I have known folks whose jobs included a sign-on bonus, paid after one year on the job, or when they were laid-off, unless: they were fired "for cause."
And, yes, they were fired "for cause," even though they were not at fault for a dramatic product release failure related to a buggy beta being too-soon decided by management it was ready to go to their customers; they got a lawyer, and threatened to sue, which caused the company firing them to quickly re-frame the firing as a lay-off, and to pony up the sign-on bonuses immediately, because:
If the suit had actually been filed, and come to the attention of the Board of Directors (and, legally the CEO, or whatever person was at the top, would have had to inform the Directors immediately of any suit ... at least under U.S. law) some high-level heads would have certainly rolled. And, the company was terrified of "bad publicity" that might affect stock price.
Of course, if you working as a contract programmer for someone directly, or working for a privately owned firm, such a strategy may be a waste of time, depending on what the labor laws are where you are (they can vary from state to state in the U.S.). And, lawyers ain't cheap to use.
Confused by having a brain ? This may help: [^] !
You might be surprised at how often normalization is a bad idea.
With today's storage, processing, and comms speeds, normalization more often than not turns out to be just a waste of time and effort (which is far more expensive than storage, processing, and comms).
It's one of those lovely academic ideas that makes perfect sense until you find that months of work have been spent on implementing something that doesn't deliver a noticeable performance improvement, and will only cost more and more, because it makes everything three times as complicated to do.
Simple object models usually turn out to be the best.
I wanna be a eunuchs developer! Pass me a bread knife!
normalization more often than not turns out to be just a waste of time and effort
sorry, but I can't let that go.
Normalisation isn't just about performance - it is about such things as making sure you don't have a customer's name held differently on two tables, your total cost of a sale is always the same as the sum of the cost of the items, your customer's age is correct - even when you entered it last year - etc. etc.
Normalizing everything to 3rd normal form and beyond surely can be counter-effective but that's the difference between good database design and academic database design.
If your normalisation is more often than not a waste of time and effort, then you perhaps find it difficult - personally I have no difficulty with designing a normalised database (indeed I find it natural to NOT store the same information multiple times) so, for me, to design a normalised database is not difficult in the least; what is difficult is designing a system that uses a database that is not completely normalised and ensuring it is consistent and well understood by both the current, and future, developers.