Possible new aproach to world building

[John Adams]

I should have asked initially, but where do you see a deficiency with the current indexing? I mean, the PKs shouldn't matter as much as the FKs - or what IDs tie the whole thing together. The database does show it's age, with no constraints and dead data (that many have offered to clean up).

The npc_types table is laid out exactly as you described, with Zone 1 mobs being numbered 1000-1999, zone 2 being 2000-2999, etc. You can't really bind many of the other tables to "zones" unless the range is increased (I guess), because there could be more spawn groups, spawns, loot drops etc.

I doubt SQL cares what your PK is, but I believe our shared memory modules do. If you read in IDs 1-100,000, it takes up 'x' amount of memory. If you start making up new IDs and now have to read in ID 1-1,000,000, that's a helluva lot more memory (if we pad that empty space, which I think we do from an earlier discussion).

Anyway, always a good idea to have a solid database. I guess I forgive 'eq' because it is so old, before MySQL became a real database solution

[EmanonCow]

How practical would splitting the IDs be?

Ie, items being identified by a (zone, ID) pair, with (0, ID) being "uncatagorized"?

This would require changes to the code base (so it identifies things as (zone, ID) pairs rather than just IDs), but the existing data wouldn't have to be changed.

Then one could start moving things out of the "uncatagorized" zone and into a (zone, ID) pair space -- it would allow one to create portable zone-data files, but not require you to, so existing data would work fine.

[Dralanna]

items being identified by a (zone, ID) pair, with (0, ID) being "uncatagorized"?

The problem is many items appear in multiple zones.

[ArChron]

Originally Posted by John Adams

I doubt SQL cares what your PK is, but I believe our shared memory modules do. If you read in IDs 1-100,000, it takes up 'x' amount of memory. If you start making up new IDs and now have to read in ID 1-1,000,000, that's a helluva lot more memory (if we pad that empty space, which I think we do from an earlier discussion).

I believe that the IDs are read and stored in a 1 to <maxid> space... there are other programming models for handling what could be a "sparse matrix/list" if the range of values for IDs were spread out to accomodate a new identification scheme. I think that (EMU code change) is far less of an issue than just managing the data transformations that would have to happen in the SQL database...