Not necessarily networked – it could all be on one host – but yes it is assuming a separate process, and not something like SQLite.


I'm not sure why a flat file system couldn't have its own indexing to accomplish the same goal…? At one point or another the DBMS has to inspect the records, just like the flat file system. And there's no guarantee that the index it builds will be on type "long_sword" – chances are it'll be on something that's more like a primary key or a very common search column.


But now we have to establish if we're talking about DBMSs that are in their own process or not, because it really starts to matter.


Well, frankly, I've yet to see a very large world run on a Ruby codebase. I'm not saying it can't/won't happen, I'm just saying that I don't have evidence to suggest that it actually works beyond toy worlds. Furthermore, accessing a structure field in e.g. Lua is a whole lot cheaper than talking to a separate process.


Every time this is brought up, the underlying assumption is that the flat file system does nothing with indexing or other memory representation. That assumption really has to go away since it is not fair at all. You can do whatever kind of indexing you want with flat files. You just have to implement it yourself. <insert my previous summary statement here>

Actually, you can. It's up to you (as the schema designer) to determine which things are indexed. If you expect you're going to be asking for reports on objects of type ITEM_WEAPON and with "sword" in their names, you'd want to index the type field and the "name" field. That shouldn't be a big performance hit unless you have code that creates new objects on the fly all the time. Of course, you'll want instances stored in a seperate table with just the vnum and stats, since you don't want to update a string instance every time you clone a new sword.

You can certainly build indexing into a flat file system, but that won't get you anywhere with ad-hoc queries. Of course, that may not matter, and you may be fine with writing report scripts and running them as batches… nothing wrong with that.

Sure; I was referring to the claims made about automatic index generation. I think that creating an index based on a relatively infrequent report is probably not a great idea; it's much better to have your index over things that happen really often. (EDIT: because if you give it "hints", it might take them too literally and not look as much for other indexing – depends on the DBMS implementation obviously)

David, I think we're both agreeing, but just arguing on two facets of the same claims. I'm talking about what is possible, where-as you seem to be making the assumption that any DBMS is going to have the same pros and cons as MySQL/Oracle/SQLServer/etc.

By the time you start creating your own custom indexes for a custom flat file approach, the grand sum of what you've accomplished is a slower, buggier, proprietary reimplementation of BDB. It's just not worth the effort. If you need to index data, you're pretty much always better off using an existing DB API – be it a networked/server-oriented RDBMS or just a library – rather than trying to do it all yourself and hoping you can do it as well as the pros.

Well, that's why this conversation is very unspecified. Asking "what is a DB's advantage over a flat file" is more or less impossible to answer unless you get much more specific about what your DBMS is actually implementing. Some databases are "dumb" and don't do any of this fancy indexing on the fly that the enterprise-level databases will do. Given the context of MUDs here, I don't think it's appropriate to tout DB advantages that are only relevant for rather specific systems. (Not saying that anybody has done that, by the way.)

And I agree that using a library is (almost always) a better approach. I'm still not convinced that fancy data indexing is necessarily useful, though.