Hi OC,

Did you try the ERXExistsQualifier?

You can use it on a ToMany relationship so you don’t need to filter in RAM, 
instead you can filter in SQL.

Here’s some slides to explain how to use it:
http://www.chatnbike.com/presentation_existsQualifier/
AARON ROSENZWEIG / Chat 'n Bike
e:  aa...@chatnbike.com  t:  (301) 956-2319             
        

On Jul 8, 2016, at 7:10 AM, OC <o...@ocs.cz> wrote:

> Actually, I wonder...
> 
> On 8. 7. 2016, at 10:11, OC <o...@ocs.cz> wrote:
>> Alas, my DBTables contain _lots_ of DBRecords, and thus the above 
>> implementation would get terribly slow
> 
> ... my setup is pretty standard, i.e.
> 
> - DBTables are represented by rows in one DB table, say, T_TABLE
> - all DBRecords of all tables are represented by rows in another DB table, 
> T_RECORD, with a foreign key into T_TABLE.
> 
> Therefore, whenever DBTable records are used anyhow, *always* the huge 
> T_RECORD table is filtered by the desired foreign key. Of course there is an 
> index on that column, but since the table contains zillions of records, it is 
> still somewhat at the slow side.
> 
> Conceptually, it would make much better sense to have a separate database 
> table for records of each T_TABLE row: almost all operations need just 
> records of one table; there is a very little or nothing to do over records of 
> more different tables at once. Database-level, I can pretty well imagine 
> something like many tables named T_RECORD_X where X would be e.g., the 
> primary key of each T_TABLE_ROW. Nevertheless, I can see absolutely no 
> reasonable way of EOmodelling such a thing? (Note that _tables_ -- not just 
> rows -- would have to be added/removed to/from the schema on-the-fly, as 
> users create/delete tables. Table creation/deletion _can_ be slow though; we 
> need table processing to be fast.)
> 
> Are there some well-tested tricks for such cases?
> 
> Thanks again,
> OC
> 
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
> 
> This email sent to aa...@chatnbike.com

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to