Design Implementation SQL tables - c#

I am new to SQL and been given a task. Following are the details:
What I have:
A C# desktop application for User login and view user status (only two options: user logs in and check status of all users that are dummy created)
A table named USER containing
id
username
datecreated
A table named LOGINSTAT containing
id
username
Logtime
logDate
What I have to implement
I have to save time and date when ever user logs in in LOGINSTAT table using SQL.
My question
My question is how can I implement that. I can do the coding part but I am interested in getting some good advice to implement it. I think of it as a formal way as I know to do it:
when user logs in insert values into the login table giving all the required values.
BUT
I think that might be a bit odd. Some of my friends said you may be able to implement it by use of foreign key and primary keys, but the problem lies that the user may log in many time in a day. How to keep track of login time and date in that case?

You don't need username in your LOGINSTAT table.
You'll probably want the LOGINSTAT to include:
id
u_id
loginDateTime
id is the unique ID of every login
u_id is a foreign key from the id in users that matches your log event to a user
loginDateTime is a datetime that will give you both your log date and log time in one column

What is unique in LOGINSTAT? Not user by itself, but ID+LogDate+LogTime should be. That would be your primary key.
The only foreign key is in LOGINSTAT: ID, which references the ID in the USER table.

Values in a PRIMARY KEY column (eg. USER.id) must be unique from one another.
Values in a FOREIGN KEY column in another table referencing that primary key (eg. LOGINSTAT.id referencing USER.id) do not need to be unique - you can have multiple records in a table have the same foreign key column reference the same primary key.

Related

Generating unique column like primary key

I have created a multi-tenant application in which users creates record which has an unique number like a primary key. Every record that is added to the system increases that unique number and labels itself with that number.
My problem is, when two users try to insert a record at the same time, I get the same unique number. I want that number to be unique.
I tried to work with threads, assumed the second thread will wait for the first one to get the correct number and continue. But it didn't go as I planned.
I have also tried table triggers. When a new record inserted, I just updated the field with the latest unique ID. But still when two record comes at the same time, got same unique ID.
I expect to create unique id column, like a primary key. I understand that it could be done with in database or code.

Prevent Duplicate Records in SQL Server

I have 3 tables in my Database, one for student and other for the courses and the third one to store what every student select from courses. I want to prevent the student from selecting the same course more than once. what condition should I provide in Insert statement in the third table?
Thanks
Your StudentCourse table should have a unique constraint on the (StudentId, CourseId) table.
As an alternative, you can create the Primary Key on your StudentCourse table as a composite key on (StudentId, CourseId).
While it follows that every table in your database must have a Primary key constraint, often its an auto generated value useful when carrying out most database maintenance tasks. However the primary key itself will not protect you from user generated or user captured data that may contain duplications. Enter the “Unique” constraint! This is a very powerful table-level constraint that you can apply to your table against a chosen table column, which can greatly assist to prevent duplicates in your data. For example, say you have a “Users” table and in it, you have an EmailAddress column, surely it would be strange to capture 1 or 2 users who have an identical email address.

Best practice for saving data in SQL

I am creating a survey. It is long enough that I want to give people a chance to save what they have so far. I am wondering what the best practice is for saving the data. Do I turn off foreign key constraints so if they haven't selected everything yet then foreign key constraint errors are ignored. In this example I use an ID to link the documents table to the table that holds what they have selected. If they haven't selected a document yet then a -1 is inserted as a holder. Or do I create a second table to hold the saved place data. Or is there a third option.
There is a 3rd option. You can generate the primary key right when the user begins the survey. There are two ways to do this:
Generate a database record and read-back the primary key (assumes
it's generated by the database)
Change the primary key to be a GUID
and simply generate a GUID in code.
OK, using -1 this way means that you have to have document in the documents table with an id of -1. If you don't a better structure would be to define the field as allowing nulls. Then you pass in a null value.
You might want to read this:
Can a foreign key be NULL and/or duplicate?

Get application username for Audit table

I want to implement an audit table and I have no idea how am I supposed to get the username.
I am using C# and Sql Server. I have a Users table in my database. When I log in my windows form application I verify if the correct combination of username and password is used. But how do I inform the database of the current user? I thought of adding an extra column to my Users table in which to set on 1 the logged username. Is that a solution for single-user? But my application in supposed to support multi-user. What could be done in this case?
Depending on your authentication scheme, you need to get the the User name.
for thick client applications,
Environment.Username
and
System.Security.Principal.WindowsIdentity.GetCurrent()
are a couple of options.
typically for audit tables, there is a column called 'ModifiedByUser' where you can log the user name provided by the win form app.
create the nvarchar and datetime columns (if not already) in your audit table.
one will stored the user name and the other the datetime of the audit action.
in your code, whenever you want to add an entry to the audit table, get Environment.Username or System.Security.Principal.WindowsIdentity.GetCurrent(), along with DateTime.UtcNow and pass it on to be saved to the DB into the Audit table.
SQL Server knows who you are. You can simply use SUSER_SNAME() or/and ORIGINAL_LOGIN() function as a default value for the username column in your audit table. Same for the time of audit event, use GetDate() function. There is no need to send this information from the client.
This is a very open-ended question but I think I understand what you are trying to do. You have application-specfic users that are defined in a Users table (as opposed to using database users or active directory users) and you need to log specific information for auditing purposes or drive security based off of the logins. Is that correct?
This can be done, but the logic for it will need to be written in your application.
Let’s pretend we are writing a program to send out an invoice to a customer.
I used role based security where you can give users access to do specific tasks by granting them a role. For example, “Create New Invoice” could be a role. I usually have 2 tables for this:
SecuirtyRoleDefintion
SecurityRoleUsers
The fist table, Security Role Definition will have an ID column, the Description (“Create New Invoice”), and I usually have a Audit column to indicate if this action needs to be logged for Audit.
The second table, SecurityRoleUsers, is where I define if a user has permission to execute that role. Columns are usually something like this: a unique ID, User ID (foreign key to the Users table), RoleID (foreign key to SecurityRoleDefintion)
Now in your application we need a class to check if a user has a role. It needs to take in the role ID (or name) and the user ID. Example: public bool IsUserAuthorized(int RoleID, int UserID)
This method can run a query on your SecurityRoleUsers table to see if the user is in the table for that role. If so, it returns true. If not, it returns false.
Now back in the application when user click the “Create New Invoice” button it runs the IsUserAuthorized() method to check if a user can perform the operation.
If creating an audit log is necessary, you could do something similar. After the security check is done for “Create New Invoice” you can check to see if the Role needs to be audit logged, if so then write to an Audit table.
DECLARE #username varchar(128)
SET #username = CONVERT(VarChar(128), CONTEXT_INFO());
PRINT #username
DECLARE #ID_User int
SET #ID_User = ( SELECT Users.ID_User
FROM Users
WHERE Users.Username=#username )
PRINT #ID_User
This is how I solved it. I inserted this piece of code in each update trigger.

How to Update the primary key of table which is referenced as foreign key in another table?

Suppose a
Table "Person" having
"SSN",
"Name",
"Address"
and another
Table "Contacts" having
"Contact_ID",
"Contact_Type",
"SSN" (primary key of Person)
similarly
Table "Records" having
"Record_ID",
"Record_Type",
"SSN" (primary key of Person)
Now i want that when i change or update SSN in person table that accordingly changes in other 2 tables.
If anyone can help me with a trigger for that
Or how to pass foreign key constraints for tables
Just add ON UPDATE CASCADE to the foreign key constraint.
Preferably the primary key of a table should never change. If you expect the SSN to change you should use a different primary key and have the SSN as a normal data column in the person table. If it's already too late to make this change, you can add ON UPDATE CASCADE to the foreign key constraint.
If you have PKs that change, you need to look at the table design, use an surrogate PK, like an identity.
In your question you have a Person table, which could be a FK to many many tables. In that case a ON UPDATE CASCADE could have some serious problems. The database I'm working on has well over 300 references (FK) to our equivalent table, we track all the various work that a person does in each different table. If I insert a row into our Person table and then try to delete it back out again (it will not be used in any other tables, it is new) the delete will fail with a Msg 8621, Level 17, State 2, Line 1 The query processor ran out of stack space during query optimization. Please simplify the query. As a result I can't imagine an ON UPDATE CASCADE would work either when you get many FKs on your PK.
I would never make sensitive data like a SSN a PK. Health care companies used to do this and had a painful switch because of privacy. I hope you don't have a web app and have a GET or POST variable called SSN with the actual value in it!! Or display the SSN on every report, or will you shred all old printed reports and limit access to who views each report., etc.
Well, assuming the SSN is the primary key of the Person table, I would just (in a transaction of course):
create a brand new row with the new SSN, copying all other details from the old row.
update the columns in the other tables to point to the new row.
delete the old row.
Now this is actually a good example of why you shouldn't use real data as table cross-references, if that data can change. If you'd used an artificial column to tie them together (and only stored the SSN in one place), you wouldn't have the problem.
Cascade update and delete are very dangerous to use. If you have a million child records, you could end up with a serious locking problem. You should code the updates and deletes instead.
You should never use a PK with the potential to change if it can be avoided. Nor should you ever use SSN as a PK because it should never be stored unencrypted in your database. Never, unless your company likes to be sued when they are the cause of an indentity theft incident. This is not a design flaw to shrug off as this is legacy, we don't have time to fix. This is a design flaw that could bankrupt your company if someone steals your backup tapes or gets the ssns out of the sytem in another manner (most of these types of thefts are internal BTW). This is an urgent - must fix now design flaw.
SSN is also a bad candidate because it changes (people change them when they are victims of identity theft for instance.) Plus an integer PK will have faster performance than a nine-digit PK.

Categories

Resources