Money is made of dollars and cents, but stored as one field because dollars and cents are properties of the same value, not values themselves (you can use simple math to convert between the two). Weight is made up of pounds and ounces, but is also stored in a single column for the same reason.

Likewise, it seems that x,y and z dimensions are really just one value as well, with three properties since there is little need to know x without y and z in an application (but you may want to query on them discretely).

In OOP, we usually create objects to handle special primitive types like dates, money, weights, and dimensions. But unlike the other primitives, you can't simply add dimensions together and stuff them in a decimal column and hope to get them back out again.

You could store dimensions in a varchar with a delimiter, like 7;4,2;2, but this would make any queries for certain values difficult. ie. "get the record that has the longest (any dimension) side".

Of course, the conventional approach of storing x,y, and z in separate decimal columns would also have issues with a "get the longest side" query, since the database wouldn't treat them as one value collection. (You would have to get the longest of each, then the longest of the three results).

So I'm looking into the spacial data types which seem designed for map making, but it occurs to me that a data type designed to hold coordinates in 3d space would probably work just as well for defining 3d objects since it would still be a collection of x, y and z treated as a cohesive unit in one field with the ability to query coordinates separately.

Unfortunately, I'm having a hard time finding good information on using spacial types and I'm not sure if they can be used in this manner.

Can spacial types be used to store the dimensions of 3 dimensional objects?

Money is made of dollars and cents, but stored as one field because dollars and cents are properties of the same value, not values themselves (you can use simple math to convert between the two). Weight is made up of pounds and ounces, but is also stored in a single column for the same reason.

Likewise, it seems that x,y and z dimensions are really just one value as well, with three properties since there is little need to know x without y and z in an application (but you may want to query on them discretely).

In OOP, we usually create objects to handle special primitive types like dates, money, weights, and dimensions. But unlike the other primitives, you can't simply add dimensions together and stuff them in a decimal column and hope to get them back out again.

You could store dimensions in a varchar with a delimiter, like 7;4,2;2, but this would make any queries for certain values difficult. ie. "get the record that has the longest (any dimension) side".

Of course, the conventional approach of storing x,y, and z in separate decimal columns would also have issues with a "get the longest side" query, since the database wouldn't treat them as one value collection. (You would have to get the longest of each, then the longest of the three results).

So I'm looking into the spatial data types which seem designed for map making, but it occurs to me that a data type designed to hold coordinates in 3d space would probably work just as well for defining 3d objects since it would still be a collection of x, y and z treated as a cohesive unit in one field with the ability to query coordinates separately.

Unfortunately, I'm having a hard time finding good information on using spatial types and I'm not sure if they can be used in this manner.

Can spatial types be used to store the dimensions of 3 dimensional objects?