> As I recall it, the issues were size and speed, coupled with the need
to create an online repository that could act as the equivalent of a
DOI or ISBN for chess games, at least for Scid's sake. See for
instance this discussion which recalled another one:
http://comments.gmane.org/gmane.games.board.chess.scid.user/4759
This is a very interesting discussion thread that I had not seen before. I have
always thought that there needed to be some kind of clearing house for chess
games where a globally unique id is assigned. In other discussions I suggested
that either FIDE (unlikely) or some other group, such as TWIC would be ideal
for this, so that when games are distributed they already have the id
incorporated. Once this is in place then a retrospective step would be to
assign such an id to historic games. I'd definitely support any steps towards
this such as a new PGN tag for global game id.
More important than a global id for games, in my humble opinion, would be
equivalent ids for events, sites and players. Although for the latter the FIDE
player id is a good start. From that you would be able to generate a single
scid name file that would be independent of database. With a standardised
player file you could easily download the FIDE ratings lists to have all the
ratings information at your fingertips.
If you could achieve a global database of events, sites, playersidentifying
unique games would also then become a lot easier.
> As I recall it, the issues were size and speed
With regard to the specific scid unique game id I was thinking more of a unique
game id within the context of ascid database rather than a global id.
With that in mind, if you continue to use the game number (the relative
position in the index file) for linking between the database files and use the
unique game number just as a reference field in the display or for exporting
games then I would have thought that speed would not be such an issue.
Even accessing a game by its unique game id would not be that bad provided that
you can guarantee that the game id would be always ascending with respect to
the game number.i.e.the number ascends as you step through the index file.
A simple binary search would find the game id relatively quickly. (To search
you just jump half
way through the index, depending on what you find, jump half way up or
down from there and so on until you find the id you are looking for.)For my 4
million game database, that would require accessing at most 23 index records to
find a given game id.
I think I am right in saying
that new games are always added to the end of the database in which case if you
always assign a sequentially ascending number for new games then this would
automatically guarantee you an ascending game id with respect to the game
number. For external consistency (so that exports match) you would have to
ensure than when a game is deleted the game id is never reused,
This could be achieved simply by storing the most recently assigned game id in
say the index header. When you add a new game increment the id.
If you merged databases then you would have to assign new game ids so that the
game id continues to ascend with respect to the game number.
This is similar to features that exist in conventional database systems e.g.
autoincrement in sqlite or identity in sybase.
That said, I would agree that such a unique game id is of limited value, it
would only be useful for referencing scid games from outside a scid database
e.g. exporting games.
If you wanted to have an id that transcended a scid database, such as a global
id, or even an id that you could assign yourself. For example if you were
working with a group and you wanted to identify your games consistently. You
would need a field whose value is not limited to ascending by game number.
Speed would most definitely be an issue in that case. You would have to
mitigate this by introducing some kind of indexing mechanism which I would
imagine would be a less than trivial change.
Regards,
Steve W
________________________________
From: Ben St-Pierre <benbon...@gmail.com>
To: Chris Bannister <cbannis...@slingshot.co.nz>
Cc: Scid Users List <scid-users@lists.sourceforge.net>
Sent: Monday, 18 February 2013, 22:52
Subject: Re: [Scid-users] Referencing a game in a scid database
> I suppose an internal scid unique number is out of the question because of
> database merges etc. ?
As I recall it, the issues were size and speed, coupled with the need
to create an online repository that could act as the equivalent of a
DOI or ISBN for chess games, at least for Scid's sake. See for
instance this discussion which recalled another one:
http://comments.gmane.org/gmane.games.board.chess.scid.user/4759
I suppose everything is possible, but I suppose this will have to wait for now.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
