> Is there no permanent unique identifier for each game object
> irrespective of which collection it is currently a part of?

1. The index file would grow enormously with an additional unique
identifier.

2. Even with such an unique identifier you do not have direct
access to this game, because this identifier is not an index
(the game number is the index). Using this identifier as an
index would blow up the memory enormously.

3. Searching the game data for the linked game is too slow, this means
searching the database for an unique ID is not practicable.

4. Other database formats do not deliver such an unique ID, as
Steve has pointed out.

Momently I do need see a chance for a reference outside the database,
but probably I'm seeing ghosts here?

> Anyway - linking games within the database will surely add to Scidb's
> complexity and delivery date. Maybe this feature should be
> de-prioritized ?

I think it's the right date for this feature. The goal is to have
a stable production version (hopefully next year). One requirement
is a stable database format, which will not change (for some years).
This feature is influencing the database format.

Currently I'm already working on a next version of the database format,
because:

1. I have an issue with database management concerning the comments,
   I need an additional attribute in the game data section.

2. I have the support of children's chess in my mind (allowing invalid
   moves), this requires a small change in the game flags (index file),
   games with invalid moves have to have a special flag, such games are
   not exportable into other formats, for example.

3. Links to other games requires an additional data file, and an additional
   attribute inside the game data.

4. I'm planning to support the attachement of documents:
   - Attachement to a specific game
   - Attachement to a specific tournament, for example the tournament table
     (PDF or HTML)
   - Attachment to a database, for example a document which gives more
     information about this database.

One reason for the support of attachments is the ChessBase support.
ChessBase is attaching documents, and I'm (almost) knowing how to
export these documents (but this is not yet tested). Moreover I think
that such attachements are very useful, the author has a tool to
point out the specific attributes of a game, or even a whole database.

It's not useful to do the changes of the database format without implementing
the related features, only the practice can show whether the format is
really practicable. The effort for the implementation of the listed features is
not high, except the export of the ChessBase documents. But the latter is part
of the ChessBase support, and some users have shown great interest to switch
from ChessBase to an alternative database.

Gregor

Reply via email to