There's a couple of tables that I need to use columns from in the select statement. the questions is: Create a View to display the employee id, first name and surname. In your query include the coin price and a 10% commission for the sales made by the employees.
the difficult part for me is that employees of the same employee number, can make multiple coin sales, so in the view, i need to be able to add all the coin sales together of each respective primary key (employee_id)
As you can see in this image, emp101 has sold two different coins, with the coin_id's of "7116" and "7112". In the view i want to be able to somehow tally each coin value that each employee_id has sold if that makes sense ?
There's multiple other tables, but there's too many to send, so i am just trying to get a general idea of how to do this. I understand the logistics of the question, i just dont know how to implement the answer with the correct syntax and methods etc...
Since this appears to be a homework question, here is a discussion of how to solve it:
You want to CREATE a VIEW and give the view a name (something like employee_commisions) and include 5 columns (employee_id, first_name, surname, coin_price and commission - or maybe only 4 columns if they want the combined price plus commission).
To get the values for that view, you want to SELECT ... FROM existing tables; however, your image does not include first_name, surname or a value for a coin so I am assuming that you will have an employees table and a coins table that you will need to INNER JOIN to the invoice table on their respective primary keys.
To get the total value for the coins, you want to aggregate the values and this would be done with the SUM aggregation function and, so that you get the value for each employee, you would need to GROUP BY the employee_id primary key. You will either need to include the other columns you are not aggregating by in the GROUP BY clause or apply an aggregation function to those columns such as MAX(surname).
The syntax for CREATE VIEW is here.
The syntax for SELECT is here.
I need to partition a big Hive Table based on customer identifier (account number like 12345678).
In particular, I am looking for a function that gets customer_id and then converts it into a numerical value like 0-9 so it becomes my partition. By doing so, I have 10% of my customers in each partition.
for example, f('123455') returns 4
Appreciate hint
clustered Index- id
non-clustered index- salary
select ename from employee where id=100 and salary>5000;
I want to know, Which one will get highest priority in oracle.
Index unique scan or index range scan.
Please give suggestion.
The clustering has little to do with the selection. The issue is which is more selective.
In this case, presumably id is more selective -- meaning that fewer rows match the id condition than the salary condition.
If you want to optimize the indexes for this query, then the best index is on (id, salary, ename).
I have a large table of 7 column in Oracle 11G. Total size of the table is more than 3GB and total row in this table is 1876823. Query we are using
select doc_mstr_id from index_mstr where page_con1 like('%sachin%') it is taking almost a minute. please help me to optimize the query as well as proper indexing for this table. Please let me know if partitioned is required for this table.
Below are the column description
INDEX_MSTR_ID NUMBER
DOC_MSTR_ID NUMBER
PAGE_NO NUMBER
PAGE_PART NUMBER
PAGE_CON1 VARCHAR2(4000)
FILE_MODIFIED_DATE DATE
CREATED_DATE DATE
This query is always going to result in a full table scan. Your only filter cannot use a B-TREE index, due to the leading wildcard:
where page_con1 like('%sachin%')
If you want to do lots of queries of this nature you need to build a Text index on that column. From its datatype page_con1 appears to hold text fragments rather than full documents so you should use a CTXCAT index. This type of index has the advantage of being transactional, rather than requiring background maintenance. Find out more.
Your query would then look like this:
select doc_mstr_id from index_mstr
WHERE CATSEARCH(page_con1, 'sachin') > 0;
I recently was reading about Oracle Index Organized Tables (IOTs) but am not sure I quite understand WHEN to use them. So I have a small table:
create table categories
(
id VARCHAR2(36),
group VARCHAR2(100),
category VARCHAR2(100
)
create unique index (group, category, id) COMPRESS 2;
The id column is a foreign key from another table entries and my common query is:
select e.id, e.time, e.title from entries e, categories c where e.id=c.id AND e.group=? AND c.category=? ORDER by e.time
The entries table is indexed properly.
Both of these tables have millions (16M currently) of rows and currently this query really stinks (note: I have it wrapped in a pagination query also so I only get back the first 20, but for simplicity I omitted that).
Since I am basically indexing the entire table, does it make sense to create this table as an IOT?
EDIT by popular demand:
create table entries
(
id VARCHAR2(36),
time TIMESTAMP,
group VARCHAR2(100),
title VARCHAR2(500),
....
)
create index (group, time) compress 1;
My real question I dont think depends on this though. Basically if you have a table with few columns (3 in this example) and you are planning on putting a composite index on all three rows is there any reason not to use an IOT?
IOTs are great for a number of purposes, including this case where you're gonna have an index on all (or most) of the columns anyway - but the benefit only materialises if you don't have the extra index - the idea is that the table itself is an index, so put the columns in the order that you want the index to be in. In your case, you're accessing category by id, so it makes sense for that to be the first column. So effectively you've got an index on (id, group, category). I don't know why you'd want an additional index on (group, category, id).
Your query:
SELECT e.id, e.time, e.title
FROM entries e, categories c
WHERE e.id=c.id AND e.group=? AND c.category=?
ORDER by e.time
You're joining the tables by ID, but you have no index on entries.id - so the query is probably doing a hash or sort merge join. I wouldn't mind seeing a plan for what your system is doing now to confirm.
If you're doing a pagination query (i.e. only interested in a small number of rows) you want to get the first rows back as quick as possible; for this to happen you'll probably want a nested loop on entries, e.g.:
NESTED LOOPS
ACCESS TABLE BY ROWID - ENTRIES
INDEX RANGE SCAN - (index on ENTRIES.group,time)
ACCESS TABLE BY ROWID - CATEGORIES
INDEX RANGE SCAN - (index on CATEGORIES.ID)
Since the join to CATEGORIES is on ID, you'll want an index on ID; if you make it an IOT, and make ID the leading column, that might be sufficient.
The performance of the plan I've shown above will be dependent on how many rows match the given "group" - i.e. how selective an average "group" is.
Have you looked at dba-oracle.com, asktom.com, IOUG, another asktom.com?
There are penalties to pay for IOTs - e.g., poorer insert performance
Can you prototype it and compare performance?
Also, perhaps you might want to consider a hash cluster.
IOT's are a trade off. You are getting access performance for decreased insert/update performance. We typically use them for reference data that is batch loaded daily and not updated during the day. This is not to say it's the only way to use them, just how we use them.
Few things here:
You mention pagination - have you considered the first_rows hint?
Is that the order your index is in, with group as the first field? If so I'd consider moving ID to be the first column since that index will not be used.
foreign keys should have an index on the column. Consider addind an index on the foreign key (id column).
Are you sure it's not the ORDER BY causing slowness?
What version of Oracle are you using?
I ASSUME there is a primary key on table entries for field id, correct?
Why the WHERE condition does not include "c.group = e.group" ?
Try to:
Remove the order by condition
Change the index definition from "create unique index (group,
category, id)" to "create unique index (id, group, category)"
Reorganise table categories as an IOT on (group, category, id)
Reorganise table categories as an IOT on (id, group, category)
In each of the above case use EXPLAIN PLAN to review the cost