Collection Object

[Philip Mötteli]

Am 03.08.2006 um 18:08 schrieb Ruslan Zasukhin:

> On 8/3/06 1:02 PM, "Philip Mötteli" <philip.moetteli at econophone.ch>  
> wrote:
>
>>> Well, after this discussion may be lets begin from start?  :-)
>>>
>>>     Can you give e.g. some simple more specific example?
>>>     With NSSet, 2 tables T1 and T2 to be some objects..
>>
>> What can I tell more?
>> Three tables NSSet, T1 and T2. NSSet has an M:M connection to T1 and
>> another to T2. Instead of making this M:M connection, as a separate
>> table, we have an attribute in NSSet, which is an array of OIDs.
>
> Wait.
>
> Here you describe not ABSTRACTION but its implementation.

So I try to describe the abstraction: We need to have a feature, that  
allows us to make an M:M connection from one field of one record to  
man records in many tables, even to the originating table.


> We already have found at least 3 possible implementation of the same
> abstraction: ARRAY, another table, inheritance, ...

:-)	I don't see yet the inheritance. But an M:M table and an ARRAY,  
are both valid solutions to me.
The problem is, that the separate table produces a lot of programming  
overhead.


>> Three tables NSSet, T1 and T2. NSSet has an M:M connection to T1 and
>> another to T2. Instead of making this M:M connection, as a separate
>> table, we have an attribute in NSSet, which is an array of OIDs.
>> Searching should be
>> 1. by looking at the content of this array itself and
>> 2. by dereferencing the OIDs and looking at their content.
>>
>
>> E. g:
>>
>> NSSet {Rec_ID recID; unsigned int n; Array of OID members;}  
>> tableID = 1
>> T1 {Rec_ID recID; char *name;} tableID = 2
>> T1 {Rec_ID recID; char *name;} tableID = 3
>>
>> (1) SELECT OID
>> FROM NSSet
>> WHERE members[*] == anOID
>>
>> (2) SELECT OID
>> FROM NSSet
>> WHERE members[*].name == 'aName'
>>
>> "SELECT OID" always means a subset of the content of the members  
>> array.
>>
>> This array type of field should be able
>>
>> 1. ordered
>> 2. allow multiple insertions of the same member (OID, or other type)
>> 3. to address members randomly (not only serially)

> * do you want to get really SQL searches as above, or you just use  
> them as
> example? I.e. Will be you happy, at least on start with API functions?

For case (2) I definitely need SQL.
But case (2) is an optimization to leverage the relational part of  
the data-store. And it will be implemented way after case (1).


>> 1. by looking at the content of this array itself and
>>
> * okay, this not looks as hard task

Very good!


>> 2. by dereferencing the OIDs and looking at their content.
>>
>
> * here we can have variants.
>
>     One of them, that you develop this mechanism self as external
> algorithms.

That would destroy the very aim of this. As I said just some lines  
above, this application is only needed for performance optimization.  
I will automatically implement a LOCAL algorithm of this. Actually  
Apple has already done that for me:
- (NSArray *)filteredArrayUsingPredicate:(NSPredicate *)predicate


> Best of all in C++.

I do not have enough knowledge of C++ to deliver you such a code.  
And, I'm sorry, I really would prefer not have to learn C++ more than  
the minimum I know so far. I don't want to start yet another language  
war, so I don't go into more detail. It's not worth it.


> I do not see so far where this can be
> penalty from tech/performance view of point

If I have it locally, every record must be loaded and de-serialized,  
passed through KVC, only to throw most of these objects right away in  
the trash, because they don't fulfill the query. Having 30'000'000  
records and you are just looking for one… this is a huge waste of  
resources.


>     Of course it is more simple for you to have this builtin into
> engine...but again, if this will be designed as some set  
> of .cpp / .h files
> then generally speaking it is not important who have made these  
> files. Only
> if you will point some problem/task which can be solved more  
> efficient if
> have access to deep levels of engine.
>
> What you think ?

Sorry!	:-|


> So my resume:
>
>     AT LEAST as first step in this direction,
>     we need add new field type:
>
>         ARRAY of numeric items with type T based on BLOB,
>         with ability to index this column vertically.
>
> Right ?

Yes, except, that I'm not sure if it's vertically or horizontally.  
But you are probably right.	;-)


>> The only useful thing, table-wise inheritance could bring me, would
>> be the reduced redundancy of IVars/fields combinations. I mean, every
>> subclass actually copies its super-classes IVars in its table
>> representation.
>>
>
> You mean this is as NOW you design it ?
>
>
>> But because I use the NSCoding protocol in order to serialize my   
>> objects, I
>> almost can't distinguish, if an IVar comes from a  superclass or not.
>>
>
> IMPORTANT POINT is
>
> If you split N records into M tables, then you get M indexes.

Yes, but don't forget, I need those tables anyway, because every  
subclass has additional IVars.


Re
Phil