I have a simple requirement of creating a schema for resources. One way to do is add fields for multivalue key value pair and we can add as many as key value pairs in the component. But only thing which we need to keep in mind is that we want to restrict content authors to not to change any "key" in this component. The other approach is to add as many as "text" fields in the schema for different resources for example: text field with description "Please enter text for find" etc. In this case content author has to just put the text which he wants to enter. This way author wont be able to touch the "key", only has to provide "value". Which approach should I follow. Is it ok to put many fields in schema? is there any way to restrict user to not to change anything in "key" field?
There isn't really anything wrong with a Schema with lots of fields, other than the fact that editing the Component based on it will not be a pleasant task. Loading will be slower with a large number of fields, but if you need to scroll several page lengths to get to the field you want to edit, well you can see that UX wise this is not preferred.
As the others mentioned, you have the option there to separate it into multiple Schemas, so that everything remains manageable.
If you expect the number of fields to change in the future, then I would opt for an embedded Schema with a Key and Value field. To prevent the normal editors from changing the keys, you can use a UI extension to lock down the key fields for certain groups of users. An example of that is given in the Field Behavior Injection project.
The is an excellent discussion surrounding this subject on John Winter's Creating translatable website labels in SDL Tridion post over on Tridion Developer.
There are lots of interesting opinions surrounding the pros & cons of using key/value pairs against having set fields within a Schema, and Alvin also mentions an idea the he submitted to the Tridion Ideas site.
In addition to this discussion, you may want to consider splitting your resources out in to multiple Components (and updating the templating code to reference these), rather than having lots of Fields. That way, you can group related labels/resources together (e.g. Form labels, search labels, etc.) and you will also be able to control the security on these Components separately, if needed.
For one implementation I created separate fields for each label so that the key (field name) could not be changed across the BluePrint. On other implementations this was not important so an embeddable schema with key-value fields was used. There is no right or wrong here. It depends on your CMS users.