we have adopted the approach to use the "Related CI's" with a relationship type defined.
We keep the parent-child relationships for those relations that the CI needs in order to operate (i.e. the parent cannot operate without the child CI) e.g. Parent=Server Child=Oerating System / Hard Drive
We use the "Related CI's" where the parent can operate without the child e.g. servers and switches or switches and routers. The server can operate without the switch - you can turn it on and run applications, It may not be able to communicate with anything else if the connection to the switch is lost but it the server still working. it also allows you to create reverse relationships.
We customised the Relationship types a fair bit and use "Uses" and "Depends on" etc carefully. eg. App1 might "use" App2 but if the other App2 is down App1 is still available (maybe a little degraded?). But if App3 "Depends" on App2 then when App2 is down then App3 is unavailable.
A server would "Depend on" the network switch it connects to (unless you have LAN redundancy in which case "Connects to" would suffice).
Certainly, if you think you might try and use the CMDB to provide availability reports then taking care with relationship types might be worthwhile.
We do use Parent and Child but usually for things like a Cluster - the Virtual node is the Parent and the Nodes the Children.
Or a Business System is a Parent with The Underlying apps as Children?
But what we do isn't necessarily correct but maybe these ideas help?