I agree with what Sandro said, for his particular situation. It is interesting that you always analyze the scenario that you are developing. For example, in your case it is interesting to make the 1: 1 relationship in the same table because there is little information, but let's imagine a different scenario:
You are developing for example a vehicle rental application, so you have a Rent table for example:
(Tabela - Aluguel)
id(PK)
idCarro(FK) ManyToOne
idMotorista(FK) ManyToOne
dataDevolucao
dataEntrega
dataPedido
valorTotal
And for each Rent you need a Insurance Apolice:
(Tabela - ApoliceSeguro)
id(PK)
protecaoCausasNaturais
protecaoRoubo
protecaoTerceiro
valorFranquia
You have noticed how the scenario has changed, if you put the 1: 1 table in the same table, your table will get a lot of information that is not hers. The insurance, belongs to rent, but has insurance information, so it is a separation of responsibilities.
So for this particular scenario in the Rent table, you will have an FK as follows:
idApoliceSeguro(FK) OneToOne
About the need to perform more than one INSERT. Some frameworks can help you with this task, like Hibernate. Let's imagine that you try to perform only (1) INSERT. The error will occur saying that the object is referencing an unsaved instance, first save this unsaved instance before downloading the data in the database. The instance he is referring to is ApoliceSeguro.
If you are using Hibernate for example, you could create a DAO from the seraglio apolice, save it before, so it becomes an object persisted and managed by EntityManager and it will have the code to be able to save the rent. / p>
Or, in the @OneToOne annotation, you use the property (cascade = CascadeType.ALL) for all operations or only for certain operations like PERSIST, MERGE and etc.
But in your specific case, I have a suggestion, separate the responsibilities and use a relationship (ManyToMany), I would do it as follows:
(TABELA - usuario)
id(PK)
nome
senha
(TABELA - grupo)
id(FK)
descricao
nome
(TABELA - usuario_grupo)
id_usuario(FK)
id_grupo(FK)
This way I can manage as follows:
- GROUP = Administrator, Manager, Employee, ...
- User = user (X) belongs to the Administrator group
- User = user (y) belongs to the Manager group
And so on ...
In this way you manage in your application the rights that each group has and which users will receive those rights.