U lost inferential integrity, like on delete cascade when the parent is deleted, etc. So many codes to maintain, instead of using database features.

regards

Hello,

With the current solution you applied you can't ensure data integrity and consistency. So you may add some values into AId of table B which is not existing into table A. 

Also when you delete one record of AId if it has any records into table B it will continue using deleted Id.

The best solution here is to extract Table A at least or both A and B into new module and reference this module into both X module and Y module

Problems are what @Mostafa Othman is saying,

in the day to day usage, data integrity is not ensured, but it is also bad for software maintainability, this dependency is hidden from anybody doing work on the X module.

Let's assume you leave the A entity in the X and the B entity in the Y module, then let's rename your modules for better readability for anyone appliying the common naming standards

module X_CS : 

• only contains A entity and A wrappers
• this module has no dependencies on B

module Y_CS

• only contains B entity en B wrappers
• this module has a dependency on X_CS, in the form of a reference A_Id in entity B

NEW module :

• naming and parent application is up for debate and would depend on where the logic best fits with
• so that would be X_BL or Y_BL or maybe XY_BL or maybe somethingCompletelyDifferent_BL
• this module has no entities but has the actions you now have put in the X module
• this module will probably have dependencies on both A_CS and B_CS because your actions involve both, and involve creating the reference between them

So there are no circular references now

• something_BL references X_CS and Y_CS
• Y_CS references X_CS

Dorine

Is there a need for the two entities to be in a different module? They seem to be closely related which might pop the question why not put them in one module?