MP wrote on Oct 7^th, 2007 at 3:01pm:

Depends on how you want to use it. If you are trying to emulate a relational-style multiple field primary key, then yes.

Quote:

No. You can use XResultSetValue to override.

MP wrote on Nov 15^th, 2007 at 2:39am:

If you are doing what I think you are, @IsUnique should be faster. Single value comparison, stops on first match. The @XResultSetSearch method requires multiple comparisons and will continue looking until it finds all matches.

Quote:

I think so, but I'm not where I can check. I'll confirm in the morning.

Quote:

Honestly, MP, this very rarely comes up. The vast majority of our user base doesn't have any need (or desire) for that level of milking and optimization. The only time we hear this kind of question is when pro developers come at us from something like Oracle and haven't shaken off the big engine mindset. We are designed for a different environment and a different kind of user than Oracle and SQL Server and such.

The answers to these questions are usually pretty straightforward and short enough to where white papers are kind of overkill.

I'll confirm this in the morning, but I believe the PREINDEX index for a field is built the first time per session that the server uses that field value as the key value in an X command. Once an index exists, it is updated when indexed values are changed/added/deleted. So, the first X command per session using a particular key field will be slower than all subsequent X commands using that key field. PREINDEX speed increases only apply to absolute key values like "APPLE".  Keys including a search spec, like "..APPLE.." do not benefit. Unloading a database also unloads the indexes for that database.

Optimizing queries involves some very basic rules, some of which are common sense to someone with your experience:
1. Absolute searches are faster than searches with wildcards or ranges.
2. Programmed retrieve specs are slower than non-programmed. Wherever possible, pre-resolve constant values like @Date in a retrieve spec by using the pipe (|) syntax to gain significant speed over the {} equivalent.
3. For subrecord searches, Natural linking is faster than Relational linking.

You're not dealing with JOINs or HAVING clauses or nested SELECTS or any of that kind of stuff. To put this in SQL parlance (although we are not SQL-based), you have the equivalent of SELECT, WHERE and ORDER BY with no nesting. Subrecords add a level to that under-the-hood, but you get my drift. It's a very straightforward query environment. 

We maintain a constant presence among our users, so we are constantly adding tools and making adjustments to optimize Sesame to the way it is actually being used in the field. If you have questions about specific things, the developers and Support people are here and willing to help, or you can contact Support directly. Also, there is a section in the back of the User Guide that discusses some of our internal structures and may provide some of the information you are after.

Edited:

Hammer wrote on Nov 15^th, 2007 at 3:34am:

Thank you for the detailed and informative response.  I freely admit to being a (graduate?) student of the "big engine mindset".  But even if that wasn't true, regardless of the programming task at hand, I prefer to know as much about the internals as possible so that the answer to "Why is this slow?" isn't that I didn't program it efficiently the first time.  Not that I've had that question asked about my Sesame application yet (which, BTW, is still in BETA).  I'm just trying to pro-actively keep those questions at bay.

Your response does inspire one more question.  I try to avoid any functions that rely on a form, such as XLOOKUP.  I understand their genesis, but they still rub me wrong.  I prefer to utilize the data abstraction layer that is available via the XResultSet functions.  But a key (possible) advantage in the XLOOKUP world is @XLookupSourceList.  In a client/server environment, this method clearly does everything in a single fetch.  The same may or may not be true in the XResultSet world, thus leading to the following question:

Do XResultSetValue and @XResultSetValue impose a network cost in a Client/Server environment, or are they working with a cached result set on the client side?  And, if each @XResultSetValue does a single write/commit across the network, is there a more efficient way to batch together a set of updates to a ResultSet?

PS: The Philosophy and Advanced Concepts appendixes were the first things I read when evaluating your product.  They gave me the confidence that this was a product worth exploring further.