If two tables have a one-to-one relationship, they can generally be combined into a single table unless there is a good reason not to do that. (Usually for security reasons, for example, an employee and that employee's salary, where you do not want to expose the salary table). I don't think that PowerApps will create such a relationship for you, However, if you have a common field in both entities, like the table ID, you can do it manually using a lookup in a gallery and a Dropdown control in a form.
I am more into model-driven apps. I created a one to many relationship and in the parent entity lookup, I filtered for the non-related records (yet) to be available for a new relationship. That is fine.
The concern I have is that a user can still add more childs to the parent, from the form of child, related. I know i can hide the child entity from there but is it still a good data design?
Why not just combine the fields in the two entities into a single entity but create custom forms and views from that entity that only display the fields that you want. That way you won't be creating multiple child records for each parent.
I have a PROJECT Entity, and a PROJECT-QUOTATION Entity that against each PROJECT that we submit a proposal, a PROJECT-QUOTATION is booked. This is one to one relationship, and QUOTATION ENTITY is meant only to give this relationship, no other data inside.
Then there is the real QUOTATION entity that is a child to PROJECT-QUOTATION, in which there could be many QUOTATIONS for a PROJECT-QUOTATION (for a PROJECT)
Here is an example:
E191-001J - Status Submitted
E191-002J - Status No Quotation
E191-003J - Status Submitted
For the Projects in line 1 and 3, they should have a PROJECT QUOTATION
Q19-001 - E191-001J
Q19-002 - E191-003J
Q19-003 - waiting to be booked
in the QUOTATION entity you will then find
Q19-001-1.0 first quotation rev 0 for Project E191-001J [which is actually a child for Q19-001]
Q19-001-2.0 second quotation rev 0 for Project E191-001J [which is actually a child for Q19-001]
Q19-001-1.1 first quotation rev 1 for Project E191-001J [which is actually a child for Q19-001]
Q19-002-1.0 first quotation rev 0 for Project E191-003J [which is actually a child for Q19-002]
what is good and bad in this design? what are the recommendations?
You cannot have a pure one-to-one relationship, so with a one-to-many there is always the possibility of creating multiple child records (though you could create a plugin, or workflow with flag fields) to prevent this.
As per the other posts, I'd suggest combining the PROJECT and PROJECT-QUOTATION entities to avoid the need for a relationship; you can use field-level security if you need detailed control over permissions down to the field level