Below I attached diagram which corresponds to part of my database :

enter image description here

My questions:

  1. In your opininon Do I have to divide ServiceInsance and ConfServiceInstance ? I did it like that because I would like to have separated IDs and Configuration columns.
  2. What do you think about name of these tables ? I mean Is it worth to have Dict and Conf in table names ?
  3. Is it a problem that PK does not corespond to table name by convention: TableName + ID in Conf and Dict tables ?
  4. Is it a better idea to create schemas conf and dict maybe ?

1 Answer 1


I would have 3 tables "Service", "ServiceInstance", and "Node". 1-1 relationships are generally best collapsed into a single table, and there's no reason to decorate your lookup tables with a a prefix.

  • This. By definition the non-key columns in a table are describing the entity - e.g. the ServiceInstance - so you usually don't need a prefix to say it's 'configuration'. In the database it's not a Dictionary, it's a table, which by definition stores multiple rows of that entity. You also don't want to name your tables based on your app's data structure implementation, e.g. you might change that sometime. Usually if you model the tables based on the real-world entities things work out well: hence Service, ServiceInstance and Node.
    – Rory
    Jan 5 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.