Multi table inheritance and performance

Question

I really like the idea of multi-table inheritance, since a have a main
class and three subclasses which just add one integer to the main class.
It would be a waste to spend 4 tables on this, so I decided to put them
all into one.
My problem now is, that when I query for a specific class, kodo will build
SQL like:
select ... from table where
JDOCLASSX='de.mycompany.myprojectname.mysubpack.classname'
this is pretty slow, when the table grows because string comparisons are
awefull - and even worse: the database has to compare nearly the whole
string because it differs only in the last letters.
indexing would help a bit but wouldn't outperforming integer comparisons.
Is it possible to get kodo to do one more step of normalization ?
Having an extra table containing all classnames und id's for them (and
references in the original table) would improve performance of
multi-tables quite a lot !
Even with standard classes it would save a lot memory not having the full
classname in each row.

Answer 1

Stefan-
Thanks for the feedback. Note that 3.0 does make this simpler: we have
extensions that allow you to define the mechanism for subclass
identification purely in the metadata file(s). See:
http://solarmetric.com/Software/Documentation/3.0.0RC1/docs/manual.html#ref_guide_mapping_classind
The idea for having a separate table mapping numbers to class names is
good, but we prefer to have as few Kodo-managed tables as possible. It
is just as easy to do this in the metadata file.
In article <[email protected]>, Stefan wrote:
First of all: thx for the fast help, this one (IntegerProvider) helped and
solves my problem.
kodo is really amazing with all it's places where customization can be
done !
Anyway as a wish for future releases: exactly this technique - using
integer as class-identifiers rather than the full class names is what I
meant with "normalization".
The only thing missing, is a table containing information of how classIDs
are mapped to classnames (which is now contained as an explicit statement
in the jdo-File). This table is not mapped to the primary key of the main
table (as you suggested), but to the classID-Integer wich acts as a
foreign key.
A query for a specific class would be solved with a query like:
select * from classValues, classMapping where
classValues.JDOCLASSX=classmapping.IDX and
classmapping.CLASSNAMEX='de.company.whatever'
This table should be managed by kodo of course !
Imagine a table with 300.000 rows containing only 3 different derived
classes.
You would have an extra table with 4 rows (base class + 3 derived types).
Searching for the classID is done in that 4row table, while searching the
actual class instances than would be done over an indexed integer-classID
field.
This is much faster than having the database doing 300.000 String
comparisons (even when indexed).
(By the way - it would save a lot memory as well, even on classes which
are not derived)
If this technique is done by kodo transparently, maybe turned on with an
extra option ... that would be great, since you wouldn't need to take care
for different "subclass-indicator-values", can go on as everytime and have
a far better performance ...
Stephen Kim wrote:
You could push off fields to seperate tables (as long as the pk column
is the same), however, I doubt that would add much performance benefit
in this case, since we'd simply add a join (e.g. select data.name,
info.jdoclassx, info.jdoidx where data.jdoidx = info.jdoidx where
info.jdoclassx = 'foo'). One could turn off default fetch group for
fields stored in data, but now you're adding a second select to load one
"row" of data.
However, we DO provide an integer subclass provider which can speed
these sorts of queries a lot if you need to constrain your queries by
class, esp. with indexing, at the expense of simple legibility:
http://solarmetric.com/Software/Documentation/2.5.3/docs/ref_guide_meta_class.html#meta-class-subclass-provider
Stefan wrote:
I really like the idea of multi-table inheritance, since a have a main
class and three subclasses which just add one integer to the main class.
It would be a waste to spend 4 tables on this, so I decided to put them
all into one.
My problem now is, that when I query for a specific class, kodo will build
SQL like:
select ... from table where
JDOCLASSX='de.mycompany.myprojectname.mysubpack.classname'
this is pretty slow, when the table grows because string comparisons are
awefull - and even worse: the database has to compare nearly the whole
string because it differs only in the last letters.
indexing would help a bit but wouldn't outperforming integer comparisons.
Is it possible to get kodo to do one more step of normalization ?
Having an extra table containing all classnames und id's for them (and
references in the original table) would improve performance of
multi-tables quite a lot !
Even with standard classes it would save a lot memory not having the full
classname in each row.
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com