This Was Intended To Be A List of Hints and Tips That You Might Find Useful When Using SQ

This was intended to be a list of hints and tips that you might find useful when using SQ,L
but a mere list of tips would be of little benefit without the knowledge to make use of them, so we've expanded the list to include the explanations to increasing its usefulness and to make it a proper tutorial. One important point to remember is that Oracle caches the compiled form of SQL and is therefore able to re-use queries which are the same as previously executed queries. This saves the time and resources required to parse the statement and determine the execution plan. How can you do this ?
Use Views
Views are a good way to ensure the same query is re-used as much as possible.
Remember that even just changing the case and spacing of the words could prevent a query from being reused. A view is merely a pre-defined query, the text of which is stored in the database. Therefore by using views you are using exactly the same queries and eliminating the re-parsing overehead. As the load on the database increases this reparsing overhead becomes more and more significant. Materialised views take the concept one stage further by actually running the query and storing the results in a table
Use Stored Procedures

Another way is to use stored procedures which are program units that contain both SQL and logic statements and are stored in the database. Oracle allows the use of PL/SQL and Java stored procedures. Stored procedures and views also have the advantage that the queries in the views/stored procedures have to be tuned only once, not in every place where they're used. Like views, stored procedures also eliminate the overhead of sending the queries from the client to the server as the queries are already on the server.
Use Bind Variables

The use of bind variables in queries makes them generic and therefore re-usable. For example, instead of writing a query like :SELECT name,addr FROM custs WHERE id = 12345; Change it to:SELECT name,addr FROM custs WHERE id = <cust_id>; The first query will only be re-used when you request the details for customer number 12345, whereas the second query will be re-used for any other customer.
For Better, Faster, Smarter, Oracle Solutions

SQL Tutorial - Hints And Tips To OptimiseYour SQL (ctd)
4. Use Selective Indexes

Ensure that tables are accessed via selective indexes, unless the table is very small or very large, in which case it may be better not to use the indexes. If the table were very small it could be cached completely, or all the columns could be indexed which means only the index would have to be read to satisfy any query. Also make sure that you're not disabling the use of an index by:
using an operator on the column (eg. <indexed_col> + 1); the use of hints, if you're running Oracle(only applies if you're using the cost based optimiser); using NULL and not equal checks. (eg. <indexed_col> <> 12345 ; or <indexed_col> IS NULL)
5. Use Full-Table Scans

If the table is very large, depending on how many blocks are read, using an index may remove everything else from the buffer cache and degrade the performance of all other queries. In which case a full-table scan is better - only the last few blocks read are kept in the buffer cache.
6. Optimise Joins
All other things being equal, the driving table is the one listed LAST in the FROM clause, when using the rule-based optimiser. Changing the order of the columns in the join condition does not change which table is used as the driving table. Choose the driving table carefully to ensure the minimum number of rows are returned. When using the cost-based optimiser, ensure that all the tables in the join have been analysed (ask your dba), if they haven't, this may well cause poor performance. The most usual way to optimise queries when using the cost-based optimiser is to use hints, which instruct the parser as to which indexes should or should not be used, or which tables should be scanned in full. You can also experiment with the order of the tables in the join.
Indexes - these can still be used even if the where clause contains a "like" condition but not if there is a "not like" condition. Outer joins - the correct syntax for outer joins using Oracle syntax is: tab1.col1(+)= tab2.col1 or tab1.col1 = tab2.col1(+) The bracketed plus sign follows the column of the table which has/may have the missing row. An alternative is to use the ANSI standard outer join format which has the advantge that it enables you to perform a full outer join in one statement:
tab1.col1 left outer join tab2.col1 (return all rows from tab1) tab1.col1 right outer join tab2.col1 (return all rows from tab2) tab1.col1 full outer join tab2.col1 (return all rows from tab1 and tab2) The final tip for this short tutorial is:
7. Name The Columns In A Query

There are three good reasons why it is better to name the columns in a query rather than to use "select * from ...". 1. Network traffic is reduced. This can have a significant impact on performance if the table has a large number of columns, or the table has a long or long raw column or have in-line clob or blob columns (all of which can be up to 2 Gigabytes in length). These types of columns will take a long time to transfer over the network and so they should not be fetched from the database unless they are specifically required. 2. The code is easier to understand, which means you need fewer comments! 3. It could save the need for changes in the future. If you are using views, not only might columns be added to or removed from the view, but the order of the columns could well change - in which case using "SELECT *" at best would fetch the wrong data and at worst would fail with an Oracle error which might take a long while to understand. This tutorial just scratches the surface of the subject, for more help see our Advanced SQL Tutorial --------------------------------------Subscribe to our Oracle ezine and sky-rocket your performance.
Smartsoft Computing Ltd Bristol, England Tel: 0845 0031320 Contact Us
Click here to view our privacy policy . This site uses woopra.com to gather statistical information about our visitors. View woopra privacy policy .
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. UNIX is a registered trademark of The Open Group in the United States and other countries.
Copyright Smartsoft Computing Ltd 2001-2009. All rights reserved.
Search for:
Training Overview Oracle Training UNIX Training Oracle Financials Solaris Red Hat Linux AIX HP-UX MySQL & PHP Introduction to Oracle Introduction to SQL Advanced SQL Oracle 8 Oracle 9i Oracle 10g Oracle Performance Tuning PL/SQL More free guides and tutorials Oracle UNIX Linux
For Better, Faster, Smarter, SQL Tutorials

Advanced SQL Tutorial
This advanced SQL tutorial focuses on the design of more complex SQL statements and the strategies available for implementing them, it concentrates on sub queries and joins because they are often inter-changeable, and views because these are often used to hide the complexity of queries involving sub-queries and joins. As this is an advanced tutorial there is some consideration of performance issues, but this aspect is more thoroughly explored in our series on Oracle performance tuning. You might also be interested in our beginner's SQL tutorial, our PL/SQL tutorials and our Oracle tutorials
Part 1 of this advanced SQL tutorial (this article) introduces sub-queries and looks
at non-correlated sub-queries. Part 2 looks at the use of sub-queries. Part 3 looks at nested sub queries, sub-queries in the from clause and sub-queries that return no rows. Part 4 of this tutorial covers correlated sub-queries.
Sub Queries
Sub queries are also known as nested queries and are used to answer multi-part questions. Sub queries and joins are often interchangeable and in fact the Oracle optimiser may well treat a query containing a sub-query exactly as if it were a join. Let's use a trivial example of finding the names of everybody who works in the same department as a person called Jones to illustrate this point. The SQL could be written using a sub query as follows: SELECT name FROM emp WHERE dept_no = (SELECT dept_no FROM emp WHERE name = 'JONES') or as a join statement, like this:SELECT e1.name FROM emp e1,emp e2 WHERE e1.dept_no = e2.dept_no AND e2name = 'JONES' With a trivial example like this there would probably be very little difference in terms of performance of the SQL for such a simple query, but with more complex queries there could well be performance implications. For this reason it is always worth trying a few variations of the SQL for a query and examining the execution plans before deciding on a particular approach, unless they're very simple queries.
Learn more about Oracle performance tuning here.
Non Correlated Sub-Queries

There are, in fact, two types of sub query: correlated and non-correlated. The example shown above is a non-correlated sub query. The difference between them is that a correlated sub query refers to a column from a table in the parent query, whereas a noncorrelated sub query doesn't. This means that a non-correlated sub query is executed just once for the whole SQL statement, whereas correlated sub queries are executed once per row in the parent query. Continue this Advanced SQL tutorial and learn more about sub-queries or see part 4 for more on correlated sub queries. --------------------------------------For more Oracle Tips and Tricks sign up to our ezine. There's no frills, no fluff, just solid, reliable technical information. Take a short cut to your success and subscribe now. It's jam-packed full of tips and tricks to help you make your Oracle applications better, faster and smarter. Sign up today and your first issue will soon be winging its way to your mailbox. Return from advanced sql tutorial to Oracle tips and tricks
Copyright Smartsoft Computing Ltd 2001-2009. All rights reserved. Search for:
For Better, Faster, Smarter SQL Tutorials

Advanced SQL Tutorial (ctd)
This is part 2 of our Advanced SQL Tutorial. Part1 introduced sub-queries and looked at non-correlated sub-queries. This part looks at the uses of sub queries. There is also some consideration of performance issues, but this aspect is more thoroughly explored in our series
on Oracle performance tuning. See also our beginner's SQL tutorial, the PL/SQL tutorials and the other Oracle tutorials
Uses of Sub Queries

The most common use of sub queries is in the WHERE clause of queries to define the limiting condition for the rows returned (i.e. what value(s) the rows must have to be of interest), as in the previous example. However, they can also be used in other
parts of the query. Specifically, sub queries can be used:
to define the limiting conditions for SELECT, UPDATE and DELETE statements in the following clauses:o WHERE o HAVING o START WITH Instead of a table name in o INSERT statements o UPDATE statements o DELETE statements
o
the FROM clause of SELECT statements
To define the set of rows to be created in the target table of a CREATE TABLE AS or INSERT INTO sql statement. To define the set of rows to be included by a view or a snapshot in a CREATE VIEW or CREATE SNAPSHOT statement. To provide the new values for the specified columns in an UPDATE statement
The first example of sub query in SQL shown above, used a simple equality expression as we were interested in only one row, but we can also use the sub query to provide a set of rows. For example, to find the names of all employees in the same departments as Smith and Jones, we could use the following SQL statement :SELECT name FROM emp WHERE dept_no IN (SELECT dept_no FROM emp WHERE name = 'JONES' OR name = 'SMITH') In fact, the original example could also return more than one row from the sub query if there were two or more people that were called Jones working in different departments. In the first example a run-time SQL error would be generated in that case, because the
first example, by using '=', specified that the sub query should produce no more than one row (it is perfectly legitimate for a sub query to return no rows). We can reverse the question to ask for the names of all the employees that are NOT in the same department as Jones, To do this, the sense of the sub query just has to be reversed by prefixing it with 'NOT' or '!'. Again depending on whether there might be more than one Jones, we would either use 'IN' or '=' SELECT name FROM emp WHERE dept_no NOT IN ( SELECT dept_no FROM emp WHERE name = 'JONES') Or SELECT name FROM emp WHERE dept_no != ( SELECT dept_no FROM emp WHERE name = 'JONES') Click on the link to continue this advanced SQL tutorial and learn about nested sub queries. --------------------------------------Want a short cut to learning SQL? Simple - just subscribe to our ezine. It's jam-packed full of tips and tricks to help you make your Oracle applications better, faster and smarter. Sign up today and your first issue will soon be winging its way to your mailbox. Return from advanced sql tutorial to Oracle tips and tricks
For Better, Faster, Smarter, SQL Tutorials

This is the final part of our advanced SQL tutorial focusing on the design of more complex SQL statements and sub queries in particular. Part 1 introduced sub-queries and looked at non-correlated sub-queries. Part 2 covered the the uses of sub-queries and part 3 covered
nested sub queries, sub-queries in the from clause and sub-queries that return no rows. The final part of our tutorial examines the use of correlated sub-queries. Performance issues are only briefly mentioned as we have a whole series of articles on that topic (see Oracle Performance Tuning).
You might also be interested in our beginner's SQL tutorial,
our PL/SQL tutorials and our Oracle tutorials.
Sub Queries (ctd)

Correlated Sub-Queries
As we've seen already, there are two types of sub query: correlated and non-correlated. We've already looked at non-correlated sub queries (see advanced SQL tutorial part 1). All of the examples of sub queries up until now have been non-correlated sub queries. Just like non-correlated sub queries, correlated sub queries are used to answer multi-part questions, but they are most often used to check for existence or absence of matching records in the parent table and the related table in the sub query. A correlated sub query refers to a column from a table in the parent query. As mentioned in part 1 sub-queries (both correlated and non-correlated) and joins are usually interchangeable. However the SQL may be significantly faster when a correlated subquery is used as correlated sub queries refer to a column from their parent queries, they are executed once per row in the parent query whereas non-correlated sub queries are executed once for the whole statement. For example, using the emp and dept tables from before, to find out which departments have no employees assigned to them, we can write the SQL statement in 3 different ways - as a non-correlated sub query, as an outer join, or as a correlated sub-query.
Example 1 - non-correlated sub query

SELECT dept.name FROM dept WHERE dept.id NOT IN ( SELECT dept_id FROM emp
WHERE dept_id IS NOT NULL )
Example 2- outer join

SELECT dept.name FROM dept,emp WHERE emp.dept_id (+) = dept.id
Example 3 - correlated sub query

SELECT dept.name FROM dept WHERE NOT EXISTS (SELECT dept_id FROM emp WHERE emp.dept_id = dept.id) The second example is an outer join SQL statement which may produce differnt reults to the other 2 queries as it returns both matching rows and the non-matching rows on one side of the join. In this case the query would return the names of departments which have no employees assigned to them plus the names of those departments that do have employees assigned to them. The first and the third SQL statements would produce exactly the same results, but the first would probably be slower than the third if the dept_id column in the emp table were indexed (depending on the sizes of the tables). The first SQL statement can not use any indexes - the where clause of the sub query is just checking for NOT NULL rows - so a full table scan would be performed. Also the sub query would be executed once for each row in the dept table. On the other hand, the sub query in the third example can use the index and since only the dept_id is returned by the sub query, there is no need for any subsequent table access. For these reasons, the third query would normally perform better than the first. As you can see there are nearly always several ways in which the SQL for a query may be written, and it is therefore best to try alternative SQL statements particularly for complex queries before deciding on the preferred one. This advanced SQL tutorial only touched on performance tuning which is a whole subject in itself. For more help on Oracle performance tuning and other aspects of Oracle see the oracle tips and tricks section and see our Oracle resources section for book reviews and links to other excellent Oracle resources. ---------------------------------------
Looking for Oracle training?

For Oracle training with experienced consultants on site or off-site at training centres throughout the UK contact us with your requirements or click on the link for the schedules, prices and course outlines for our Oracle SQL and PL/SQL training courses Looking for more Oracle tips and tricks? For no frills, no fluff, just solid, reliable technical information, take a short cut now and subscribe to our ezine. Jam-packed full of tips and tricks, it should save you hours searching for information and help you to keep your Oracle systems running smoothly and efficiently. Subscribe today and your first issue will soon be winging its way to your mailbox. Return from advanced sql tutorial to Oracle tips and tricks
Training Overview Oracle Training UNIX Training Oracle Financials Solaris Red Hat Linux AIX HP-UX MySQL & PHP
Introduction to Oracle Introduction to SQL Advanced SQL Oracle 8 Oracle 9i Oracle 10g Oracle Performance Tuning PL/SQL More free guides and tutorials Oracle UNIX Linux
For Better, Faster, Smarter SQL Tutorials

This is part 3 of our advanced SQL tutorial focusing on the design of more complex SQL statements and sub queries in particular. Part1 introduced sub-queries and looked at noncorrelated sub-queries. Part 2 looked at the uses of sub-queries. This part will look at
nested sub queries, sub-queries in the from clause and sub-queries that return no rows and part 4 covers correlated sub-queries. Performance issues are not thoroughly explored even though this is an advanced sql tutorial as that subject is covered by another series of articles - Oracle Performance Tuning.
Sub Queries (ctd)
Nested Sub-Queries
The SQL syntax allows queries to be nested, meaning that a sub query itself can contain a sub query, enabling very complex queries to be built as there is no syntacttical limit to the level of besting. However, very complex queries should be avoided as they are difficult to understand and to maintain and may not perform that well either. For example, the SQL statement to find the departments that have employees with a salary higher than the average employee salary could be written as: SELECT name FROM dept WHERE id IN ( SELECT dept_id FROM emp WHERE sal > (SELECT avg(sal)FROM emp) ) Any of the other comparison operators instead of '=' or 'IN' such as '>', or '<' can also be used with a sub query.
Sub Queries In The From Clause

The examples so far in this advanced SQL tutorial all had sub queries in the where clause, but sub queries can also be used in the from clause instead of a table name. In these circumstances the sub query acts as if it had been predefined as a view. For example, the following SQL statement returns the amount of used space, the free space and the total allocated space for all tablespaces in a database. SELECT ts.tablespace_name ,ROUND(fs.mbytes,2) "Free (Mbytes)" FROM dba_tablespaces ts ,( SELECT tablespace_name ,SUM(bytes)/1024/1024 mbytes FROM dba_free_space GROUP BY tablespace_name ) fs WHERE ts.tablespace_name = fs.tablespace_name Note that the sub query is given an alias so that results can be used in the main body of the query.
Sub Queries That Return No Rows

Up until now the queries shown have all been expected to produce a result, but when creating tables, it can be very useful to write the SQL to use a sub query which will not return any rows - when just the table structure is required and not any of the data. In the following example we create a copy of the policy table with no rows: CREATE TABLE new_policy AS SELECT * from policy WHERE 1=0; The sub query returns no data but does return the column names and data types to the 'create table' statement. Click on the link to continue this advanced SQL tutorial and learn about correlated subqueries. Return from advanced sql tutorial to Oracle tips and tricks --------------------------------------Looking for more Oracle tips and tricks? For no frills, no fluff, just solid, reliable technical information, take a short cut now and subscribe to our ezine. Jam-packed full of tips and tricks, it will help you make your Oracle systems faster and more reliable and save you hours searching for information. Subscribe today - there's no charge - and your first issue will soon be winging its way to your mailbox.
For fast, high quality technical support, call 0845 0031320, fill in the form to have one of our consultants call you or go to our Oracle support page for more info.
For Better, Faster, Smarter, Oracle Training and Consultancy

A Short Oracle Tutorial For Beginners
Introduction
This is just a brief Oracle tutorial for beginners, to provide a short history of databases and Oracle's role in them, explain relational theory and give you an idea on how relational databases work with a few examples. There is also a very brief discussion of object-oriented design as it applies to databases.
Time and space don't permit an in-depth
discussion of all the features available in Oracle, but if you would like to learn more just contact us and ask for our free Oracle tutorial mini-course.
History of Databases - From Trees To Objects

The storage and management of data is probably the biggest headache for all businesses. It has been so for a long while and is likely to continue for a long while too. As companies try to store more and more details about their customers and their buying habits and as regulatory requirements for storing more data for longer, so companies will need to store and manage more and more data. The only way this can be done at a reasonable cost is by the use of computers. In the late 1960s/early 1970s, specialised data management software appeared - the first database management systems (DBMS). These early DBMS were either hierarchical (tree) or network (CODASYL) databases. These early systems were very complex and inflexible and so it adding new applications or reorganising the data was very difficult and time-consuming. In 1970 the relational data model was defined by E.F. Codd (see "A Relational Model of Data for Large Shared Data Banks" Comm. ACM. 13 (June 6, 1970), 377-387). This delivered a solution to the problems of tree and network databases due to the concept of normalisation which involves the separation of the logical and physical representation of data. In 1974 IBM started a project called System/R to prove the theory of relational databases. This led to the development of a query language called SEQUEL (Structured English Query Language) later renamed to Structured Query Language (SQL) for legal reasons and now the query language of all databases. In 1978 a prototype System/R implementation was evaluated at a number of IBM customer sites. By 1979 the project finished with the conclusion that relational databases were a feasible commercial product.
IBM's research into relational databases had also come to the attention of a group of engineers in California who were so convinced of the potential that they formed a company called Relational Software, Inc. in 1977 to build such a database. Their product was called Oracle and the first version for VAX/VMS was released in 1979, thereby becoming the first commercial rdbms, beating IBM to market by 2 years. In the 1980s the company was renamed to Oracle Corporation. Throughout the 1980s, new features were added and performance improved as the price of hardware came down and Oracle became the largest independent rdbms vendors. By 1985 they boasted of having more than 1000 installations. As relational databases became accepted, companies wanted to expand their use to store images, spreadsheets, etc. which can't be described in 2-dimensional terms. This led to the Oracle database becoming an object-relational hybrid in version 8.0, i.e. a relational database with object extensions, enabling you to have the best of both worlds. This Oracle tutorial continues in part 2 with an explanation of relational databses including a few examples. Oracle tutorial part 2 --------------------------------------Looking for more Oracle tutorials? Suggestions for further reading, book reviews and links to other resources for information about Oracle are available from the resources section. For links to other articles and tutorials on SQL, PL/SQL and Oracle go to Oracle Tips & Tricks. Looking to sky-rocket productivity, save time and reduce costs? Training is a highly cost-effective, proven method of boosting productivity. Click here for details of our scheduled Oracle training courses or let us know your requirements. Oracle secrets revealed! Subscribe to our ezine, jam-packed full of tips and tricks to help you slash costs, sky-rocket productivity and incrase your return on investment. So Subscribe today and your first issue will soon be winging its way to your mailbox. Return from Oracle tutorial to home page
Smartsoft Computing Ltd Bristol Tel: 0845 0031320 Contact Us
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Search
For Better, Faster, Smarter, Oracle Training and Consultancy

A Short Oracle Tutorial For Beginners (ctd)
What is a relational database?
As mentioned before, a relational database is based on the separation and independence of the the logical and physical representations of the data. This provides enormous flexibility and means you can store the data physically in any way without affecting how the data is presented to the end user. The separation
of physical and logical layers means that you can change either layer without affecting the other. A relational database can be regarded as a set of 2-dimensional tables which are known as "relations" in relational database theory. Each table has rows ("tuples") and columns ("domains"). The relationships between the tables is defined by one table having a column with the same meaning (but not necessarily value) as a column in another table. For example consider a database with just 2 tables : emp(id ,name ,job_title ,dept_id number varchar2(30) varchar2(20) number)
holding employee information and dept(id number ,name varchar2(30)) holding department information. There is an implied relationship between these tables because emp has a column called dept_id which is the same as the id column in dept. In Oracle this is usually implemented by what's called a foreign-key relationship which prevents values being stored that are not present in the referenced table. Relational databases obtain their flexibility from being based on set theory (also known as relational calculus) which enables sets or relations to be combined in various ways, including:
join/intersection union (i.e. the sum of 2 sets); exclusive "OR" (i.e. the difference between 2 sets) and outer-join which is a combination of intersecting and exclusive or ing.
The intersection or join between 2 sets (in this case, tables) produces only those elements that exist in both sets. Therefore, if we join Emp and Dept on department id, we will be left with only those employees who work for a department that is in the dept table and only those departments which have employees who are in the emp table. The union produces the sum of the tables - meaning all records in Emp and all records in Dept. and this may be with or without duplicates. Let's use the following data to provide specific examples: Emp Id 1 2 3 4 5 6 Name Dept Id Bill Smith 3 Mike Lewis 2 Ray Charles 3 Andy Mallory 4 Mandy Randall 6 Allison White 1
Dept Id 1 2 3 4 5 Name HR IT Marketing Sales Finance
The join of Emp and Dept. on the department id would produce the following result: Emp.Id Emp.Name 1 Bill Smith 2 Mike Lewis 3 Ray Charles 4 Andy Mallory 6 Allison White Dept.Id Dept.Name 3 Marketing 2 IT 3 Marketing 4 Sales 1 HR
The union of Emp and Dept. would produce the following results Id 1 2 3 4 5 1 2 3 4 5 Name Bill Smith Mike Lewis Ray Charles Andy Mallory Mandy Randall HR IT Marketing Sales Finance
The union operator is only allowed when the number and data types of the columns in the 2 sets are the same. It is not normally be used to combine sub sections from one or more tables rather than entire tables. There are other operators and variations but there isn't the space or the time to provide full details in this short Oracle tutorial. The later versions of Oracle (Oracle 8 onwards) support both relational and objectoriented features. The relational features are more prominent at the moment, but this is beginning to change. In this context an object has both attributes and methods (programs
stored with the object that performs a certain action or task) and in a true object-oriented database would belong to a class and would allow multilevel inheritance. Click here for more Oracle Tutorials Oracle tutorial part1
--------------------------------------Looking to sky-rocket productivity, save time and reduce costs? Training is a highly cost-effective, proven method of boosting productivity. Click here for details of our scheduled Oracle training courses or let us know your requirements. Oracle secrets revealed! Subscribe to our ezine, jam-packed full of tips and tricks to help you slash costs, sky-rocket productivity and incrase your return on investment. Subscribe today and your first issue will soon be winging its way to your mailbox.
Smartsoft Computing Ltd Bristol Tel: 0845 0031320 Contact Us
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Search
For Better, Faster, Smarter, Oracle Solutions

Oracle Training - Tips and Tricks To Make Your Oracle Systems Your Most Valuable Asset
Subscribe to our ezine - just go to www.asktheoracle.net/oracle-tips-signup.html The resources section has recommendations for further reading to enhance your knowledge of Oracle and contains links to information on OTN and other places. New subscribers can access Oracle 9i training material here and advice on general Oracle performance tuning here
2. Oracle Questions
From: V.Mahesh - please send me details about constraints in oracle ( table level and column level ) There are 5 different types of constraints available in Oracle NOT NULL, CHECK, UNIQUE, PRIMARY KEY and FOREIGN KEY. All but NOT NULL can be defined at either the table level or the column level. NOT NULL constraints prevent column values being left undefined and so can only be defined at the column level. Example: CREATE TABLE emp(
id NUMBER NOT NULL, dept_id NUMBER, salary NUMBER) The other constraints must be defined at the table level if they apply to more than one column. CHECK constraints can be applied to one or more columns and are used to restrict the range of allowable values for those columns. For example suppose we define an employee table EMP and want to ensure that the id is always positive, we could define it as follows: Learn how to develop your Oracle systems better, faster and smarter with high quality Oracle training from our top consultants . See the Oracle training page for more info or click here for details of our scheduled Oracle courses . CREATE TABLE emp( id NUMBER CONSTRAINT emp_id_non_zero CHECK (id > 0), dept_id NUMBER, salary NUMBER) UNIQUE and PRIMARY KEY constraints are very similar except that a table can have only one primary key (but many unique columns are allowed) and all columns in the primary key must also be NOT NULL. Example: CREATE TABLE sales( invoice_no NUMBER UNIQUE, .. cust_id NUMBER) CREATE TABLE sales( invoice_no NUMBER PRIMARY KEY, .. cust_id NUMBER) FOREIGN KEY constraints are used to define the relationship between one table and another and to prevent orphaned records, thereby ensuring for example that all employees belong to an existing department. Example: CREATE TABLE emp( emp_id NUMBER , dept_id NUMBER, salary NUMBER, CONSTRAINT fk_emp_dept FOREIGN KEY (dept_id) REFERENCES dept(id));
From: Nath, Vivek - I have been doing large inserts in my database and on couple of tables and the system has been degrading by the minute.Can i know some tips and tricks how to manage this and improve the system performance??? There's no a lot of information to go on there, but there are some general things that can be done. If a lot of large inserts have been made, it is possible that the index has become skewed or fragmented and may need rebuilding, but a better solution would be to drop the indexes all together whilst the loading is taking place and re-create them once the load has finished. The same applies to constraints if they are enforced by indexes. You might also want to check the size of the extents that are created to make sure they are the optimal size for the type of application and the operating system you're using. One final check would be to look at the queries that acccess the particular tables - are they using full-table scans when an index read followed by table access by row id would be better or vice versa. For more Oracle performance tuning tips see: http://www.smart-soft.co.uk/Oracle/oracle-tips-and-tricks.htm --------From: shiva shankar - What is the exact definition of normalisation.How many types are there please explain them in detail Normalization is the process of decomposing objects into their constituent parts, removing repeating groups and any items not functionaly dependent on the key. The process was defined by Dr. E.F. Codd in 1970 when he defined the relational (database) model. There are 6 levels of normalization called normal forms (abbreviated NF): 1st normal form (1NF); 2nd normal form 2NF; 3rd normal form (3NF); Boyce-Codd normal form (BCNF); 4th normal form (4NF); and 5th normal form (5NF). Each is a refinement of the previous normal form, although it is very rare to progress beyond 3NF. It should be stressed that normalization is an analysis tool, not a programming tool, so in practice most databases will be denormalized to a certain extent to improve performance. The trade off is redundant storage of information. --------From: "Manish" - how to see all the indexes created on a particular table? how to view all the indexes in a tablespace? To see all the indexes created on a particular table you need to query all_indexes specifying the name of the table of interest as follows: SELECT index_name FROM all_indexes WHERE table_name = 'EMP';
To see all the indexes in a particular tablespace you just have to query all_indexes specifying the name of the tablespace of interest as follows: SELECT index_name FROM all_indexes WHERE tablespace_name = 'USERS'; ---------
From: Bill Rowe - I read your articles on optimizing views and wondered what the differences between cursors in packages and views might be. I've been reading Feuerstein's O'Reilly books on PL/SQL and wonder if a cursor would work as well as a view, if the cursor were in a package specification. This is an interesting question. On one level, views and cursors are completely different: cursors are defined in PL/SQL and views are defined in the database, but a more fundamental level they are very similar - they are both pre-compiled queries so they could be used in similar ways. However using views would provide more flexibility, they can be combined into other queries which you could not do with cursors, they can also be used for database updates which again you could not do with a cursor. The answer, therfore, is that a cursor would work as well as a view if you only need to use it for querying the database and you don't want to combine the view with other queries. --------From: Hrishikesh Srivatsa - I have a question regarding a SQL query. There is an employee table emp which has 3 fields namely EmpNo (Employee number) EmpName (Employee name) MgrEmpNo (Employee's manager No). The CEO's Employee Manager No can be assumed to be null or a special value. A query has to be written to display the organization's heirarchy. The answer to this is to use the hierarchical query clause of the select statement - i.e. use the connect by prior keyword to indicate the relationship between the parent and child columns and the start with keywords to indicate the root of the tree. In this example, the query would be : SELECT EmpName FROM emp CONNECT BY PRIOR EmpNo = MgrEmpNo START WITH MgrEmpNo IS NULL;
--------------------------------------Looking for more Oracle tips and tricks ? If you're looking for no frills, no fluff, just solid, reliable technical information, take a short cut now and subscribe to our ezine. Published monthly, it's jam-packed full of tips and tricks to help you make more of your Oracle systems and save you hours of blood, sweat and tears searching for information. Subscribe today - there's no charge - and your first issue will soon be winging its way to your mailbox. Send us your questions and we'll answer them in the next newsletter.

This Was Intended To Be A List of Hints and Tips That You Might Find Useful When Using SQ

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

This Was Intended To Be A List of Hints and Tips That You Might Find Useful When Using SQ

Caricato da

Copyright:

Formati disponibili

This was intended to be a list of hints and tips that you might find useful when using SQ,L

Use Stored Procedures

Use Bind Variables

For Better, Faster, Smarter, Oracle Solutions

4. Use Selective Indexes

5. Use Full-Table Scans

7. Name The Columns In A Query

Copyright Smartsoft Computing Ltd 2001-2009. All rights reserved.

For Better, Faster, Smarter, SQL Tutorials

Learn more about Oracle performance tuning here.

Non Correlated Sub-Queries

For Better, Faster, Smarter SQL Tutorials

Uses of Sub Queries

parts of the query. Specifically, sub queries can be used:

the FROM clause of SELECT statements

For Better, Faster, Smarter, SQL Tutorials

You might also be interested in our beginner's SQL tutorial,

our PL/SQL tutorials and our Oracle tutorials.

Sub Queries (ctd)

Example 1 - non-correlated sub query

WHERE dept_id IS NOT NULL )

Example 2- outer join

Example 3 - correlated sub query

Looking for Oracle training?

For Better, Faster, Smarter SQL Tutorials

Sub Queries (ctd)

Sub Queries In The From Clause

Sub Queries That Return No Rows

For Better, Faster, Smarter, Oracle Training and Consultancy

Time and space don't permit an in-depth

History of Databases - From Trees To Objects

Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

Copyright Smartsoft Computing Ltd 2001-2009. All rights reserved.

For Better, Faster, Smarter, Oracle Training and Consultancy

What is a relational database?

Dept Id 1 2 3 4 5 Name HR IT Marketing Sales Finance

Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

Copyright Smartsoft Computing Ltd 2001-2009. All rights reserved.

For Better, Faster, Smarter, Oracle Solutions

Potrebbero piacerti anche