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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
