Does Oracle automatically create a secondary index for FOREIGN KEY columns? - performance

I'm currenly developing on Oracle. I have several tables for which I defined FOREIGN KEY constraints. I have already read this SQL Server-oriented and this MySQL-oriented questions but I could find none about Oracle.
So the question is always the same: in order to optimize query performance, for those columns for which I create a FOREIGN KEY constraint, do I also have to create an explicit secondary index? Doesn't Oracle automatically create an index on FOREIGN KEYed columns to boost performances during JOINs?
I usually perform queries in which the WHERE clause compare against those columns.

No, Oracle doesn't automatically create indexes on foreign key columns, even though in 99% of cases you probably should. Apart from helping with queries, the index also improves the performance of delete statements on the parent table.

Related

How to migrate Tarantool tables in the presence of foreign keys?

I want to migrate a Tarantool table to a different format. Currently (Tarantool 2.8), this must be done manually, by creating a new table, copying the data over, dropping the old table and renaming the new table to the old name. That also means dropping all foreign keys referencing the old table and creating new ones. But an unrelated limitation is that I can't create foreign keys on tables unless those tables are also empty.
Is there any way to solve this other than just not using foreign keys at all?
EDIT: I suppose I could emulate FKs with triggers. Are there any limitations with triggers that would make such emulation impossible?

Replace foreign key column with compressed index

I would like to spare some tables in my database.
One table for example has a simple Primary-Key-ID column and a VARCHAR2 column.
The VARCHAR2 column has NO duplicate values, yet different unique IDs.
The PK column of this table is just referenced once as a foreign key in another table.
My thoughts are now to insert the values from the VARCHAR2 column into the the table which has held the primary key.
I could now remove the foreign key reference, delete the table and gain a new column with all the (duplicate) VARCHAR2 values. These I would like to compress in a unique/distinct way.
I have heard about index in the Oracle Database to compress column(s) but I am not quite sure which index I need or how to use them...
The underlying feature (and storage savings) should be about as the same as it was with the previous table of unique values and the foreign key reference.
Thank you for your help in advance!
Oracle basic compression allows us to compress tables. It comes with several distinct limitations, not the least of which is that it isn't suitable for OLTP databases. Direct path inserts, updates and deletes don't benefit. So you can't do what you want that way. If your organisation has sprung for the Advanced Compression licence then you have more options, but the compression still works on the table not an individual column.
I think you've confused things with index compression, which does operate on columns, as it allows us to compress the leading column(s) of a compound index. But it's worth applying only when there's a lot of repetition in those columns. If your index has a unique ID for the leading column than compression will actually increase the total amount of space taken. (Just one reason why compound indexes should be built with the least selective column first and the most selective column last.)
Your table is a classic key-value lookup table. So you could consider converting it into an index-organized table. You would save yourself a bit of space by maintaining only a specialized index instead of a table and its primary key index. Find out more

Foreign key limitations

I am wondering if a PL/SQL (oracle) table can carry three foreign keys? thanks in advance if any one can help me in this regard.
There is no explicit limit on the number of foreign keys on a table. However, there is a limit of 1000 columns per table, so that probably constitutes a practical limit.
Here is a SQL Fiddle which creates a toy table with five foreign keys.
There is not limit on foreign keys use except logic which based behind use of foreign keys, and if one table needs too much foreign keys, which is not logic wise, and database design suffers in such scenario.
As well as 1000-column constraint of oracle tables and pl/sql procedures also have limit in code.

Why a primary key automatically creates a clustered index

When i create a primary key in oracle table, why does it create a 'clustered' index by default. What is the reason for this automatic creation of a clustered index on creation of a primary key? is it just the Oracle designer's preference that he designed oracle in this way?
Oracle will create an index to police an unique constraint where no pre-existing index is suitable. Without the index, Oracle would need to serialize operations (such as a table lock) whenever someone tries to insert or delete a row (or update the PK).
Contrarily to MS-SQL Server, this index is not clustered on heap tables (default table organization), i.e. this index won't change the underlying table structure and natural order. The rows won't be reordered when Oracle creates the index. The index will be a B-tree index and will exist as a separate entity where each entry points to a row in the main table.
Oracle doesn't have clustered index as MS SQL, however indexed-organized tables share some properties with cluster-indexed tables. The PK is an integral part of such tables and has to be specified during creation.
(Oracle also has table clusters, but they are a completely different concept).
Creating Index is basic functionality of Primary key, it is also in SQL Server and MySQL, Clustered Index makes your searches faster.
The Database Engine automatically creates a unique index to enforce the uniqueness of the PRIMARY KEY constraint. If a clustered index does not already exist on the table or a nonclustered index is not explicitly specified, a unique, clustered index is created to enforce the PRIMARY KEY constraint.
Read this:
http://www.sqlskills.com/blogs/kimberly/the-clustered-index-debate-continues/

Linq insert with no primary key

I need to insert records into a table that has no primary key using LINQ to SQL. The table is poorly designed; I have NO control over the table structure. The table is comprised of a few varchar fields, a text field, and a timestamp. It is used as an audit trail for other entities.
What is the best way to accomplish the inserts? Could I extend the Linq partial class for this table and add a "fake" key? I'm open to any hack, however kludgey.
LINQ to SQL isn't meant for this task, so don't use it. Just warp the insert into a stored procedure and add the procedure to your data model. If you can't do that, write a normal function with a bit of in-line SQL.
Open your DBML file in the designer, and give the mapping a key, whether your database has one or not. This will solve your problem. Just beware, however, that you can't count on the column being used for identity or anything else if there isn't a genuine key in the database.
I was able to work around this using a composite key.
I had a similar problem with a table containing only two columns: username, role.
This table obviously does not require an identity column. So, I created a composite key with username and role. This enabled me to use LINQ for adding and deleting entries.
You might use the DataContext.ExecuteCommand method to run your own custom insert statement.
Or, you might add a primary key to a column, this will allow the objects to be tracked for inserts/updates/deletes by the datacontext. This will work even if the column isn't really an enforced primary key in the database (how would linq know?). If you're only doing inserts and never re-use a primary key value in the same datacontext, you'll be fine.

Resources