Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Mixing "operational" database models with archiving ones in the database context

+2
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Can you clarify the kind of "bloat" you are concerned about? Memory use? Name collision? Redundancy i... (2 comments)

1 answer

+2
−0

Generally speaking, switching data access technologies to avoid a naming conflict seems overkill. Doing that will increase the set of technologies contributors must be familiar with, and impede code reuse.

So, how to solve the similar names part? I'd probably choose names that are obviously different, for instance by requiring a big eye catchy prefix like ArchivedOrder. Using a prefix ensures that code completion will only suggest archive tables if a programmer explicitly types "Archive", and thus makes it very hard to accidentally refer to the wrong table.

Other, entity framework specific, solutions may exist, but alas I am not familiar enough with EF to advise you on their applicability.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General (1 comment)

Sign up to answer this question »