Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations dencom on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

When to break from Programming Best Practices

Status
Not open for further replies.

Memento

MIS
Jun 19, 2005
46
US
Is there ever a situation where it is acceptable to store data like Goals1, Goals2, Goals3, Goals4, Goals5? I've always been taught NEVER to create fields that have numbering because you might run into a situation where you need a Goals 6,7,8,9, etc... As it is now, I create another table called Goals and link it back to whatever table needs to use it.

The reason I ask is because we are getting a new software package, and they use the above technique several times. I'm guessing they did it that way because it might make reporting easier?!?
 
> I've always been taught NEVER to create fields that have numbering because you might run into a situation where you need a Goals 6,7,8,9, etc...

Technical term for that is "repeating columns". People do that to make CRUDs (create/read/update/delete actions) easier. That works in a short run. Anything after that... [bomb].

And reporting... um. Trivial reports become nothing but vanilla SELECTs. Anything more complex than that... [bomb].

Nah, this is spreadsheet stuff :) At least for OLTP purposes, this causes more trouble than it's worth.

------
[small]select stuff(stuff(replicate('<P> <B> ', 14), 109, 0, '<.'), 112, 0, '/')[/small]
[banghead]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top