With this in mind what would be the attributes of a platform. Here is an example.
Serial # = indentifier key (Parent) Vendor Family Model Location Warranty Maint Disk CPU MEM NIC Fiber Power Recepticles
Now a Ci withing this platform Ci. Keep in mind that every server is virtual.
Server Attributes (CHILD) Host Name = Primary key Identifier v-cpu v-MEM v-Nic v-fiver v-Disk IP DNS
Now does anyone see any attributes that I'm not seeing?
A platform could come with MANY NIC cards. What is the best way to solve this. Above I have NIC as an attribute but there could be many NIC's. NIC's come with their own identifier which is a MAC address. How about CPU since there could be more than one CPU in a HW Platform.
I'm starting a CMDB from scratch and decided to start with the HW Platform.
I would not define ANY attribute for a CI unless I knew exactly how the staff would be using it. If nobody is using it, I would not put it in the CMDB. In other words, make your use cases first; define your CMDB structure afterwards.
This strategy will give you the answer to the question about NICs. But basically you only have five options:
1) create as many fields as you think you might need for NICs; 2) create a relation between individual NICs and the platforms where they are installed ("platform" could mean whatever you need - a physical machine, a virtual machine, a logical network interface, or whatever). That relationship is likely to be a parent-child, but it could be another type. 3) create a relation between a generic NIC (a non-unique CI) and the platform - which might be fine if you do not manage NICs individually. 4) just have one field for NICs, and describe in free text whatever you what to say about them. 5) put any information you need about NICs in a general description field.
So there are a lot of possibilities, and any one of them may be the right one for your organization, depending on what you really need to do, what you are really managing.
As far as I know, the only real difference between Parent - Child and any other type of CI relation is that OVSD prevents you from creating more parent-child relations than the max. number of installations allowed for the child CI. This is irrelevant for physical and virtual servers, so I think you can do whatever you want.
We reserve the parent-child relation for cases where the child cannot function if the parent does not. If this is also your rule, than parent-child might be a good bet for you.
However, it might be confusing for users to have part of the relations in one list, and another part in another list.