Re: [SQLObject] Composed Primary key

[Magnus <ma...@th...>]

At 19:13 2003-08-05 -0400, Brad Bollenbach wrote:

>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=
 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=
 table.

I think so too! That's why the propsed feature is good.

>>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 being=20
>useable here, and composite columns (for something other than the PK)=20
>become necessary?

If I have a Money class, my Python class OrderLine would have
an attribute "price", which was an instance of the Money class.
It should *not* have a priceAmount attribute and a separate
priceCurrency attribute. The internal composition of the price
is not the concern of the OrderLine class!

Thus, we get a mismatch between Python classes and RDBMS tables.

 From an OO Design point of view, you separate your data into
two categories: Objects and values. An object is something that
has an identity on its own, like a person, a window, or an
order line. A value is some data which just describes some
property of another object, but doesn't have its own identity,
such as a length, a name, or a monetary amount.

In Python, it's very common that design objects are instances
of a class, and design values have another type than instance,
such as long, float or string, but that's not always the case.

So, while the idea that a class in Python corresponds to a
table in SQL fits the bill in most cases, this is not always
the case. There can be mismatches in both directions.

If you have simple non-scalar objects like dates with time-zones,
money objects with a currency, measurements with a unit and a
given precision etc, you would probably want to "inline" these
values into your main table, rather than to assign some kind
of made up identity to these values and store them in a separate
table. You still implement these "value objects" as instances of
their own class in Python though.

The other way around, you can have a list of integers as a simple
attribute in a Python class, and then you want to go the other
way around, and split your Python class into more than one table.

It would be nice if SQLObject handles both these deviations from
the typical 1 class =3D=3D 1 table situation in a convenient way.

E.g. Python classes that have attributes like below...

class Money
     amt =3D int()
     currency =3D str()

class OrderLine
     id =3D oid()
     order_id =3D oid from Order()
     spec =3D str()
     price =3D Money()

...should be stored in *one* (not two) tables as we seem to
agree on above, with as little tweaking as possible.

On the other hand, if you have something like:

class Curve
    color =3D str()
    style =3D str()
    coords =3D list of complex

E.g.

c =3D Curve()
c.color =3D 'RED'
c.style =3D 'DASHED'
c.coords =3D [(1+2j), (3+5j), (3+2j)]

Then you obviously need two tables to comply to the first
normal form. One with an id, the color and the style, and
a separate table with the coordinate list.


--
Magnus Lycka (It's really Lyckå), ma...@th...
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The Agile Programming Language=20