I have database application, I want to allow the user to restore the deleted records from the database, like in windows we have Recycle bin for files I want to do the same thing but for database records, Assume that I have a lot of related tables that have a lot of fields.
Edit:
let's say that I have the following structures:
Reports table
RepName primary key
ReportData
Users table
ID primary key
Name
UserReports table
RepName primary key
UserID primary key
IsDeleted
now if I put isdeleted field in UserReports table, the user can't add same record again if it marked as deleted, because the record is already and this will make duplication.
Note: I always use surrogate primary key.
Add a timestamp 'deleted_at' column. When user deletes entry put there current time. Make this key part of your constrain.
In every query remember to search only for records that have null in deleted_at field.
Some frameworks (like ActiveRecord) make it trivial to do.
Related
My boss has assigned a SQL task to me and as I am new to SQL, I am struggling to know where to start.
Task: Create a Customer table to hold the data written in the #Customer temporary table in the PopulateCustomers stored procedure. This table will also need to have a unique id to ensure multiple instances of the populate functionality can be run concurrently.
I know how to create a table in SQL and I am guessing I can look in the PopulateCustomer stored procedure to know what data will be written in the temp Customer table in order to create columns for the Customer table.
But what I am really struggling with is the concept of a unique Id for a database table. I immediately thought primary key for each row in the table. Which my boss responded no, I didn't want to push for more as not to come across as a newbie.
I have tried to google this myself and all I keep coming up with is pages that tell me about identifiers vs primary keys. But nothing ever tells me about a table having its own unique ID unless its in reference to the rows within the table each having an Identifier or primary key. This is leading me to think that I am not searching for the right key word for what this functionality is.
The closest thing I found was here. http://sqlservercodebook.blogspot.com/2008/03/check-if-temporary-table-exists.html
This query looks to me like its creating a temp table with an id.
CREATE TABLE #temp(id INT)
I have not pasted any of my work queries because I really want to research myself and figure this out. I just want to make sure I am looking in the right direction with what term I need to search for to find out how to create a table that has a unique ID. Or maybe I have misinterpreted the task and there is no such thing.
What I got from your story is that you need a table with an unique id, automatically generated, and use this id as the primary key.
This table can be created like:
create table example
(
id int identity(1,1) primary key clustered,
other_data varchar(200)
)
The key terms here are:
identity - for the id column be auto-incremented
primary key - so SQL Server ensures this column is unique
clustered - for all the data in this table be organized physically by this column (and make it faster to be searched by it)
I am trying to create a database for hotel reservation system.
In that the Date, Reserved Time (breakfast, lunch or dinner) and Table Number all 3 candidate keys become a composite primary key. In access it's possible to make all these 3 as primary key but when I'm trying to make relationship (Ex:with customer detail table) it's impossible due to there is no unique primary key in this table.
Is there any solution for this?
https://drive.google.com/file/d/0B5_8M-VhW5zoZ3ExRUlvakU4bzQ/view?usp=sharing
Sorry that i don't have privileges to directly add image.
Please be kind enough to refer this link.
I would recommend that you use an AutoNumber field for the primary key instead of having a composite key. Then you don't have to deal with issues like the Date field being changed in an existing record breaking relationships to other tables.
I have a SQL Server database and it contains a table to record a employee salary.
It has 3 columns declared as foreign keys, and reference to the employee table's column, employee_id:
employee_id
submitted_by
confirmed_by
But is it best practice to make it all as FK, or do I only need employee_id?
Because in my application, submitted_by and confirmed_by will be selected by a drop down list and assume it exist on employee table.
Thanks you for advice.
Yes, since all users of your system are also Employees modelled by your system, if you wish to have Referential Integrity (RI) enforced in the database, all three columns should have foreign keys back to the referenced employee table. Note that since confirmed by sounds like part of a workflow process, where the user confirming may not be available at the time the record is inserted, you can make the field confirmed_by in table EmployeeSalary nullable (confirmed_by INT NULL), in which case RI will only be enforced at the later time when the field is actually populated.
You should name each of the foreign keys appropriately by expressing the role in the foreign key, e.g.
FK_EmployeeSalary_SalariedEmployee
FK_EmployeeSalary_EmployeeSubmittedBy
FK_EmployeeSalary_EmployeeConfirmedBy
Although the front end may restrict choices via the drop down, referential integrity is still beneficial:
Protect against bugs, e.g. where the submitted by employee is omitted (in the case of a non-nullable FK) or the employee provided doesn't exist in the employees table.
Prevent accidental deletion of an employee to which foreign key data is linked.
There is a (very) minor performance penalty on RI whereby the DB will need to check the existence of the PK in the employee table - in most instances this will be negligible.
Any column that references a key in another table should be declared as a foreign key. This way, if you mistakenly try to put a nonexistent value there, the database will report an error.
I am making a Django web app and need help designing the a table within the DB.
I am to insert into the table an employee with a specific employee ID. Lets say there are three employees with the IDs (15039, 98443, 29234). Would the employee ID be the primary key or do I have to make some arbitrary column starting from 1 the primary id with employee id as a standalone column?
In a sense what I am i asking is if the 15039, 98443, and 29234 employees were inserted into the table with empl ID being primary key which order would the DMBS order them?
You did not specify which database you will use, but most likely the primary key will be the clustered index, in which case the database will order the rows by that id.
Many argue you should always create an auto-increment artifical primary key, and that usually saves you a lot of pain in the long run.
However, if you know the value will always be unique and you won't ever need to change the value, you can opt to use it as the PK for the table.
I just starting a project, I would like to have a small content manager with version control. However I don't know what is the best way to model the database.
I have content table which contains the following fields:
id primary key serial,
content_id int (field to identify diferent contents),
title varchar,
content longtext,
version int default '1',
create_date date,
I have seen some CMS separes the revisions in another table than the actual revision, What's the best way? Is there any optimized way?
Thanks!
I designed something like this and here's the gist of it;
I create mirror table for every table that I want to have row level version control. Let's say you have CUSTOMER table. Your mirror version control table will be VER_CUSTOMER
Every table that I want to have row level version control has a column called RECORD_ID (GUID)
When a record inserted to that table, I generate new GUID and populate that field. New record also inserted into VER_CUSTOMER table with RECORD_ID as added to table's natural PK.
When record is updated, I generate new GUID again. Populate RECORD_ID with this new GUID. Updated record also goes to VER_CUSTOMER table.
When record is deleted, I mark record on CUSTOMER table as DELETED (not physically delete the record). I have IS_DELETED column on every table. I set that column to TRUE when record is attempted to be deleted. Again copy of the deleted record also goes into VER_CUSTOMER table.
So every transaction that you have on that table, you have a corresponding record in VER_CUSTOMER table with RECORD_ID and table's natural PK as PK. For example if CUSTOMER table's PK is CUST_ID. PK of VER_CUSTOMER will be composite CUST_ID and RECORD_ID.
Hope this helps...
This already exists, without a database:
gitit (written in Haskell, uses git or darcs as a backend)
ikiwiki (written in Perl, can use various version control systems as a backend)
They're both open source, and both have a plugin architecture, so can be customised for your specific needs. (However, I've only used gitit.)
I would however note that git is not perfect at versioning large binary files, and darcs is terrible at it. Something to watch out for.