Hi, I'll admit to being biast up front.  I think databases aren't that
interesting but often serve for managing art assets in modern games,
while scripting languages are about defining the proper problem domain
tools to make writing your game easier.

In this treatment, you're saying you want it to act like an extension
to the running game engine.  That's fine, but this doesn't address
*how* it got to the running state, what the bootstrapping or creation
process for a new (or loaded) game is like.  So it would seem you also
need an initilization subsystem or scripting language anyway.

A smartly done scripting system would handle all the dependancies
without intervention, at a resonably fine granularity.  There are lots
of ways to make module systems in Lua for example.  Perhaps it's
better to think about what information you need to access, not what
goes on under the hood to prepare it for you.  Game content code
shouldn't have to care.

I think the problem is deciding what issues you really want it to
address.

Because your game development is moving along too quickly and easily,
so you want to make more work for yourself?  Get real :)  Lua is a
brilliant, tiny powerhouse.

I'm working on a game language in Lua, but that's neither here nor
there.

Bzzzzt.  Thanks for playing.
What I think you mean to say, is that they're responsible for
providing access to representations of these game objects, while the
game code resides executable side.  You obviously don't have to use
the scripting language for game code or extensions if you don't want,
but that's an independant issue.

What form the game objects are described in (as self-building objects,
lookup tables, or generating functions) is the real problem you need
to solve, and you should definitely leave it open-ended so you can use
the best tool for each job.  Maybe monster stats should be tables, but
items should be clonable objects, and maps are configurable generation
procedures.  However it works, you can always just provide the
resulting objects (monsters, items, maps) to your game code through
well defined interfaces, but leave the definitions very flexible.
There's no reason to artificially limit your options.

I think a database should be treated as transparent, the game code
should act as if it's all loaded all the time and proceed as usual,
but the DB can do all the real work lazily.  That's kind of the point:
to not manage it manually.

Scripting language (like Lua) tend to be garbage-collecting, so you
can load whatever whenever and it will go away when it's no longer
needed.  If a script just offers similar access to objects, it's
trivial to discard anything that's no longer needed, or persist
objects that aren't needed currently.

The DB is simpler, in that you'd be able to use popular DB software to
handle the real work.  It lacks the power and flexibility of a
language like Lua however.

The scripting language takes more upfront work from a design
standpoint: deciding what your interfaces should be and how the system
is arranged.  But given the basics, there's just so much more work it
can do for you.

The bottom line is that C code is much more brittle than DBs or
scripts are, so you want to change your interfaces and data structures
in C as little as possible.  Whether you go with a DB or script
system, the key is to figure out what those interfaces need to do
first, then arrange to provide lots of resources and services to them
via the (DB or scripting) back-end.  To roughly quote a software
engineering course I had once, "The primary problem in designing
software objects and interfaces is that of assigning
responsibilities."

-Lucas