Microsoft has some excellent documentation on InfoPath development for SharePoint, no need to repeat it here, the link is:
One of the development best practices that I would like to talk about however is the concept of schema first InfoPath development.
If you have come from a .net development background as I have, the normal process for creating a web form is to first drag and drop controls on to the form, do some formatting and look and feel changes, then work through and name each control so that it can be correctly bound to the data layer.
The same process can be used in InfoPath, and it is certainly not the wrong way. However, it may mean that, especially in the case where you have non flat data schemas associated with your form, that you have to revisit each control you added in the form to define both their appropriate binding names and their relationships.
Why not create the schema first? You can add the fields to InfoPath one by one in the right field window by right clicking and choosing add, you can group fields together related by function, and you can create one to many relationship definitions. Define your fields in Camel Case (FirstName, LastName).
Once you have finished defining the schema, you can drag and drop fields onto the form as you would from the top toolbar. If you have correctly used Camel Case, InfoPath will insert spaces correctly in the field descriptors. The advantage of this approach is:
1. By defining the data schema first, you are getting a deep understanding of the underlying data set first, negating complicated changes that may have to occur if you have created the form and all of its fields first and then perform changes necessary to match the data schema.
2. You do not have to go back and rename fields from the generic SharePoint field names, creates a streamlined process.
3. You avoid the generic flat data schema automatically created when you use the original method of form field data population.