Overview

SSP "external" tables/views do not enforce referential integrity, but loose, logical dependencies do exist between them. In some cases, even when such a logical dependency exists, it may not necessarily be the case that the depended-on record actually exist in order for the system to function. So producing a completely accurate dependency graph would be a complex effort and likely frequently subject to change as the application evolves. But some deployers have requested guidance on a recommended order in which to update these tables to ensure the complete dataset is an internally consistent as possible at any given time. This document provides such a recommendation. Keep in mind of course that this is just that - a recommendation. Not all the tables listed are required and other orderings might be perfectly valid.

For inserts the ordering is from top-to-bottom, i.e. insert into tables in the order listed. Updates would typically be in the same order as inserts, but ordering is generally less of an issue. Ordering is reversed for deletes (which should be rare). I.e. delete from bottom to top.

This document also provides a "primary use" column which tries to indicate the SSP subsystem that makes heaviest use of the data in any given table. This is intended to help provide implementation prioritization guidance when trying to decide which tables to "support first", inter-table dependency considerations aside. E.g., while external_faculty_course may be listed ahead of external_course, these tables have no logical dependency relationship. So if your deployment is more interested in the MAP subsystem than in the Early Alert subsystem, you needn't populate external_faculty_course before populating external_course.

2.0.0-b3