Re: [SQLObject] Composed Primary key

[Brad B. <br...@bb...>]

On Tuesday, August 5, 2003, at 06:59 PM, Magnus Lyck=E5 wrote:

> At 14:18 2003-07-24 -0400, Brad Bollenbach wrote:
>> > Well, if there's going to be composite keys, that might as well be
>> > generalized to all the columns (i.e., any attribute could be a=20
>> composite
>> > of several columns).
>>
>> What's the use case for this?
>
> For instance money objects that consist of an amount and a currency.
> You could make them full objects with an identifier and do:
>
> order_line
> |id |order_id|spec          |money_id|
> +---+--------+--------------+--------+
> |  1|     123|Dog collar    |       1|
> |  2|     123|Dog food      |       2|
>
> money
> |id |amt    |currency|
> +---+-------+--------+
> |  1|12.50  |EUR     |
> |  2|0.34   |USD     |

This is bad database design. amt and currency belong in the order_line=20=

table.

> But is seems simpler to just do:
>
> order_line
> |id |order_id|spec          |price_amt|price_currency|
> +---+--------+--------------+---------+--------------+
> |  1|     123|Dog collar    |12.50    |EUR           |
> |  2|     123|Dog food      |0.34     |USD           |
>
>
> In this case you could say that the price is a value from a
> design point of view, but an object from a programming point
> of view. Martin Fowler calls such objects "Value Objects" in
> the book "Patterns of Enterprise Application Architechture".

I don't follow your point. At what point do Python properties stop=20
being useable here, and composite columns (for something other than the=20=

PK) become necessary?

--
Brad Bollenbach
BBnet.ca=