Scid Databases consist of three files - an index file (file suffix .si4), a name file (.sn4) and a game file (.sg4).
Scid only allocates three bytes for some data fields. This means si4's maximum number of games is 16,777,214.
Additionally, maximum size for a single game is 131,072 bytes.
The Index File contains a description for the database and a small fixed-size entry for each game. Each game entry includes essential information such as the result, date, player/event/site name IDs (the actual names are in the Name File), and some redundant but useful information that is used to speed up searches (see fast searches for more information).
Contains all Player, Event, Site and Round names used in the database. Each name is stored only once even if it occurs in many games, and there is a database restriction on the number of unique names. The limits are -
This file contains the actual moves, variations and comments of each game.
The move encoding format is very compact: most moves take only a single byte (8 bits)! This is done by storing the piece to move in 4 bits (2^4 = 16 pieces) and the move direction in another 4 bits. Only Queen diagonal moves cannot be stored in this small space. This compactness is the reason Scid does not support chess variants.
When a game is *replaced* a new version is - in fact - created, so wasted space does accumulate over time. The database may be restored to its minimal size by compaction.
An EPD file (.epd) contains a number of chess positions, each with a text comment. The EPD file format is described in the PGN Standard.
An email (.sems) file for a database stores details of the opponents you send email messages to.
A SearchOptions (.sso) file contains Scid header or material/pattern search settings.
The Index File stores some redundant but useful information about each game to speed up position or material searches.
For example, the material of the final position is stored. If you search for rook and pawn endings, then all games that end with a queen, bishop or knight on the board (and have no pawn promotions) will be quickly skipped over.
Another useful piece of information stored is the order in which pawns leave their home squares (by moving, or by being captured). This is used to speed up tree or exact position searches, especially for opening positions. For example, when searching for the starting position of the French Defence (1.e4 e6), every game starts with 1.e4 c5, or 1.d4, etc, will be skipped, but games starting with 1.e4 e5 will still need to be searched.