How to design a parent-child relationship that includes child priority/order I am trying to design a table with a string column in SQLite3, I believe this is necessary to connect the tables parent to child, which represent entity types that are involved in a connection with a one-to-many (1:M) cardinality ratio. Te relevant data should be ordered by priority, something like this:

&quot;1|3|5|6&quot;

...this example contains these order values:

1, 3, 5, 6

Is it a good design strategy to create other two tables, one containing the order of the child and the other containing the child connection with the parent.id?
Current considerations
Here's a picture to clarify the situation, illustrating the design options I have evaluated so far:

Is there a better way to represent this kind of scenario?
If I understand your question correctly, your existing "parent" table has a column that contains a string that represents the ID values from a "child" table, and those ID values are in a meaningful order. The question, then, is how to move those parent-child relationship representations out of a string with meaningful order, and into a more normalised database design.

If this is the goal, then I suggest your second design (DB#2), with a minor change, might work best for you.

In summary, a single new table can represent the relationships between child and parent records, with one column for each of those foreign keys. (You already have this in the design). The order of those relationships can be represented in an additional column. (You already have this in the design). The only change I would make is to remove the ID (first) column - there is no need for it.

If a child may only be represented once in relationship with its parent, then make your primary key across (idParent, idChild). If a child can be represented many times against its parent (ie. because it can occupy multiple places in the ordering of the relationships), then make the primary key across all three columns (idParent, idChild, priority).

Per your design, the parent table can drop its obj#3 column (ie. the one that currently contains all the strings).

I see no reason to introduce an extra table to represent the ordering / priorities. 

This design allows for two levels in your hierarchy: parent and child. If you have a requirement for multiple levels (such as a person belongs to a department which belongs to an organisation), the question becomes more complex and there are some interesting articles out there on how to model such open-ended hierarchies. Otherwise, with the information presented, I recommend database #2 and, as mentioned, the first column is not required.