SQL Interview Questions
SQL Interview Questions
What is 'LIKE' used for in WHERE clause? What are the wildcard
characters?
LIKE is used for partial string matches. ‘%’ ( for a string of
any character )
and ‘_’ (for any single character ) are the two wild card
characters.
What is the system function to get the current user's user id?
USER_ID (). Also check out other system functions like USER_NAME (), SYSTEM_USER,
SESSION_USER, CURRENT_USER, USER, SUSER_SID (), HOST_NAME ().
What are triggers? How many triggers you can have on a table? How to invoke a trigger on demand?
Triggers are special kind of stored procedures that get executed automatically when an INSERT,
UPDATE or DELETE operation takes place on a table.
In SQL Server 6.5 you could define only 3 triggers per table, one for INSERT, one for UPDATE and one
for DELETE. From SQL Server 7.0 onwards, this restriction is gone, and you could create multiple
triggers per each action. But in 7.0 there's no way to control the order in which the triggers fire. In SQL
Server 2000 you could specify which trigger fires first or fires last using sp_settriggerorder
Triggers can't be invoked on demand. They get triggered only when an associated action (INSERT,
UPDATE, and DELETE) happens on the table on which they are defined.
Triggers are generally used to implement business rules, auditing. Triggers can also be used to extend
the referential integrity checks, but wherever possible, use constraints for this purpose, instead of
triggers, as constraints are much faster.
Till SQL Server 7.0, triggers fire only after the data modification operation happens. So in a way, they are
called post triggers. But in SQL Server 2000 you could create pre triggers also. Search SQL Server
2000 books online for INSTEAD OF triggers.
Also check out books online for 'inserted table', 'deleted table' and COLUMNS_UPDATED()
There is a trigger defined for INSERT operations on a table, in an OLTP system. The trigger is written to
instantiate a COM object and pass the newly insterted rows to it for some custom processing.
What do you think of this implementation? Can this be implemented better?
Instantiating COM objects is a time consuming process and since you are doing it from within a trigger, it
slows down the data insertion process. Same is the case with sending emails from triggers. This
scenario can be better implemented by logging all the necessary data into a separate table, and have a
job which periodically checks this table and does the needful.
What is a self join? Explain it with an example.
Self join is just like any other join, except that two instances of the same table will be joined in the query.
Here is an example: Employees table which contains rows for normal employees as well as
managers. So, to find out the managers of all the employees, you need a self join.
CREATE TABLE emp
(
empid int,
mgrid int,
empname char(10)
)
INSERT emp SELECT 1,2,'Vyas'
INSERT emp SELECT 2,3,'Mohan'
INSERT emp SELECT 3,NULL,'Shobha'
INSERT emp SELECT 4,2,'Shridhar'
INSERT emp SELECT 5,2,'Sourabh'
SELECT t1.empname [Employee], t2.empname [Manager]
FROM emp t1, emp t2
WHERE t1.mgrid = t2.empid
Here's an advanced query using a LEFT OUTER JOIN that even returns the
employees without managers (super bosses)
SELECT t1.empname [Employee], COALESCE(t2.empname, 'No manager') [Manager]
FROM emp t1
LEFT OUTER JOIN
emp t2
ON
t1.mgrid = t2.empid
Description of Normalization
Normalization is the process of organizing data in a database. This includes creating tables and
establishing relationships between those tables according to rules designed both to protect the data and
to make the database more flexible by eliminating two factors: redundancy and inconsistent dependency.
Redundant data wastes disk space and creates maintenance problems. If data that exists in more than
one place must be changed, the data must be changed in exactly the same way in all locations. A
customer address change is much easier to implement if that data is stored only in the Customers table
and nowhere else in the database.
What is an "inconsistent dependency"? While it is intuitive for a user to look in the Customers table for the
address of a particular customer, it may not make sense to look there for the salary of the employee who
calls on that customer. The employee's salary is related to, or dependent on, the employee and thus
should be moved to the Employees table. Inconsistent dependencies can make data difficult to access;
the path to find the data may be missing or broken.
There are a few rules for database normalization. Each rule is called a "normal form." If the first rule is
observed, the database is said to be in "first normal form." If the first three rules are observed, the
database is considered to be in "third normal form." Although other levels of normalization are possible,
third normal form is considered the highest level necessary for most applications.
As with many formal rules and specifications, real world scenarios do not always allow for perfect
compliance. In general, normalization requires additional tables and some customers find this
cumbersome. If you decide to violate one of the first three rules of normalization, make sure that your
application anticipates any problems that could occur, such as redundant data and inconsistent
dependencies.
NOTE: The following descriptions include examples.
But what happens when you add a third vendor? Adding a field is not the answer; it requires program and
table modifications and does not smoothly accommodate a dynamic number of vendors. Instead, place all
vendor information in a separate table called Vendors, then link inventory to vendors with an item number
key, or vendors to inventory with a vendor code key.
For example, in an Employee Recruitment table, a candidate's university name and address may be
included. But you need a complete list of universities for group mailings. If university information is stored
in the Candidates table, there is no way to list universities with no current candidates. Create a separate
Universities table and link it to the Candidates table with a university code key.
EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not always practical. If
you have a Customers table and you want to eliminate all possible interfield dependencies, you must
create separate tables for cities, ZIP codes, sales representatives, customer classes, and any other factor
that may be duplicated in multiple records. In theory, normalization is worth pursuing; however, many
small tables may degrade performance or exceed open file and memory capacities.
It may be more feasible to apply third normal form only to data that changes frequently. If some
dependent fields remain, design your application to require the user to verify all related fields when any
one is changed.
Tables should have only two dimensions. Since one student has several classes, these classes
should be listed in a separate table. Fields Class1, Class2, & Class3 in the above record are
indications of design trouble.
Spreadsheets often use the third dimension, but tables should not. Another way to look at this
problem: with a one-to-many relationship, do not put the one side and the many side in the same
table. Instead, create another table in first normal form by eliminating the repeating group (Class#),
as shown below:
Student# Advisor Adv-Room Class# --------------------------------------- 1022 Jones 412 101-07
1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 201-01 4123 Smith 216 211-
02 4123 Smith 216 214-01
Note the multiple Class# values for each Student# value in the above table. Class# is not
functionally dependent on Student# (primary key), so this relationship is not in second normal form.
In the last example, Adv-Room (the advisor's office number) is functionally dependent on the
Advisor attribute. The solution is to move that attribute from the Students table to the Faculty table,
as shown below:
Students: Student# Advisor ------------------- 1022 Jones 4123 Smith Faculty: Name Room Dept
-------------------- Jones 412 42 Smith 216 42
Why you need indexing? Where that is stored and what you mean by schema object? For what
purpose we are using view?
We can’t create an Index on Index.. Index is stored in user_index table. Every object that has been
created on Schema is Schema Object like Table, View etc.If we want to share the particular data to
various users we have to use the virtual table for the Base table...So that is a view.
Indexing is used for faster search or to retrieve data faster from various tables. Schema containing set of
tables, basically schema means logical separation of the database. View is crated for faster retrieval of
data. It's customized virtual table. we can create a single view of multiple tables. Only the drawback
is...View needs to be get refreshed for retrieving updated data.
• But trigger is automatically invoked when the action defined in trigger is done.
ex: create trigger after Insert on
• Triggers are used to initiate a particular activity after fulfilling certain condition. It need to define
and can be enable and disable according to need.