Architecture: How do you store single pieces of information?

Question

I am building a solution in which each Site Collection represents a single contained unit. The members of that unit will be using SharePoint to track information that describes their unit at the root level, and then there will also be sub-sites to track their contacts, their documents and their meetings (one site for each).

What I am having trouble with is this: the information that describes their unit is not really "list"-worthy. I mean, I created a List that has placeholders for the unit's: title, address, telephone line, manager, business number, telephone line, etc. etc., but then its a list that necessarily only has one item in it - a unit can only have one title, one address, one manager, etc.

Is that the proper way to record that data though? I was thinking that I could create a big term store with Managed Metadata and then have one list and then I could add a list item for each Managed Metadata item ... that's the only other way I can think of it.

Also, in the documents site, there are some document types like "communications" or "contracts" which there will be lots of, and then there are other document types that are really one-offs, like "schematics" : all units will always have just one schematic ... Does that mean I should create a "schematics" library just to house that one document?

Answer 1

Refer to the SharePoint Guidance from patterns & practices

They have a section on configuration data which would apply, and part of that section includes storing configuration data in a list. The list implementation is much like a hashtable.

Answer 2

Your question is two-fold, so my answer will be.

Regarding storage of information, a list as you describe is the simplest and most flexible option. Other options are:

• Store as property bag items (requires a custom access UI, provides none of the advantages of a list such as versioning, approval, etc.)
• Store in a central configuration list (all Site ('units') pointing to the same 'Configuration Site')
• More involved, custom stores (DB, Service application..)

I'm not 100% I understand your Managed Metadata idea. What would your terms be? The name, address, etc.?

Your decision should consider: How are you accessing this information? (through code? through regular SharePoint list views?). What kind of security is required? What kind of access volume and caching is required? Do you need this information from outside SharePoint (web service, etc.)?

If the answer to all of those question is No or Nothing fancy, use a simple list.

Regarding one-off documents: Why not have a "Unit documents" library that allows multiple content types, and store those one-off documents there, along with those types that you have many of?