OC, > >> 1- Store additional attributes in a serialized map structure (json, >> serialized php array, serialized java objects or property list). > > Precisely what I did. Works well, but is unacceptably slow (even if I cache > unarchived dictionaries in Eos, fetching and unarchiving just the first > time).
If your dictionaries are stables and mostly read-only, you may cache then globally using your EO globalID as the key and add some way te refresh them (time, notification of change, ...) That would be way faster and less memory hungry. >> 2- Store the additional attributes in an dedicated entity with a commun >> dictionary of attribute definitions. > > I use this approach in some specific cases (like e.g., file attachments), but > to exploit it for all dynamic attributes I would fear all those joins would > bring performance problems, too. Definitely I might be wrong, but I think a > flat denormalized table would be consideraly faster. That why you need to use the ERXExistsQualifier. Anyway if you use regular qualifiers directly with joins, you will not get the expected result. A flat table may be faster maybe not. The server will end scanning at some point on a flat table with many qualifiers and may better use indexes with a normalized structure. A flat table can be a compromise if you pre-allocate some attributes and simply allows the user to name and map them. For exemple, your model have 4 decimal attributes, 5 texts, 3 int and you have a way to define which one are used, their label and display order. If you have data with multiple template, your searches are limited to data using a commun template. If fast queries are required with such dynamics structure, you may also consider building a Lucene index of your data, it will be orders of magnitude faster than any SQL engine. That was our solution for www.richelieu.com and we needed to add some slang support and strange imperial unit parsing for the text queries entered by users. Samuel _______________________________________________ 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
