To me, the logical design is to have objects that can contain other objects in arbitrary configurations. This allows for cities that contain facilities, facilities that contain rooms, rooms that contain rack rows, rows that contain racks, racks that contain objects, and so on.
I agree that objects which can contain racks/rows sounds appealing. To further clarify the idea...
- 'Location' would be a new Type of object. Locations could be contained within other locations, handling the cities/facilities/rooms scenario you described above. - 'Row' and 'Rack' would also be new Types of objects. I like the existing user interface for managing rackspace. It would need to be adjusted to use the new data model while retaining the existing look and feel. - Treating Locations, Rows and Racks as objects would allow attributes to be assigned to them. - Right now the table storing object data is named 'RackObject'. If the preceding changes are made, 'Object' would be a more appropriate name. Custom reports and other home-made apps which interact with RackTables on the SQL level would need to be adjusted to use the new table name. As discussed in previous threads, and API would be helpful in this type of situation. - Data from the 'RackRow' and 'Rack' tables would be moved to the 'Object' table. Afterwards, the 'RackRow' and 'Rack' tables would be dropped.
-- Aaron Dummer