Re: [GENERAL] Retrieval of OO objects.
От | Oliver Elphick |
---|---|
Тема | Re: [GENERAL] Retrieval of OO objects. |
Дата | |
Msg-id | 199904170901.KAA12072@linda.lfix.co.uk обсуждение исходный текст |
Ответ на | Re: [GENERAL] Retrieval of OO objects. (Chris Bitmead <chris.bitmead@bigfoot.com>) |
Список | pgsql-general |
Chris Bitmead wrote: >I guess the point is if you had an Eiffel collection of animals, two >Invertebrates and two vertibrates, and did a save to disk. When you >loaded the collection back in from disk you wouldn't expect to get back >4 animals, whose status as vertibrates or invertibrates is no longer >known. > >In a real object database, you could say "Get all the animals", and they >would come back appropriately - some as vertibrates, some as >invertibrates. Since they come back properly we can call methods on >different types of animals and they will behave differently as >appropriate. That is so; however, if you use class `animal' only, you can see only the features that are appropriate to animals as a whole. To see features of more specialised classes, you have to use those classes. To take a real-life example in PostgreSQL: Table = person +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | id | char() not null | 10 | | name | text not null | var | | address | int4 | 4 | | salutation | text default 'Dear Sir' | var | | envelope | text | var | | email | text | var | | www | text | var | +----------------------------------+----------------------------------+-------+ Table = organisation (inherits from person) +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ [inherited fields] | contact | char() | 10 | | structure | char() | 1 | +----------------------------------+----------------------------------+-------+ Table = customer (inherits from organisation) +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ [inherited fields] | acs_code | char() | 8 | | acs_addr | int4 | 4 | | class | char() default '' | 1 | | type | char() | 2 | | area | char() | 2 | | country | char() default 'GB' | 2 | | vat_class | char() | 1 | | vat_number | char() | 12 | | discount | float8 | 8 | | commission | bool default 'f' | 1 | | status | char() default '' | 1 | | deliver_to | int4 | 4 | | factor_code | text | var | +----------------------------------+----------------------------------+-------+ Table = supplier (inherits from organisation) +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ [inherited fields] | terms | char() | 2 | | acs_code | char() | 5 | +----------------------------------+----------------------------------+-------+ In this case, customer and supplier both have a field `acs_code', but the lengths are different and the meaning is different (customer account code and supplier account code). I could define a field `status' for supplier which was a CHAR (like the one in customer) but meant something entirely different: customer status - null = normal, s = suspended, p = prepay only; supplier status - p = preferred, x = no longer used. I might also have another inheritance tree of individual inheriting from person, where status is - s = single, m = married, d = divorced. It would be wrong to mix these columns into one, because their meanings are different. If you were to `select status from person*' which column should be shown? You are right to say that all data should be retrievable, but wrong in wanting to attach descendant features to an ancestor class. In this example, if I want a list of contacts, I must `select contact from organisation*', because person does not have a contact field. I lose nothing thereby, because there is no information to be got from any other sub-trees about contact. If any other descendant of person does define contact, it does not have the same meaning as does contact in organisation and it should not, therefore, be reported anyway. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 ======================================== "But as many as received him, to them gave he power to become the sons of God, even to them that believe on his name." John 1:12
В списке pgsql-general по дате отправления: