Station_Disks
- station_disk_id: generated primary key, notnull
- station_id: foreign key to stations, notnull
- node_id: foreign key to nodes, notnull
- mount_point: string, notnull
- disk_size: integer, notnull
- disk_status: foreign key to new station_disk_statuses, notnull
- description: string
- Unique Keys:
- station_id and mount_point combination are unique
- node_id and mount_point combination are unique
Station_Disk_Statuses
- disk_status: primary key, notnull
- disk_status_desc: string, notnull
Disk_File_Locations
This could be thought of as Disk File Cache too, but its similar our earlier Data_File_Locations, so I recommend naming it thus. Others can argue and win without much fight from me on this issue. While it is similar in concept to our current Data_File_Locations table, it is different enough to warrant its own table. In light of this, we should really think of our data_file_locations as tape_file_locations - but PLEASE NO NAME CHANGES NOW! Make a synonym if you want! Actually, if we make this split it may make it possible for us to cleanup the implementation of data_file_locations - but let's defer it till after v1.5 shall we?
- disk_file_id: generated primary key, notnull
- station_disk_id: foreign key to station_disks, notnull? I think it should be but had nullable on my board?
- file_id: foreign key to data_files, notnull
- directory: string, notnull
- start_time: date, notnull (for now will equal create_date, but it may differ if we decide to track a date given to us by the station server)
- end_time: date
- Unique Keys:
- station_disk_id, file_id and directory combined are unique
Disk_File_Project_Deliveries (or a better name if you have one)
- disk_file_id: foreign key to disk_file_locations, not null
- project_id: foreign key to analysis_projects, not null
- start_time: date, not null (for now will equal create_date, but it may differ if we decide to track a date given to us by the station server)
- end_time: date, not null
- Unique Keys:
- disk_file_id and project_id combined are unique