I would go for a direct reference to the parent (which would be called parentType, not parentTypeId). That leaves the choice whether or not you want to store references to the children as well. The answer is, it depends. If you need to access an object's children then it's better to add them. If you only need to go "up" to the parent then you don't need them.
One more advice: don't use a Type for the children, use a List<Type>. That way you can add children without any problems.
You should also take care of data consistency. If, for objects x and y, x.parentType == y, then y.childTypes.contains(x) should be true and vice versa. This means that:
1) If you create a Type with a parent in the constructor, that constructor should add this to the parent's children. This does mean that you may get threading issues as you are publishing the object before it's fully initialized.
2) If you provide an addChild method, this method should remove the given child from its current parent (if any) before adding it to the current object.
You didn't follow my advice about data consistency. Consider the following example:
I also dislike the name setChild for adding children.
Joined: Mar 12, 2010
Yes, I kept your data consistency thing in mind.
I'm using a DAO for selecting types, These types will be selected from database.
The DAO will ensure that selected type will be consistent and will have proper parent child relationship. And still working on that