One of the more difficult decisions
to be made when deploying AccuSQL across a campus or when adding entities to an existing system is whether or not to place
all entities on one database or give some, or all of them separate databases.
The general criteria used to come to the best decision is often based on the
following:
·
How often entities would be able to make good
use of tracking data collected by other entities.
·
The level of sensitivity of the tracking data
collected within an entity.
·
How the management of several databases impacts
the technical staff charged with their maintenance.
·
The funding sources for each entity.
·
The scope of reporting needs for both the
individual entities as well as the institution.
Based on the above criteria, the types of entities most often placed on a separate database include grant funded programs, student behavioral or health related programs, disabilities services and programs where there is no need to store all students on the student table. Types of entities that almost always share a database include student affairs departments (advising, financial aid, registration, new student orientation), student life, housing, fitness locations, honors programs, and student support programs (tutoring, mentoring, supplemental instruction). Using this criteria should result in the ability of the separated entities to report more easily to their
outside funding source while the entities sharing a database location can leverage cooperation
between themselves for the sake of student success. The more entities share databases, the more institution wide reporting
will have the ability to address a student’s usage of resources from the moment the
student registers for a new student orientation onward to when the student graduates. Institutional reporting becomes more
comprehensive the more campus entities use a shared database.
Here is a list of pros and cons to consider when deciding if your department/program should have a separate database location:
Pros of a Separate Database
§
Avoids commingling student records between services offered by different funding sources.
§
Allows the program to use the unique student
profile to pre-qualify prospective participants when services are offered only to eligible students.
§
Allows the program to project participation rates
by tracking recruiting processes.
§
Safeguarding of sensitive records.
§
Easier report creation as filters for
non-participants are not needed.
Cons of a Separate Database
§
Technical support will have to repeat updates
and imports for the separate database.
§
Usage of other campus resources by participants
will not be viewable in the separate database.
§
Campus partners will not be able to view usage of resources by participants in the separate database.
§
Resources available elsewhere on campus will not
be included in the Individual Educational Action items for users in the separate database.
§
Individual Educational action items assigned by
other programs and departments will not be viewable by users in the separate database.
§ Institutional reporting will be not be seamless and will have more opportunity for duplication issues.