Wow, it's almost like we have professional seasoned game-design types here and not just a buncha teenaged kids who are only after the latest kewl frag-fest. I once again wish death on the Gamedev Lounge forum :)Two other facets of the design that I need to detail that will certainly affect the process. . .
Fact one
Perfect scores in Shi Sen are rather commonplace. Unlike something like Voracity (where perfect scores are nigh-impossible), it's not all that difficult to "beat the game". Much like the standard Mahjongg/Taipei/Shanghai game, it is possible to make a configuration of tiles that's impossible to beat, such a configuration doesn't happen very often with a random tile placement.
In casual play (i.e. without a helper-bot), I'd guess that the odds of me being able to get a board down to zero tiles is about 1/6. Only a bit more difficult than the "classic" Mahjongg puzzles.
Hence, I don't think that having a separate table of perfect scores will work. Even Klondike (aka Windows Solitaire) wouldn't need such a "ring of honor", and the odds for beating that are about 1/20. It's either all or none with the perfect scores.
However, I'm now leaning towards only storing perfect scores from a usability standpoint. Much like Klondike, with a little play you (or at least I) take a "win-lose" attitude. In Klondike, if you place all of the cards and get the little bouncy animation, you win. Anything else is a loss, no matter what the little score display in the corner says.
I think that users will roll their eyes if the system brings up a "Good job, enter your name in the high score table!" if they're stuck with 98 tiles remaining on the board. That'd be like Windows Solitaire saying "You can't place any more cards. Enter your name for the high score table."
Fact Two
This is a technical limitation. I'm using Flash for the games and a tool called Zinc to make the Flash apps look and act like first-class apps. One thing Zinc provides is a way for Flash apps to open and save files (like high score tables) to the user's hard drive. Flash itself has no file functionality for obvious reasons (or if it's not so obvious, it's so I can't write a web page ad that overwrites files in your Windows directory if you don't want to buy my V1aGr4 knockoff).
That being said, Zinc's file save-n-load is rudimentary.
Really rudimentary.
Specifically, two functions. . .
mdm.FileSystem.saveFile(filePath:String, dataToSave:String):Void
and
mdm.FileSystem.loadFile(filePath:String):String
So basically if I call loadFile, it stuffs the entire contents of a file into a String that I can then parse and massage at my leisure. Once I've made any changes to that string, I can write the whole goldurned thing back out.
And that's pretty expensive if that file wants to get big, both in memory and disk access. Zinc does have database access, but that's even more unruly, as it requires an ADO, MS Access, or MySQL data source, which is way outta line for a casual game.
A little no-install-required database like SQLite would solve that problem in a jiffy, but that'd require me to write some glue-code in C to bridge between SQLite's sophisticated functions and Zinc's rudimentary methods for talking to DLL's.
And that'd stretch the schedule. Especially since I haven't written a line of C in years.
Compromises compromises.
If the file is definately too big to handle in a reasonable about of time, you might consider breaking it down into more manageable chunks.
If 100,000 games were more manageable, have separate files for games 0-99,999, 100,000-199,999 etc. 10 separate files could contain all 1,000,000 game records.
Then you'd just need to load the file that the current game would be found in.