I don't think you really need to store them in a database, but rather design them in a smart way. This will at least reduce the amount of spells you have. You can obviously store them in a database, but how depends also on what the spells are based on (player level, player selection, item choice)

You don't need to store every single variation of a spell. In the end, it's nothing more than a number that does something (healing or damage) with 0 or more side effects (like a stun) and perhaps a timer, or whatever you want a certain spell to have. This, same as above, also depends on what affects your spells.

I guess it also depends a bit on how big the game is, or rather, how many different kind of spells you're going to have. I would personally think it's more of a hybrid between storing base spells in some way (doesn't need to be a database per se, perhaps some XML file, I don't know) where different factors (player level, stats, etc) are a modifier for the final outcome.

I guess it can also be achieved with scripting the spells (so the designers don't have to dive in the actual code).

In the end it probably also depends a bit on how many spells you have though. Maybe setting up a scripting language or parsing through some database/file isn't worth the effort if you're going to have 5 base spells with level based variations that don't need to be stored.

Others can probably shed some more light on it, but this should at least give you something to think about. :)

A proper relational database is overkill -- I suppose if you were using a database heavily for other things it would make sense to consolidate storage systems, but that's certainly not a dependency you want to take just for this.

If it were me, I'd design my spells and other effects as a component system, and then have a set of factories to build them from a declarative sort of description; or, tie that into a scripting language like Lua to define the languages.

From the perspective of a client/server I would consider restricting the details of the spell effects to the server side only, and only propagate data necessary for visualization to the clients. This would allow you to create effects and spells and such that don't need to be communicated to the clients, potentially even while the game is still running. The clients just need to download the visual aspects of the effects such as animations, textures, particle systems, hud icons, and many of those can be shared or mixed and matched between skills. The client need not even have any knowledge of the spell system in general. Maybe the client has only the capability to communicate targeting information to the server and activate spells by an id value, and the server kicks communicates streams of visualization instructions at entity positions to relevant players around those locations in a generic way that has no dependency on the spell system.

Alternately, is your question more about how to structure the definition of a spell effect?