Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
Context Our product owner has realized that some entities are duplicated from time to time and that a merge is required. This should clean up existing duplicates and also allow special users to me...
#2: Post edited
by
Alexei
·
2021-06-25T17:33:06Z (almost 3 years ago)
explained the cons of EF approach
- ## Context
- Our product owner has realized that some entities are duplicated from time to time and that a merge is required. This should clean up existing duplicates and also allow special users to merge entities in the future.
- The merge process is defined as follows (this should be done atomically):
- - identify "to be merged" and "main" entities
- - archive "to be merged" information
- - parent most of the children of "to be merged" to "main"
- - write some archiving metadata (who, when etc.)
- - remove "to be merged" (with cascade)
- The entity is rather used as it has a couple of dozens of other entities referencing it (foreign keys).
- ## Dilemma
- I am wondering how to proceed about this as I see two main options.
- ## Entity Framework approach
- - add all archive related models in the database context
- - easily archive data by mapping existing models to archive ones
- - all changes are done in a context transaction
- **Pros**: rather easy to implement
**Cons**: bloats the context with archive related models- ## SQL approach
- Create a stored procedure to tackle the archiving.
- **Pros**: avoid bloating the context and app with archiving functionality
- **Cons**: use SQL stored procedure which is harder to write and maintain.
- Another way is to create another database context for archiving stuff, share the connection string and explicitly handle the transaction.
- I am wondering if there is any best practice for such functionality.
- ## Context
- Our product owner has realized that some entities are duplicated from time to time and that a merge is required. This should clean up existing duplicates and also allow special users to merge entities in the future.
- The merge process is defined as follows (this should be done atomically):
- - identify "to be merged" and "main" entities
- - archive "to be merged" information
- - parent most of the children of "to be merged" to "main"
- - write some archiving metadata (who, when etc.)
- - remove "to be merged" (with cascade)
- The entity is rather used as it has a couple of dozens of other entities referencing it (foreign keys).
- ## Dilemma
- I am wondering how to proceed about this as I see two main options.
- ## Entity Framework approach
- - add all archive related models in the database context
- - easily archive data by mapping existing models to archive ones
- - all changes are done in a context transaction
- **Pros**: rather easy to implement
- **Cons**: bloats the context with archive related models (add a dozen models that have very similar names to the operational ones and might create confusion when having to work with DbSet related to these).
- ## SQL approach
- Create a stored procedure to tackle the archiving.
- **Pros**: avoid bloating the context and app with archiving functionality
- **Cons**: use SQL stored procedure which is harder to write and maintain.
- Another way is to create another database context for archiving stuff, share the connection string and explicitly handle the transaction.
- I am wondering if there is any best practice for such functionality.
#1: Initial revision
by
Alexei
·
2021-06-23T13:10:55Z (almost 3 years ago)
Mixing "operational" database models with archiving ones in the database context
## Context Our product owner has realized that some entities are duplicated from time to time and that a merge is required. This should clean up existing duplicates and also allow special users to merge entities in the future. The merge process is defined as follows (this should be done atomically): - identify "to be merged" and "main" entities - archive "to be merged" information - parent most of the children of "to be merged" to "main" - write some archiving metadata (who, when etc.) - remove "to be merged" (with cascade) The entity is rather used as it has a couple of dozens of other entities referencing it (foreign keys). ## Dilemma I am wondering how to proceed about this as I see two main options. ## Entity Framework approach - add all archive related models in the database context - easily archive data by mapping existing models to archive ones - all changes are done in a context transaction **Pros**: rather easy to implement **Cons**: bloats the context with archive related models ## SQL approach Create a stored procedure to tackle the archiving. **Pros**: avoid bloating the context and app with archiving functionality **Cons**: use SQL stored procedure which is harder to write and maintain. Another way is to create another database context for archiving stuff, share the connection string and explicitly handle the transaction. I am wondering if there is any best practice for such functionality.