Yup -- I would agree.
I believe the process of changing the structure of a table is a fairly
painful db process and prone to issues.
The status field is something likely to change - hence putting it
separate made sense.
Anybody from BMC care to comment why it would be done that way?
-John
On Mar 25, 2010, at 1:20 PM, Misi Mladoniczky wrote:
Hi,
I guess it is easier to restructure one small (thin) table, than the
whole
T-table, when you add/remove new Status-values.
That may be a reason on some DB-platforms at least.
I would think that Status-values would be more fluctuating than actual
fields.
It was a long time ago when this design was implemented...
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
logs.
Find these products, and many free tools and utilities, at http://
rrr.se.
What would be the purpose of having a seperate table to hold the
status values and not just have it in the orig table?
-John
Sent from my iPhone
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
--
This message was scanned by ESVA and is believed to be clean.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
--
John Sundberg
Kinetic Data, Inc.
"Building a Better Service Experience"
Recipient of the WWRUG09 Innovator of the Year Award
[email protected]
651.556.0930 I www.kineticdata.com
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
