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.

> Yes, but makes the application have to perform less and changes where 
> the work is done.

The real advantage is you can change what's stored underneath (like, say, 
changing the primary keys, or changing whether you talk about "attachments" 
or "spans") without updating the application. You rearrange the database, 
rewrite the views, but all your calculation code etc stays the same.

> That works if the GPS location used in each instance is exactly the same 
> - get off by a bit and you have a duplicate pole 1' away from the 
> existing pole.  But a good interface could check for that and prevent it 
> from happening.

Right. That was the "precise enough" bit. :-)

> Yes, you just can add another 'property'.  But not if you miss a 
> fundamental requirement that alters the data you already have organized.

The advantage of basing the schema on the "real world" is that if you miss a 
fundamental property, it's because the data isn't available.

> I was referring to the situation where a piece of data was not accounted 
> for in the database.  You must define ground rules for the database so 
> you can define the piece of data and know where it actually should get 
> stored.  We have been lacking in such definition.

Well, yes, it's hard to store data you don't know about. :-)

I was simply talking about the addition of new types of data after you 
already have the existing data defined.

> yes, several alternatives can achieve the same outcome.  Our group 
> sometimes has trouble seeing that.  

Ah, welcome to the club. ;-)  That's why I like being boss.

> What is the practicality of storing the images in the DB as a field 
> (blob or something else)?

Well, it'll certainly make things slow. If you want to store them in a 
database rather than the file system, *this* is a perfect use case for 
having a second database. :-) Make them blobs in the second database, and 
refer to them from the first database.

The benefits of doing this are that you get easy access to the pictures from 
the same place you have any of the other data (i.e., you don't have to 
figure out how to set up network shares, your login information can control 
access to the pictures, etc.). But you also have the advantage that you 
don't have to back up the database as often, you can put it on a different 
partition or a different server, etc.  (For example, say the customer FTPs 
the pictures to you. You could pull the pictures out of the incoming 
directory and put them into the PolePicture blob database when you created 
the pole record in the primary database that references the picture. Then 
you could leave the pictures on the FTP server until you back up the blob 
database at the end of the week/month/whatever, whereas you'd probably want 
to be replicating the actual transactional database live.)

So generally that's what I'd recommend. Be sure to write the code to fetch 
the pictures modularly, so you can move it to an entirely different server 
with an entirely different connection string if it gets too big or something.

And read up on the technical details of how blobs are handled in storage, so 
you don't wind up configuring yourself into a corner or something. :-)

-- 
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