According to the Data Model Resource Book, a FACILITY entity stores the
attributes or relationships associated with a physical structure.
Facility types include warehouse, plant, building, room, office.
The type of storage tank I was referring to is one you would see in a
tank farm - it could be as large as a multi-story building. From my
perspective, it is a facility, but it could also be a fixed asset (just
like any other facility).
-Adrian
David E Jones wrote:
A storage tank might be better modeled as an asset that is located in a
facility rather than being a facility itself.
BTW, we already have a UOM field to go along with the "squareFootage" field
(which is unfortunate that it was done that way, but it's been there for a while now).
This isn't a change in primary key or anything that requires significant migration, and
in fact is just expanding the field size (specifically the decimal size of the numeric
field). Most existing databases won't have to do any migration at all unless they want to
start storing decimal values instead of just integer values in this field.
-David
On Mar 30, 2010, at 9:28 AM, Adrian Crum wrote:
Good idea Scott! Taking it one step further, how about supporting volume too? A
facility might be a storage tank.
-Adrian
Scott Gray wrote:
If we want it to be a bit more generic we should probably add two new fields:
floorArea and floorAreaUomId and then deprecate squareFootage, perhaps with a
migration service to populate the new fields with the data from the old.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/03/2010, at 7:22 AM, Jacques Le Roux wrote:
Hi,
I'd like to allow Facility.squareFootage to support decimals. In order to do
that, I need to change the type of the squareFootage field from numeric to
fixed-point. I can't see any issues doing that OOTB. But in case this would be
a problem for someone I prefer to warn.
Jacques
