Handle database validation (exists, unique constraint, etc)
With approach A) you may run in a concurrency problem.
For example process A and process B want to write a new entry. Both load the data from the database and check if their new entry would be valid. Both decide &quot;YES, valid&quot;.
Now process A writes the new entry, and then process B tries to write. But A already changed the database, therefor the validation in B was executed on obsolete data.
Be aware that node will execute things concurrently, because as soon as a &quot;process&quot; (task) has some waiting time, another process (task) will be executed until that one is finished or also waiting for something.
With version B) this problem gets (for most db´s) fixed. On the other side, now your business logic is scattered over multiple systems, which makes maintenance harder.
--&gt; As always, there is no YES or NO but a &quot;depends on your context&quot; :-)
About the bonus question:
If your application uses the same entities as the DB, then your whole application (from top to bottom) has a dependency to your database schema.
As a result, a change in your DB then has to be followed by a lot of changes in your application.  If you do the mapping in the service layer (thats where i would expect the business logic), then all changes run at least until there.
Therefor i would &quot;map&quot; the data in the data access layer into the entities i use in my application. Yep, in many cases the entites will look similar, but it decouples my application from my database. And my business logic will not know anything about the format that is used when data gets stored.
By the way, some people use their entities over the whole application, some create new entities for each layer and the data get maped a lot. Both approaches have their reason, personaly i work with a entity set for the whole application.
Just a few thoughts. Pick those that make sense to you and skip the rest. :-)
warm regards