Many applications use
several SAS files. It is to your advantage if, while designing your
application, you identify and divide the following:
-
the set of files that must be updatable
by more than one user at a time
-
the files that will be updated
by only one user, but while other users are reading the files
-
the files that will be updated
so infrequently that access to those files by all users is practically
read-only.
The files in the first
group are excellent candidates for access through a server. The files
in the second group are often good candidates for access through a
server, but for some applications the performance improvement from
not accessing the files through a server might make it worthwhile
to use a more complicated procedure to update those files while the
users are not around. The files in the third group are almost always
poor candidates for access through a server because all of the operating
environments that SAS runs under provide shared read-only access to
files, and that direct access is almost always faster than access
through a server.
Here is a summary of
the advantages and disadvantages of dividing files into read only
and concurrently updated libraries:
-
A SAS file that is accessed through
a server usually costs more, in terms of computing resources, for
users of the application to use than a SAS file that is stored in
a library that is accessed directly by the users.
-
Reduced traffic through a server
optimizes response time for the users of the concurrently updated
files.
-
Simpler, more direct access to
read-only copies of files reduces the cost of an application's query
and reporting functions. Note that such a copy might be a subset instead
of the entire file.
-
A SAS file that is accessed through
a server can be updated while it is being queried or reported on.
-
Copies of files require disk space.
-
A file in a SAS library that is
accessed directly by users cannot be updated while a user executes
the part of the application that uses that file.