MySQL connectivity from Toolset makes its debut.

[chris421]

Oh the possibilities...

Wanted to bring up something else important.

My C skills are unfortunately pretty weak. For about a week now I've been trying to rewrite the current NWNX4 MySQL plug-in in which instead of writing dumb BLOBs of object GFFs to the database, I'd actually parse them out to XML and dump those as unique tables (not rows) themselves. Storing BLOBs = bad in a database, or so I'm told.

Got the bright idea to also create variant MySQL DLLs for every game OBJECT_TYPE, establishing a unique listener keyword in NWNX to direct storage of each object type to multiple logical databases (via multiple .INIs), i.e., if objecttype = PC, parse and store in "NWNX_PC" db…If objecttype=ITEM, parse and store in "NWNX_ITEM" db…etc. That would eliminate potential table name collisions/clutter and could open up distributed databases, not necessarily running on the same MySQL server.

BLOB objects in db makes retrieving everyday, mundane values a big pain and creates a terrible hit to the db since the whole unindexed BLOB gets read to find them.

If a NWNX4 GFFStream-to-XML-to-MySQL (and vice versa) parser became a reality, commonly tracked PW values like player gold, health, spells/feats, and loc would be readily available. So it would cut down on duplicate writes to the databases for the anti-cheat type values. Also by having PCs written to their own databases, the MySQL server could have a recurring job on that specific database to reBLOB and export as .BIC to disk, hence eliminating the duplicate write from the module heartbeat EXPORT players function.

[nosfe]

greeting chris,

Good I also thought several days of this problem of file [.BIC <-> XML <-> MySQL]; Knowing that I immediately eliminated the possibility of: [.BIC <-> MySQL (Blob] bus really too heavy.

On the other hand to use MySQL to store the name of file .BIC, its version, and dates it from the last modification, for then managing files .BIC in command line out from the play (example: backup with Cobian Backup).
For the important information storage that one wants in MySQL for a use out from the play, it is enough to pass from [.BIC <-> XML <-> MySQL] from important information;

The ideal it would be a library of functions NWNX which launches the serialisation/deserialisation of GFFStream towards or since MySQL, but not of all the fields which is in .BIC bus too much much are without utility.

[chris421]

Very true. A lot of extraneous info would end up being deBLOB'd and stored in MySQL for a player BIC that you might never have a use. Also there's the problem of the item objects on players--do you parse/store those too--in another db?

Still though, I have to believe disk IO is handled better by writes performed to MySQL vs. the in-game EXPORT char function. In fact you could make the default table creation type "MEMORY" and only commit to BIC when you needed (like when a player disconnects).

From a DBA point of view, the more intelligible info available on the players/items/objects, the easier they'd be to modify outside of the game mechanics via direct SQL queries. You could clean up inventories, fix skin properties, etc. without ever touching an 'onenter' script.

[nosfe]