Easy way to design SharePoint data structure

A couple of weeks ago, in a business requirement analysis meeting, all of sudden, I realized that the whole SharePoint site collection is a huge xml file with security control.  Root site is the root node; sub sites, lists (libraries) are nodes with descendants, and items (files) are actually leaf nodes; meta data are attributes!  So, we only need to consider factors below in the data structure design.

1. Location

The reason that we put data into SharePoint (or Shared folders on file server), is because we what to share the information.   (This is quite obvious, or else we would save the file to our local computer.)
So, whom do you want to share the data with?   If you want to share it with a department, put the data (or file) into that department's site; if you want to share it with a small team, put the data into that team's site. Easy.

2. Security

Once you decided the location of the data, let's say, a list in a sub site (for a team), who should get what kind of access rights over this file?  One principle: keep unique permissions minimum, and always grant rights to user group (instead of specific person).

3. Meta data

In traditional shared drive, normally, we have to create many layers of sub folder to represent "meta data"; or, we have to put them into file name.   That's why we often see some files with 200 characters name in shared folder. We cannot sort by one of the "meta data" (which is stored in file name or sub folder name), cannot apply "filter", and normally cannot assign multi-value meta data to a file.  SharePoint fixed this issue through "columns" (fields).  We can add all necessary columns to a list (library), such as "start date", "end date", "owner", "scope", etc.   Only one pitfall: sub folders.  It's easy to understand: we cannot put the same item (file) into more than one folder.   Since SharePoint site collection is a huge XML file, we definitely don't want to put sub folders into leaf node, which will make the whole XML file messy and out of control.

That's it.

Based on these understanding, "data migration" from traditional file server to SharePoint is almost impossible. We have to build proper data structure in a SharePoint site collection, then give users sufficient training, then ask them to do it manually.   It's painful.  Many clients don't want to go through this pain, then end up with a new messy data repository which is even worse than the previous file server.  Rubbish in, rubbish out.

No pain, no gain.    :-)


(Please let me know you have different thoughts.  Any comments welcome.)