I have 3 content types (blogs, photos, videos) that all reference the same "topic" vocabulary.
When I add the term reference field to each content type I can either create a new field "field_blog_topic", "field_photo_topic" and "field_video_topic" for each of the types.
Or I could create a "field_topic" field for blogs and then use that existing field for the photo and video content types.
Would it make any practical difference?
Yes it would make sense to have only one field that you attach to multiple content types.
If you're using a MySQL backend then a table is created for every field you create in the UI (it's probably similar for other storage backends). If you create a single field and attach it to several different entity/bundle types then only a single table is created with the values for all entities. Fewer tables is definitely more desirable.
Also if you wanted to query the database for all nodes that are within a certain vocabulary (using EntityFieldQuery or even Views) then the query generated would have two less JOINs to make which is just much better for performance on the whole.
I think it was the intention of the developers that fields be used in this way, there's a complicated mechanism in place for managing different instances of fields and I don't think that logic would need to exist if they weren't supposed to be used like this.
I don't know if it's better or not, but I like to have 1 vocabulary per content type. That way, I can create 3 different term reference fields. I find it more logical, especially when it comes to creating taxonomy menus and using terms in views for each of my content types.
However, I don't know the effects on performance.
