Norman,

is the data you wish to store able to be stored in a string field, or is it some type of binary or image data that you are wanting to store?  The reason I ask is because if it's just a bunch of properties for an object you are creating, you could just serialize your object and store the data in a single setting value.  Could you give us a little more detail about what you are trying to accomplish specifically?

Norman,

You're right, there is a limit to what can be stored for a setting.  Each setting value is NVARCHAR (2000) so it can store up to 2000 characters before truncation occurs (and the name setting is limited to 50 characters).

What I've done in the past when I have had similar requirements as you do is to create my own settings table for my modules.  In that regard I can specifically create any data types and lengths that I need; some cases I use TEXT fields (which you can't edit directly in the database table anyway), other cases I use numeric types, etc.  The caveat is that I can't use the ModuleSettings controller for it, of course, but have to write my own code and stored procs to handle it.  On that same token, when I've done the approach mentioned I tend to have my Settings control completely separate from the standard module settings control (instead of using the key "Settings" I have my own) because those pages tend to get complicated.

Additionally -- yes, storing your data as a string when the ID is related to another object in your database would affect referential integrity.  That is one of the sacrifices you might make in lieu of ease and less code.  There are always architectual decisions to be made regarding your modules, that is definitely one of them.

Hope that answers your questions?