I'm building an ASP.NET MVC application with SQL Server. I would like to know what will be a good practice for record deletion operations. I mean, when an item is deleted via web application, I would like to mark it as deleted, and then from an admin console, I will purge them if needed.
Is this a good practice? Should I use or avoid?
Thank you.
There is nothing wrong with this approach if you have no issues with storage space. Typically, we will use this pattern if the object being deleted is tied to other object (for instance, if you were tracking changes by user id, then you would not want to delete the user because you would not be able to pull info for that user later on). Simply mark a bit field showing the record has been deleted and filter those out when you query.
Again, it really depends on what makes sense for you and your application. Will you ever need this object again? Is it tied to other items in the database? Do you want to offer the user the option to 'undelete'? If the answer to any of those questions is yes, then you should probably keep the record. If the answer to all of those is no, then I would ask, why would you not just delete the record at the time it was requested?
Related
I'm making a table with React, where the user can add new entries, and I'm deciding what to use as a key. I'm considering these options:
Use database id. But this will force me to talk with the server every time the user wants to add a new entry, which is not ideal.
Generate a front-end id for each row and persist it in the state
Option 2 clearly seems better, but I see the React docs recommend using database id.
I've dealt with this same dilemma many times over different projects, and I've never figured out the best solution, so I decided to get it answered once and for all.
It sounds like you might want to go with Option 2 for any data that hasn't been saved yet to the DB.
Recommendation is correct to use the DB id when available, but seeing as how your requirements allow for temporary or "draft" entries then I see no problem with Option 2. Just be wary of how you generate these temp ID's as you'll want to prevent clashes with existing ID's in the array.
I want to know if it would make sense to store the website about text and contacts in a database instead of just writing it in the html, and how would I do that?
I've been thinking just one table for each with the information and no id (since I only want to store one version of everything), but that doesn't make a lot of sense, I think.
The about table should contain the text and the contacts should contain an address, coordinates, email and phone number.
Any suggestions?
The question might get flagged as off topic, but I have some thoughts. I would only put stuff in a database that would be updated frequently. Simply putting text in a DB that never really changes doesn't get you any benefit and just adds complexity and burden on your DB. If you find yourself copying the same web text to different pages of your site, make it text you include.
User information like logins,etc. that is added/updated/deleted should clearly live in a DB. But unless your About Us kind of data is going to be changed constantly or you make a tool that allows somebody else to update it, don't put that in the DB.
I have a problem in the entity framework and looking for a solution, the problem is this :
imagine a software with one form that contains staff data,
now two users open the same record at the same time in their own systems to edit its data,
the first user changes the name and saves his edit,
some seconds after the first user, the second user changes the phone number and save his edit,
now which changes are registered in the database?
yes, the second change.
as you may found out my problem, I need a solution to allow both changes happen correctly in entity framework ORM.
do I must handle such things in the UI section, or there is a way in the entity framework itself?
thanks in advance.
I'd like to log all changes made an SQL Azure database using Entity Framework 4.
However, I failed to find a proper solution so far..
So far I can track all entities themself by overriding SaveChanges() and using the ObjectStateManager to retrieve all added, modified and deleted entities. This works fine. Unfortunately I don't seem to be able to retrieve any useful information out of RelationshipEntries. In our database model we some many-to-many relationships, where I want to log new / modified / deleted entries too.
I want to store all changes in an Azure Storage, to be able to follow changes made by a user and perhaps roll back to a previous version of an entity.
Is there any good way to accomplish this?
Edit:
Our scenario is that we're hosting a RESTful WebService that contains all business logic and stores the data in the Azure SQL Database. A client must be authenticated as a user with the WebService, and I'd need to store the information which user changed the data.
See FrameLog, an Entity Framework logging library that I wrote for this purpose. It is open-source, including for commercial use.
Even if you don't want to use the library, you can look at the code to see one way of handling logging relationships. It handles all relationship multiplicities.
Particularly, see the code for the private methods logRelationshipChange, and logForeignKeyChange in the ChangeLogger class.
You can do it with a tracing provider.
You may want to consider just using a database trigger for this. Whenever a value in a table is changed, copy the row to another Archive table. It has worked pretty well for me.
I have a classic 3-tier web application build with MySQL and Tomcat.
I want to save the creator id of each database record for all tables at creator_id column or just log it somewhere.
Current user is stored at the http session object.
Modify all queries and pass creator id parameter is unacceptable.
Can I solve the problem using triggers, alter table commands etc.?
What is the best way to do that?
PS. Hacks are acceptable and welcome.
The database can't possibly know which site user is sending the query, all it knows is which database user. And if it's a web application, it's probably the same database user all the time, no matter who is logged in on the website.
The short answer is that no, you're going to have to go with your "unacceptable" option, unless you want to create a database user for every site user, and have the site open the database connection using those, instead of one "shared" user. But that may end up causing more problems than it solves.
Based on what you say in your question, your logical application user ID is different than your database connection ID. IF that is the case how can the database possibly know what your logical application user ID is? unless you pass it in, there is no way for it to know who is doing what. You say that is is unacceptable to modify all queries to pass this in. However, you would only need to modify the saves where you want to record this "creator_id" value. You will need to modify those tables as well. Hopefully you have a table that contains all of these users and you can FK to the new column to this table.