Tom Austin wrote:
> On 3/9/2011 3:14 PM, Darren New wrote:
>> Tom Austin wrote:
>>> The problem is that we have to get jobs out for the client now and
>>> might not physically have the time to do it right.
>>
>> I grok. Why can't you use the old system, tho.
>>
> 
> A desire to just get rid of it and not try to morph it.
> It is one of those things - until you grasp how broken it was it doesn't 
> seem logical.

No, I meant your business is going to be making money running the old system 
while you're implementing the new system. Why is there a hurry beyond "we're 
spending money on peoples time to build the new system"?  If you turned the 
old system off before the new system was ready, I can see the hurry.

Doing it right shouldn't take a whole lot longer than doing it wrong.

> Like - does this belong with make ready or the current state of the 
> pole....

Right. You do have to watch out for that sort of thing, yes. But again, fall 
back to the concept that each row (in a "primary" table) represents a real 
entity.  If it's something artificial that is related to but not *really* a 
part of the thing the row represents, it should go in a separate table keyed 
to the main table.

Like, if you have a bunch of poles, and you want to know where to put a date 
at which the utility thinks it'll finish installing the cabling, that's not 
part of the utility *or* part of the pole.  So you can make a new table 
"ExpectedInstall" that has nothing but the pole and the date. Or whatever 
the key is you wind up hooking it to. Even if you have only one row in that 
table for each pole, that keeps the database clean, as well as making it 
obvious everywhere you actually use that data later (in that everywhere you 
actually use it, you'll be joining against the table).

>> Ah, welcome to the club. ;-) That's why I like being boss.
>>
> 
> can be difficult if you someone in the group has a strong personality.

As long as they're not stubborn in the face of reason. :-)

> Thanks for the tips - for the image files I don't know if it will go to 
> blobs or stay files simply because of making working with the files more 
> complex.  But leaving the files as is adds complexity as well.  <sigh>

Yeah, the main reason would be to unify managing the pictures with managing 
the rest of the data. If unifying the pictures makes it more complex to 
manage rather than simpler, it doesn't make sense to do that.  Make sure you 
make that bit modular in your code, and you shouldn't have a problem. :-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message