On Thu, Aug 4, 2016 at 5:05 PM, Kevin O'Gorman <kevinogorm...@gmail.com> wrote:
> 3. Positions are 64 bytes always, so your size guesses are right. They are > in no particular order. I like the suggestion of a separate position > table, because they're going to appear in multiple qmove records, with an > average of about 3 or 4 appearances I think. Maybe more. > 3x or 4x duplication doesn't sound like a lot. What you'd gain in the moves table, you'd lose having to join to the positions table I suspect. Higher level duplicates, maybe. 64-bytes always? Is that a human readable string, or some 'code' in hexadecimal? If the latter, use a blob, which requires only 32-bytes to store the same info. You can use the blob literal notation x'abcdef01' (that's a 4-bytes blob). Finally, note that if your program writes a huge text file with all your values, that you .import into sqlite3 as you showed, you're IMHO wasting time, since you can't use prepared statements and binds, and you also force SQLite's SQL parser to parse a huge amount of text. By embedding SQLite into your generator program, you remove all parsing except for a trivial "insert into qmoves values (:1, :2, ...)", and all the rest is sqlite_bind*() and co. calls. (and if blob situation for positions, then you can bind the 32-bytes blob directly, no need to convert/parse to/from hex). My $0.02. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
