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