Author: Mark Boylan
Date: 16:41:42 03/03/06
Go up one level in this thread
A SQL solution for chess databases, engine user interfaces & book building programs would be ideal. There would be absolutely no need for any kind of hashing algorithm at that level because the database would handle it. A varchar(90) key (or whatever the maximum size of a fen is) is nothing for good database. In fact I've already started to design a SQL game/position database using fens (with a shorter surrogate key for relations) and I expect it to be very fast. But I see two problems. First is what database to use. I wouldn't want to use a database _server_ for a single user desktop application, but I guess you could. There are more than a few embedded databases for Java, and that's what I've cosen for my database application. But I wouldn't want any Java in my engine (just my preference). And using an embedded database (assuming that's the choice) kind of ties you to a language. I'm not sure what's available for other languages. I think there are xbase-like databases for C, but they aren't really SQL. In any case, the data files wouldn't be interchagable among the servers, embedded or otherwise. But, a book-building program could certainly export a file readable by any engine, regardless of language or platform. In the end, the engine will probably just hash the results of the query anyway, no?
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.