benb196 / archive-master Goto Github PK

Rough outline of the Archive Master Schema/Table Breakdown

Table 1:

• collection
  • id (int, auto-gen, unique, not null)
  • name (varchar, unique, not null) Do we want this to be unique?
  • description (text, nullable)
  • parentCollectionId (int, nullable) This allows for nested collection/subcollections.

Table 2:

• item
  • id (int, auto-gen, unique, not null)
  • collectionId (int, not null)
  • name (varchar, unique, not null) Do we want this to be unique?
  • description (text, nullable)
  • parentItemId (int, nullable) Should we consider allowing items to be attached to other items? Or should everything just be kept under collections only? Simpler if we drop this field.

Table 3:

• file
  • id (int, auto-gen, unique, not null)
  • filename (varchar, not null)
  • file (longblob, not null)

Table 4:

• itemFileMap
  • id (int, auto-gen, unique, not null)
  • itemId (int, not null)
  • fileId (int, not null)

Table 3:

• metadataMap
  • id (int, auto-gen, not null)
  • collectionItemId (int, not nullable) Either a collectionId or itemId must be set here.
  • collectionItemIdType (int, not null) This will be an enum that will state what the collectionItemId is referring to, so that the proper lookup can be done
  • metadataNameInheritance (boolean, not null) Determines if subcollections/items should inherit the metadataName. Note if sub-items are dropped this field would only apply to subcollections.
  • metadataNameId (int, not null)
  • metadataValueInheritance (boolean, not null) Determines if subcollections/items should inherit the value of the metadataValue. Useful if you want many items in a collection to have the same metadata fields but different values. Note if sub-items are dropped this field would only apply to subcollections.
  • metadataValueId (int, nullable) Only required if a map is being directly linked to an item, or if metadataValueInheritance is set to 1.

The next two tables can either be defined by us, if we want to only allow users to use specific standards. Or we can allow users to add/update/remove from the tables if we want them to have control.

Table 4:

• metadataName
  • id (int, auto-gen, unique, not null)
  • name (varchar, unique, not null)
  • metadataTypeId (int, not null) This will be an enum and will offer standardized data types which can be validated (string, int, date, etc.)

Table 5:

• metadataValue
  • id (int, auto-gen, unique, not null)
  • value (text, not null) This field would be validated against the metadataTypeId field

The next two tables are for users/logging, and do not directly impact the core functionality of the system.

Table 6:

• user
  • id (int, auto-gen, not null, unique)
  • firstName (varchar, nullable)
  • lastName (varchar, nullable)
  • userName (varchar, not null, unique)
  • userpermissionId (int, not null) This will be an enum which specifies the user permissions... either archiver or read-only archiver.
  • password (varchar, not null)

Table 7:

• auditLog
  • id (int, auto-gen, unique, not null)
  • userId (int, not null)
  • action (varchar, not null) Refers to actions like: add, delete, update along with the thing that was changed.
  • timestamp (datetime, not null)