when i was thinking.. a idea.
 

i was thinking about the problems with eq admin tools and spawning because of the huge list of npcs. how about this..

split up spawns data database to spawn(shortzonename)

ie: spawnsqeynos spawnkarana etc

it will make exporting single zones much easier.

i think only factions table needs to be left together because theres lot of spawn across zones that has same faction type.

Spawn2 could be split by zone I guess, but the rest would need to stay the same... Then again, you would be refering to different tables for each zone, I am not sure if that works well for programing.

its only for spawns however. not items zonelines etc.

im sure zone server can look at database named spawn(shortname zone) it actally needs like only change of name to look at, with variable that holds the value of current shortname of zone.

I haven't used too many of the admin tools (for presicely the reason you describe), but I don't think that splitting up the database into more tables would really help matters. The DB should be able to handle 10,000 rows as easily as 100. Hell, it _should_ be able to handle 10,000,000 rows just as well, but I don't know how well mysql would do at that (though I've read reports that it does hold up pretty well).

What really needs to be done is that the admin tools need to create better queries. Have the admin tool query for spawns only in EC or gfay, etc, and only work with those. Or have it query as needed. For example, get the IDs of all the items (to konw how many there are and what their IDs are) in one query intially, but don't get the full info until it needs to be displayed on the screen. The key is to grab data in short, manageable chunks.

Another approach would be to have a background thread manage all the data retrieval. So when the interface needs data, it sends a request for data to that thread and then goes back to the user. The background thread executes the query against the DB and populates the interface as the data comes back from the DB.

Now maybe some of the tools use approaches like these (or other ideas).

In any case, it's not the amount of data in each table that's the problem. The problem is creating queries that don't take too long to execute (in terms of the database generating the data, the time to transfer the data from the DB to the admin tool (like over a network) and most importantly the time to process the data). Shorter queries and more dynamic loading would probably greatly improve performance.

Also, having a table for everything is VERY VERY bad practice, and IS frowned apon in the coding standards area. I mean you'd have 150 tables just for spawns, and that is rediculous. If you want spawns for just one zone you do a WHERE case to the statement like we do in the emu.

Now for the admin tools, they will always be slow. And it's not because they don't use threading, itbecause the myODBC and delphi mysql modules are VERY slow themselves. And there is nothing to fix that. To my knowledge the fastest forms of mysql handling are C++ (like EQEmu), and webscript (PHP, PERL..)