Thanks David, I didn't look at the entity in question before commenting, if there is a uom already then Jacques proposal sounds fine to me (aside from the unfortunate name of the existing value field).
Regards Scott On 30/03/2010, at 9:37 AM, 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 >
smime.p7s
Description: S/MIME cryptographic signature
