2008/6/24 Alexander Wagner <[EMAIL PROTECTED]>:
>
> Hi!
>
> 2008/6/24 Alexander Wagner <[EMAIL PROTECTED] <mailto:
>> [EMAIL PROTECTED]>>:
>>
>> CentriScid_ID 123456
>> CentriScid_Version 10
>> CentriScid_TacticPly 23
>> CentriScid_TacticSolution Nxf3 ...
>> CentriScid_OpeningBlunder 7
>> CentriScid_OpeningBlunderSideToMove black
>>
>>
>> This has a major disadvantage. How do I cite that game? By
>> just printing out the whole block? Consider I'd want to show
>> the game easily with a single tag you could do something
>> like
>>
>> $ scid CentriScid -search CentriScid:12-123456
>>
>>
>> The CentriScid_ID tag is a key. It is sufficient to designate a game.
>>
>
> Nope.
>
> The version n+1 superseedes the previous one. If you use (version, Id)
>> tuple as a key you consider several distinct games, from a DB point of view.
>>
>
> Exactly. This implies versioning support. One idea is to
> even have all versions in one DB and create a release by
> means of a suitable select/view.
It would be awfully inefficient. I don't see the point in having N versions
of a game. You would need proper indexes. And moreover if you have 3 M
games, with several versions for each, searches will get slower as you add
versions.
>
>
> Searching for additional PGN tags is terribly slow. I do
>> this all the time when I add [Ref]-tags to my larger DB to
>> crosscheck that I did not miss to flag the games in question
>> correctly and it is plain PITA. Sorry. Just searching the DB
>> takes about half an hour to come to the result list. :(
>>
>> I was not aware of this. Do you have enough RAM related to the size of the
>> base ?
>>
>
> Well, I think that about 1.5G are enough, the base in
> question is about 700M or 3.5Mio games. Searching via flags
> is very fast, searching by player names etc is very fast.
> Searching by additional header tags is slow as they are not
> indexed.
>
I agree for a 3 M games DB. But for smaller dedicated bases, tags are good
enough. For example I just took a 300.000 games DB and added a tag (Medal ->
Gold) every 100 games (not by hand !). The search as plain PGN text takes
only 36 sec on my laptop. So one solution is to have a big ref DB and
specialized DB for openings, tactics, endings, etc.
Using Scid, if I had a 10.000 games DB for each of those fields :
- tactics,
- my favorite openings explained with traps,
- endings I should know,
I would be very happy. And even such a goal seems very ambitious. So why try
to get something scalable to 3 M games DB ?
In annotation feature I added an opening blunder detection. Given the time
taken to go through games, I never exceeded 1000 games checked with this. Of
course you would not use this on a big Ref DB, but on a small DB where one
opening line is pre-selected (say 20000 games). And the games flagged with
"opening blunder" are rare.
The real concern here is to have a Ref DB (big) and several dedicated DBs.
So some games are duplicated, with the same CentriScid_ID. Not an ideal
solution, but I don't want to set a costly high level solution if there is
no real matter behind it : Scid has no Ref DB on its own, no opening DB, the
only books provided are certainly not the best (I know what I am talking
about ;- ) ) and the only "tactics" bases are those I auto-generated (just
mate in N moves), hence their poor quality.
So I don't want to build a car if nobody has gasoline.
>
> My main concern here is that I'd like to have something
>> easy to implement, and to add a metadata file along with
>> the 3 existing files is not a piece of cake.
>>
>
> No, no, actually I'd like to place the CentriScid-ID as one
> PGN Header tag. I suggested to set for a game in question
>
> [CmailGameName "CentriScid:12-123456"]
>
> (CmailGameName just as it is already used for a UID, but
> this is up to discussion.)
>
> I'd just prefer to add just _one_ line there and not
> several. This eases up entry among other features (see
> below). I'd prefer to have a generic ID-field and not a
> specific one, as this could be indexed. E.g. if you name it
> "CentriScidID" it is only usable in CentriScid as otherwise
> it is not unique anymore. Therefore the DB-name that it
> refers to has to be part of the ID. If you drop the version
> from the UID you can not handle versioning with it anymore,
> IMHO this is desirable. And well, one unique number has to
> be there.
>
I did not get where you put special markers like "rook ending at move 34",
"tactical shot : xray" ?
Pascal
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
