Saturday, February 25, 2012

Looking for options to fix a poorly implemented solution

So, I've started a new job recently where I am doing work on a SQL
Server database designed by a third party software company, which also
wrote the client software accompanying the database. The client
software is crap, the data model sucks rocks, and I'm stuck with it.
So in no way can I modify client code, or redesign any element of
relational model. I've been able to modify stored procedures and
triggers for performance, perform regular maintenance tasks, and
upgrade all upgradable elements, but that's about it. On top of that,
people developed an internal method of using the datbase that is
causing it to grow way too fast. Basically, there is one table with a
BLOB field that people are using to store Word documents containing
scanned images (part of their efforts to go to a paperless system).
Documents are scanned only when there is no other way to get the
information into the system (client signatures, legal documents from
courts, etc). And I've been charged with getting the size of the
database down. Yay.
Brainstorming for solutions, I was wondering if there is any possible
way to compress BLOB fields in a way that is completely transparent to
the client. I can't think of a way, so I have little hope for that
idea. Another is to go in and make sure all of the images are
compressed. That will only yield marginal results. Finally, going in
and replacing all of the scanned documents with documents that point
to a UNC path with all of the extracted documents is a solution that
will required quite a bit of work, but is possible. (If it were up to
me, I'd just say to heck with it and keep some documents in a paper
system). Any thought about what I could do?
Thanks!When I was at Sprint, the Place Where Consultants Go To Be Punished, our
department got into a document archiving frenzy. Ended up storing all
documents into PDFs, storing them on the server, with only a link to the
document in the database.
- Wm
"AAAWalrus" <aaawalrus@.yahoo.com> wrote in message
news:8b266bc2.0312101204.32a99d74@.posting.google.com...
> So, I've started a new job recently where I am doing work on a SQL
> Server database designed by a third party software company, which also
> wrote the client software accompanying the database. The client
> software is crap, the data model sucks rocks, and I'm stuck with it.
> So in no way can I modify client code, or redesign any element of
> relational model. I've been able to modify stored procedures and
> triggers for performance, perform regular maintenance tasks, and
> upgrade all upgradable elements, but that's about it. On top of that,
> people developed an internal method of using the datbase that is
> causing it to grow way too fast. Basically, there is one table with a
> BLOB field that people are using to store Word documents containing
> scanned images (part of their efforts to go to a paperless system).
> Documents are scanned only when there is no other way to get the
> information into the system (client signatures, legal documents from
> courts, etc). And I've been charged with getting the size of the
> database down. Yay.
> Brainstorming for solutions, I was wondering if there is any possible
> way to compress BLOB fields in a way that is completely transparent to
> the client. I can't think of a way, so I have little hope for that
> idea. Another is to go in and make sure all of the images are
> compressed. That will only yield marginal results. Finally, going in
> and replacing all of the scanned documents with documents that point
> to a UNC path with all of the extracted documents is a solution that
> will required quite a bit of work, but is possible. (If it were up to
> me, I'd just say to heck with it and keep some documents in a paper
> system). Any thought about what I could do?
> Thanks!

No comments:

Post a Comment