Improvements in the existing process

Question

Hi All,
We are planning to improve our existing process in terms of DATABASE.
For that my BOSS asked me to start execution. But I am really very strange to this work.
If anyone can give me suggestions atleast, would be really grateful to them.
Like table structure to be changed (unnecessary lengths can be cutoff) etc..
Thanks in Advance..

Answer 1

The next thing that i always try to make sure is that data validation and its relationship are defined in database using constraints. I dont prefer it to be at the application layer.
Oracle is a very inelegant software. More the information you offer to it more robust it becomes.
Here is an example. Consider this table structure.
SQL> create table t (no integer, constraint no_chk check(no <=1000));
Table created.
SQL> insert into t select level from dual connect by level <= 1000;
1000 rows created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(user, 'T')
PL/SQL procedure successfully completed.
If you see the table T, Oracle has the information that the column NO cannot have value that is greater than 1000.
So now i run a query with filtering condition which says no > 1000, see what happens.
SQL> select * from t where no > 1000;
no rows selected
Execution Plan
Plan hash value: 1401356643
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |     3 |     0   (0)|          |
|*  1 |  FILTER            |      |       |       |            |          |
|*  2 |   TABLE ACCESS FULL| T    |     1 |     3 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
   2 - filter("NO">1000)
Statistics
          8  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        164  bytes sent via SQL*Net to client
        232  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed
You could see that a Filter condition NULL IS NOT NULL is added by oracle. This actually makes oracle not to scan the table, you can check the consistent gets in the statistics.
Now lets drop the constraint and see what happens.
SQL> alter table t drop constraint no_chk;
Table altered.
SQL> select * from t where no > 1000;
no rows selected
Execution Plan
Plan hash value: 2153619298
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |      |     1 |     3 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |     3 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("NO">1000)
Statistics
        163  recursive calls
          0  db block gets
         24  consistent gets
          0  physical reads
          0  redo size
        164  bytes sent via SQL*Net to client
        232  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
          0  rows processed
Now you see the consistent gets goes up.
So make it a point to define your data and its relationship by using constraints.