Home > Archive > Software Engineering > May 2006 > Storing values...in script or in database?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Storing values...in script or in database?
|
|
| Zamdrist 2006-05-16, 7:08 pm |
| I'm writing a logon script in the Windows environment using VBS. Part
of the logon script copies Word template toolbars depending whether or
not a user is in a particular group or not.
There are nine of these templates. A user could be in all, one or none
of the groups. These templates exist out on the network and via the
logon script are copied to their home directory that corresponds to
their Word 'startup' folder.
My question is: I can hardcode the names and paths of the groups, file
names & paths in the script file as constants easily enough, but would
a database table lookup be better? Sure, it would be  er :) But
would there be an meaningful benefit? I can think of some pros and cons
off the top of my head:
Pro:
Managing a table of values is somewhat more accessible to a non
programmer type.
An interface to manage these values could be made accessible on the
Intranet
Adding a new set of values, i.e. group, path, filename doesn't require
a programmer's intervention.
Con:
Script would be need additonal objects such as ADO.
Script would be reliant upon a data connection in order to complete its
function.
Script would require a bit more documentation to explain exactly what's
going on.
Your thoughts would be greatly appreciated!
Steve
| |
| Zamdrist 2006-05-16, 7:08 pm |
| A couple of notes:
In order to go the database table route, I would have to either run the
stored procedure for each group the user is in, or build a Where...In
('...') string.
Also, the these particular groups are not added/subtracted to often by
any means, they are pretty static. Nor do the paths and names of the
templates change frequently.
| |
| H. S. Lahman 2006-05-16, 7:08 pm |
| Responding to Zamdrist...
> I'm writing a logon script in the Windows environment using VBS. Part
> of the logon script copies Word template toolbars depending whether or
> not a user is in a particular group or not.
>
> There are nine of these templates. A user could be in all, one or none
> of the groups. These templates exist out on the network and via the
> logon script are copied to their home directory that corresponds to
> their Word 'startup' folder.
>
> My question is: I can hardcode the names and paths of the groups, file
> names & paths in the script file as constants easily enough, but would
> a database table lookup be better? Sure, it would be er :) But
> would there be an meaningful benefit? I can think of some pros and cons
> off the top of my head:
Some sort of external configuration data will be better than hard-wiring
the names in the scripts. Scripting and markup languages were abandoned
in the early '70s largely because they are a pain to maintain. [And
were reborn in the late '80s. How soon we forget. B-)] Hard-coding
just increases the need to touch them.
Whether you should use a database rather than a flat configuration file
or some other mechanism really doesn't matter. (Depending on the OS you
can also use things like environmental values, registry entries, etc..)
The key idea is that you just want your constants defined in one
place, preferably outside the code. Note that if the scripting language
supports included scripts, you can achieve pretty much the same thing by
just isolating the constants in their own script.
>
> Pro:
> Managing a table of values is somewhat more accessible to a non
> programmer type.
> An interface to manage these values could be made accessible on the
> Intranet
> Adding a new set of values, i.e. group, path, filename doesn't require
> a programmer's intervention.
If the constants are used in multiple places (or may be in the future),
one has multiple edits to execute changes. That increases the
opportunities for inserting defects.
The scripts are now portable to different contexts. Only the <local>
configuration data needs to change.
>
> Con:
> Script would be need additonal objects such as ADO.
Only if it is in a database.
> Script would be reliant upon a data connection in order to complete its
> function.
Only if it is in a database. These two issues are trade-offs to be made
when designing the application. The main justification for using a DB
is to allow customers access to the data. However, you probably want to
provide a buffer update application for that anyway so you can control
access and do error checking. Once you have such a buffer the rear end
doesn't matter.
> Script would require a bit more documentation to explain exactly what's
> going on.
Perhaps not if it is a coding standard. B-)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Zamdrist 2006-05-16, 10:00 pm |
| Thank you for your thoughts. I will ponder other solutions.
|
|
|
|
|