Design your system according to SharePoint boundaries and limits

When designing the architecture of a SharePoint solution it is fairly important to design so that it will not exceed the limits listed by Microsoft in SharePoint Server 2010 capacity management: Software boundaries and limits.

Best practices for using fine grained permissions in SharePoint 2010

Error! "You cannot break inheritance for this item because there are too many items with unique permissions in this list".
This may be the error you get when trying to add a new item to a list with unique permissions on the items.

Microsofts best practices on that one:

Best practices:

• Only set unique scopes on parent objects such as folders.

• Do not create a system with many uniquely permissioned objects below an object that has many scopes.

If your business requires that you more than 50,000 uniquely permissioned items in a list or document library, then you must move some items to a different list or document library. 

The above is a quote from Microsoft's "Best practices for using fine-grained permissions": http://technet.microsoft.com/en-us/library/gg128955.aspx

My advice: Instead of making one list with broken permissions for n number of groups. Can you in your solution make a design where you make n number of lists each with only permissions broken on list level. Items will inherit from the list then.

How to avoid it in future systems

SharePoint is often used in large companies with a lot of employees/users, generating and sharing a huge amout of data. But never may all employees see all data.
In SharePoint you can control exactly who can see the data by setting permissions on secureable objects (site, lists, list items etc.). You can be tempted to break permission inheritance as it then is easier to make a system architecture that fits with your companies business logic with regard to permissions.

However be warned! This is NOT the best practice!
Try to make a design that do not break inheritance unless it is really necessary.
If you do not design your system wisely you will reach the limits when your system is in use and may be critical for the daily operation. However you will be forced to do a long and painful redesign of your system. In all this time it will not be up and running!

I lately ran in to a problem where I was dealing with a solution with a list containing 50,000 items all with unique permissions. This hit the boundary of what is supported. This called for a redesign. A perfect one! But fast!

To save you self the trouble read the best practices from Microsoft regarding fine grained permissions in the document here: http://technet.microsoft.com/en-us/library/gg128955.aspx

How to restrict the user only see list items created by him/her

This can be achieved in a couple of ways including coding an eventreceiver listening on ItemAdding or a workflow when items are added.

However the easiest would probably be to modify the default view and add the following filter:

The users should not have permissions to change the view though!