Re: Updating data in table depending on data in same table

On Feb 9, 2:10 pm, "Ed Prochak" <edproc..._at_gmail.com> wrote:
> On Feb 9, 6:21 am, "The J Man" <jonathan.kee..._at_gmail.com> wrote:
>
>
> it is flawed because the design allows these duplicates. A better
> design would have dealt with this diferently. Not knowing all your
> business requirements I won't suggest a solution here (and I don't
> have one off the top of my head). Another easy to point out flaw is
> the DEPARTMENT attribute in table A. That really should be another
> table, or (since dups are allowed in this table) multiple rows.
>
> You did not come here for a design review, but a big part of what I
> posted was just that. I apologize if I offended you.
>

No, no offense taken. I realize that any design that allows dupes in a database sucks but the end user (read stupid manager) won out in this case.

>
> Okay, sounds like a good plan. Any assignment where you expand you
> knowledge is good.
>

Yes it seems to have worked on the test tables i have done out so its just a matter of running it now on the production database, all the while hovering over the rollback button!

>
> Another mea culpa. I assumed you were like some of the posters who can
> barely write a SELECT query but get assigned projects like this. I
> still think some table redesign is in order, but that doesn't solve
> your immediate problem.
>

Nah, i realize it probably came off like that because i fluffed around the facts of what it was actually trying to do. A re design could be in order as well though.

>
> I hope I did. Now it sounds more like you are a good fit there. so
> keep the job, and thank you for not taking offense at my less than
> complimentary remarks.
> Ed

No problem, thanks again, I'd rather get any replies than none at all. J. Received on Fri Feb 09 2007 - 09:03:14 CST