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.
Related
My question is related to the ER-diagram I designed using Oracle SQL developer. I designed this ER-diagram but I don't know how to read the relationships between these tables.
I have created this ER diagram:
ER Diagram
As it can be seen that these relations don't look like those normal one to many or many to one relations. Can anyone please help me how to read the relation between SYS.GENERAL_LEDGER_ACCOUNTS and SYS.INVOICE_LINE_ITEMS? Thanks in advance
The relationship is described by the foreign key:
ALTER TABLE invoice_line_items
ADD CONSTRAINT line_item_fk_accounts
FOREIGN KEY (account_number)
REFERENCES general_ledger_accounts(account_number);
Defines a foreign key with the name line_item_fk_accounts on the column account_number which references the account_number of the general_ledger_accounts.
Assuming that it is notNULL then this is a many-to-one relationship such that each row of invoice_line_items has a relationship to exactly one row in the general_ledger_accounts and there can be many invoice_line_items for each general_ledger_accounts.
Similarly, line_items_fk_invoices is a many-to-one constraint with many invoice_line_items each referencing one row of the invoices table.
Aside: NEVER modify the system schemas. If you do you risk making the database unusable and invalidating any support contract that you have with Oracle. Instead, you should create a user and then work in that schema.
The diagram has over 40 tables, most of them have a primary key defined.
For some reason there is this one table, which has a primary key defined, but that's being ignored when I export the model to a DDL script.
This is the "offending" key (even though it's checked it is nowhere to be found on the generated DDL script):
Has anybody had the same problem? Any ideas on how to solve it?
[EDIT] This is where the key is defined:
And this is the DDL preview (yes, the primary key shows up there):
This is what happens if I try to generate the DDL for just that table (primary key still not generated):
I was finally able to identify and reproduce the problem.
It was a simple conflict of constraints.
Table MIEMBROS had a mandatory 1 to n relationship (foreign key) from another table on its primary key column and vice-versa (there was a foreign key on MIEMBROS against the other table's primary key).
This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table.
Anyway I realized that one of the relationships was 0 to n so I simply unchecked the "mandatory" checkbox on the foreign key definition and everything went fine.
So, in a nutshell: The Data Modeler "fails" silently if you are defining a mutual relationship (two foreign keys, one on each table against the other table) on non nullable unique columns, by not generating the primary key of one of the tables.
Such an odd behavior, if you ask me!
"This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table."
Actually, if you have deferred constraints, this is not impossible. The constraints can be enforced, for example, at commit time rather than immediately at insert time.
From the Data Modeler menu under File, I used Export -> DDL File. The keys appeared in the DDL, then when I went back to the diagram and did DDL Preview, it showed all the missing stuff.
I am using Oracle database and I have a table for customers records and want to put a Unique key constraint on multiple varchar2 columns. like
CUST_ID (Number),
CUST_Name(varchar2),
Cust_N.I.C_NO(varchar2) will make a unique key.
when inserting new record through forms 6i, if ORA-00001 error comes, user will be informed that it was a DUPLICATED record.
Please advise me if there will be any database performance issue when records in this table will exceed 50000 or more.
If this is not a good practice to avoid inserting duplicate records, then please suggest any other approach.
regards.
Unique constraints are enforced though an index. So there are additional reads involved in the enforcement process. However, the performance impact of the constraint is minimal compared to the performance impact incurred by resolving duplicate keys in the database. Not to mention the business impact of such data corruption.
Besides, 50000 rows is a toy-sized table. Seriously, you won't be able to measure the difference of an insert with and without the constraints.
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.
I have a situation like this:
create table a(
a_id number(38) not null,
constraint pk_a primary key (id)
);
create table b(
a_id number(38) not null
);
create index b_a_id_index on b(a_id);
Now b.a_id is in fact meant to be a foreign key referencing a.a_id, but it isn't formally declared as such. Obviously, it should be for integrity reasons. But does a foreign key constraint also improve join performance in general or in specific cases? If yes, for what types of query transformations?
Is there any relevant documentation about this topic?
I'm using Oracle 11g (11.2.0.2.0)
Yes, having foreign key constraints in place can improve query performance. There are various transforms that are open to the optimizer when appropriate foreign key constraints exist that are not generally available. For example, if you were to join A and B but only select data from B, the optimizer could eliminate A from the query plan entirely if there was a foreign key constraint in place (this sort of thing comes in very handy when you've got useful views that join in more tables than your current query strictly needs because you don't have to trade the performance costs of the extra joins against the code reuse from using an existing view). They also come in handy when you're doing things like using things like query rewrite to rewrite a query to use a materialized view in a data warehouse/ DSS type system.
Tom Kyte has a presentation Metadata Matters that talks about how various types of constraints, along with other pieces of metadata, can influence the optimizer.
As Justin already pointed out, JOIN elimination is an essential non-cost based SQL transformation, which can be applied based on the presence of meta data only. I have blogged about this more recently:
JOIN Elimination: An Essential Optimiser Feature for Advanced SQL Usage
10 Cool SQL Optimisations That do not Depend on the Cost Model
As I originally assumed, there are a lot of SQL transformations that depend on meta data, so adding foreign key constraints (and other constraints) definitely can impact performance in a positive way.