PMFJI Paul,
P3ndrag0n,
Well, yes the table can be normalized further. "AVDate", "BoardDate", etc are actually data as field names.
And what happens in a year when you (or someone) might want to add another date, say "GroupDate" (or whatever). Using your table structure, you would have to modify the table, queries, forms, reports and possibly code.
Consider:
Code:
tblBuildings
-----------------
BuildingsID (PK) (autonumber)
Building (text)
Room (text)
tblUpgrades
-----------------
UpgradesID (PK) (autonumber)
BuildingID_FK Long (foreign key to buildings
UpgradeDate (text) (values can be: Summer 2015, Spring 2015, Winter 2015 or Winter 2016)
UpgradeType (text) (values can be: AV, Board, Seating, Table)
Because there are so many values for "UpgradeDate", I would also have a (look up) table for Upgrade Dates.. Then the structure would be:
Code:
tblBuildings
-----------------
BuildingsID (PK) (autonumber)
Building (text)
Room (text)
tblUpgrades
-----------------
UpgradesID (PK) (autonumber)
BuildingID_FK Long (foreign key to buildings)
UpgradeDateID_FK (Long) (foreign key to tblUpgradeDates)
UpgradeType (text) (values can be: AV, Board, Seating, Table)
tblUpgradeDates
-----------------
UpgradeDateID_PK (autonumber)
DateWhen (text) (values can be: Summer 2015, Spring 2015, Winter 2015, Winter 2016......, Winter 2020)
This way, if there is no date for "Seating date" or "Table date" there is not a record. All "dates" are in one field.... searching is Soooo much easier.
My $0.02..............