Target Table?

Mike88
Tera Contributor

Good afternoon all

We're in the process of importing none discoverable items into our CMDB. As part of this we're looking to bulk import a number of records from a sanitised DataSource.

We've been following the ServiceNow documentation (Data Sources | ServiceNow Developers) for context if needed but have come across a query in regards to Target Table when looking to create a new Transform Map

We understand that there is a main table (cmdb_ci) however should this be utilised as the Target Table or should we create a new Target Table?
We're not sure on best practise.

1 ACCEPTED SOLUTION

Mark Manders
Mega Patron

Well... every parrot is a bird and every bird is an animal, but not every animal is a bird and not every bird is a parrot...

 

You can put everything in the top class, but you will be missing class specific fields (or need to add fields for a specific class to the top class, making them available for all other classes as well.

There already are tables for servers, for switches and for routers available OOB, and that's also best practice. And the work is not that much, especially when you look at the upside of it: if you you have all animals in a big room, it's way harder to just get the parrots out, then if you already have them separated in their own room in a building full of birds.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

View solution in original post

5 REPLIES 5

Mark Manders
Mega Patron

What kind of items are they? CMDB_CI is the parent table of all CI-classes. Check if there already is a class you can put them in. If not, create a new class for them (extended from cmdb_ci) so you have them combined. Putting them into the cmdb_ci table can be done, but I wouldn't advise on it. It's just cleaner to put everything in the correct class.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

Hi Mark
There'll be a combination I suspect including Servers, Switches, Routers and potentially other items (we're still working through the details to see what records we've been given)
Our thoughts on best practice would have been to have multiple tables, one for each class but it would add a lot of additional work and wondered since CMDB_CI holds all data whether they could just go directly in.

Might be worth us creating a new separate table then by the sounds of it for this new datasource

Mark Manders
Mega Patron

Well... every parrot is a bird and every bird is an animal, but not every animal is a bird and not every bird is a parrot...

 

You can put everything in the top class, but you will be missing class specific fields (or need to add fields for a specific class to the top class, making them available for all other classes as well.

There already are tables for servers, for switches and for routers available OOB, and that's also best practice. And the work is not that much, especially when you look at the upside of it: if you you have all animals in a big room, it's way harder to just get the parrots out, then if you already have them separated in their own room in a building full of birds.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

Thanks Mark

I think I understand where you're coming from on this. 
While we could lump everything in a high level table such as CMDB_CI (for example) OOB provides more specific tables to use, and while these sub-tables can also contain more specific tables such as "Cisco switchs" as oppose to putting everything into just Switch [every Cisco switch is a switch but not every switch is a Sisco switch] best practise would be to put the items in the more accurate table as possible.