Each student group location (i.e., Rome, Mayagüez, Columbus, ...) enters data that must be written to the database while remaining linked to that location. There are multiple approaches for database architecture to store this.
1) The original program created individual tables for each location, called "Location" tables. At any given time, there are many dozen of these, which makes the SHOW TABLES listing cluttered and the handful of non-Location tables difficult to find.
2) When QuarkNet began maintaining the program, Joel attempted to distinguish the Location tables by adding a _LOC_ prefix to them. This works to make the SHOW TABLES listing clearer, but it is a bit ungainly and adds code overhead to remove the prefix for display. On the other hand, this overhead has been accomplished, and shouldn't take too much effort to carry forward.
3) The data from all locations can be stored in a single table, say LocationData, with an FK to link each data record to its location. This is cleaner in architecture, but the table in question might become so large that it noticeably affects performance, especially since the table will receive heavy read/write activity during a masterclass session.
Each student group location (i.e., Rome, Mayagüez, Columbus, ...) enters data that must be written to the database while remaining linked to that location. There are multiple approaches for database architecture to store this.
1) The original program created individual tables for each location, called "Location" tables. At any given time, there are many dozen of these, which makes the
SHOW TABLESlisting cluttered and the handful of non-Location tables difficult to find.2) When QuarkNet began maintaining the program, Joel attempted to distinguish the Location tables by adding a
_LOC_prefix to them. This works to make theSHOW TABLESlisting clearer, but it is a bit ungainly and adds code overhead to remove the prefix for display. On the other hand, this overhead has been accomplished, and shouldn't take too much effort to carry forward.3) The data from all locations can be stored in a single table, say
LocationData, with an FK to link each data record to its location. This is cleaner in architecture, but the table in question might become so large that it noticeably affects performance, especially since the table will receive heavy read/write activity during a masterclass session.