I've been told that if I foreign key two tables, that SQL Server will create something akin to an index in the child table. I have a hard time believing this to be true, but can't find much out there related specifically to this.
My real reason for asking this is because we're experiencing some very slow response time in a delete statement against a table that has probably 15 related tables. I've asked our database guy and he says that if there is a foreign key on the fields, then it acts like an index. What is your experience with this? Should I add indexes on all foreign key fields or are they just unnecessary overhead?
A foreign key is a constraint, a relationship between two tables - that has nothing to do with an index per se.
However, it makes a lot of sense to index all the columns that are part of any foreign key relationship. An FK-relationship will often need to look up a relating table and extract certain rows based on a single value or a range of values.
So it makes good sense to index any columns involved in an FK, but an FK per se is not an index.
Check out Kimberly Tripp's excellent article "When did SQL Server stop putting indexes on Foreign Key columns?".
Wow, the answers are all over the map. So the Documentation says:
A FOREIGN KEY constraint is a candidate for an index because:
Changes to PRIMARY KEY constraints are checked with FOREIGN KEY constraints in related tables.
Foreign key columns are often used in join criteria when the data from related tables is combined in queries by matching the column(s) in the FOREIGN KEY constraint of one table with the primary or unique key column(s) in the other table. An index allows Microsoft® SQL Server™ 2000 to find related data in the foreign key table quickly. However, creating this index is not a requirement. Data from two related tables can be combined even if no PRIMARY KEY or FOREIGN KEY constraints are defined between the tables, but a foreign key relationship between two tables indicates that the two tables have been optimized to be combined in a query that uses the keys as its criteria.
So it seems pretty clear (although the documentation is a bit muddled) that it does not in fact create an index.
No, there is no implicit index on foreign key fields, otherwise why would Microsoft say "Creating an index on a foreign key is often useful". Your colleague may be confusing the foreign key field in the referring table with the primary key in the referred-to table - primary keys do create an implicit index.
Foreign keys do not create indexes. Only alternate key constraints(UNIQUE) and primary key constraints create indexes. This is true in Oracle and SQL Server.
In PostgeSql you can check for indexes yourself if you hit \d tablename
You will see that btree indexes have been automatically created on columns with primary key and unique constraints, but not on columns with foreign keys.
I think that answers your question at least for postgres.
Say you have a big table called orders, and a small table called customers. There is a foreign key from an order to a customer. Now if you delete a customer, Sql Server must check that there are no orphan orders; if there are, it raises an error.
To check if there are any orders, Sql Server has to search the big orders table. Now if there is an index, the search will be fast; if there is not, the search will be slow.
So in this case, the slow delete could be explained by the absence of an index. Especially if Sql Server would have to search 15 big tables without an index.
P.S. If the foreign key has ON DELETE CASCADE, Sql Server still has to search the order table, but then to remove any orders that reference the deleted customer.
SQL Server autocreates indices for Primary Keys, but not for Foreign Keys. Create the index for the Foreign Keys. It's probably worth the overhead.
It depends. On MySQL an index is created if you don't create it on your own:
MySQL requires that foreign key columns be indexed; if you create a table with a foreign key constraint but no index on a given column, an index is created.
Source: https://dev.mysql.com/doc/refman/8.0/en/constraint-foreign-key.html
The same for MySQL 5.6 eh.
Strictly speaking, foreign keys have absolutely nothing to do with indexes, yes. But, as the speakers above me pointed out, it makes sense to create one to speed up the FK-lookups. In fact, in MySQL, if you don't specify an index in your FK declaration, the engine (InnoDB) creates it for you automatically.
Not to my knowledge. A foreign key only adds a constraint that the value in the child key also be represented somewhere in the parent column. It's not telling the database that the child key also needs to be indexed, only constrained.
I notice that Entity Framework 6.1 pointed at MSSQL does automatically add indexes on foreign keys.
Related
I am using SQL Server 2012 and for one of the table I see it has created primary key non-clustered (composite key) and clustered index on different column? Can somebody help me to understand what will happen in this situation?
Does this going to degrade performance for DML operations? If yes how to measure it?
Will this be causing locking/blocking/deadlocks for this table when performing DML operation during concurrency ?
Note: this table has a huge number of records in it ~10 million
One common scenario where you might end up with a primary key which is a non clustered composite key is a junction table. A junction table mainly exists to store a relationship between two primary key values from other tables. A simple example would be storing say relationships between students and the courses they take. As such, the primary (unique) key in such a table would actually be the combination of the two foreign key columns. That being said, there can still be a clustered index on some other column. There is nothing at all out of the ordinary here, assuming such a table falls in line with your design intentions.
I have used natural keys of transactional tables as primary keys but I was told to use surrogate key as a primary key. But this table has a dependent child table. I want to know what is the best practice to choose primary key of a table, when it has a child table- between natural key vs surrogate key.
If surrogate key is preferred, how would I derive this surrogate key into child table to make a foreign key relationship? I know we do this is in Data warehousing environment to load dimension tables first and then fact tables by doing the look up on the dimension table keys.
Please give me your inputs on what is the best approach for transactional relational database design?
I appreciate your help in this regard.
Thank you!
Varun
In Microsoft SQL Server there is no great difference between a key defined as PRIMARY KEY and a key defined as a UNIQUE constraint. Therefore there is no special advantage to making the primary key a surrogate.
A disadvantage to having a surrogate key referenced by a foreign key constraint is that you will usually need extra joins and lookups in code. Because any searches will usually be based on the natural key(s) you will need an extra join - or at least an extra index seek operation - to find the surrogate key value first. You will typically need to do that kind of lookup or join whenever you want to modify referencing rows in a child table.
If you insert rows to the child table immediately after inserting to the parent table then there you can retrieve the surrogate values without any extra operation. If the surrogate is an IDENTITY column you can use the SCOPE_IDENTITY function to retrieve the last-inserted value. Alternatively, you can also use the OUTPUT clause on an INSERT statement to retrieve the inserted values - useful when you are inserting more than one row.
So i have a table in which i have a column named parentKey. And this column has actually keys (which by definition are foreign keys) to MANY other tables (at least 4). And it seems strange to me to even create a column like this. I haven't yet seen a construction of a table that had this. Because you can't add a foreign key constraint since the column doesn't link to one single table. So i don't know is this is allowed to exist. I mean it's there it is created but i'm not sure if i should let it like this.
My idea is to create a column for each of the possible tables and name it correctly like : MyTable1Key, MyTable2Key and let them be foreign keys. But the problem with that is that if one of the foreign keys is assigned then the other ones will be null (And it will never be assigned so it will always stay null).
So do i have to let this parentKey column like it is or should i split it to different columns linked to tables by foreign keys and so have null values for some columns?
Unless you have a good reason, do not combine multiple foreign keys into a single column. As you've already noted it removes the referential integrity of your foreign key.
Either you will risk having a key which could belong to two tables or you have a master table somewhere that you should use as your foreign key reference. It is possible to have a primary key as a foreign key.
It sounds like you may be looking at the supertype-subtype pattern in which case this question might give you some good ideas. How do I apply subtypes into an SQL Server database?
What meaning does the concept of a primary key have to the database engine of SQL Server? I don't mean the clustered/nonclustered index created on the "ID" column, i mean the constraint object "primary key". Does it matter if it exists or not?
Alternatives:
alter table add primary key clustered
alter table create clustered index
Does it make a difference?
In general, a KEY is a column (or combination of columns) that uniquely identifies each row in the table. It is possible to have multiple KEYs in a table (for example, you might have a Person table where both the social security number as well as an auto-increasing number are both KEYs).
The database designer chooses one of theses KEYs to be the PRIMARY KEY. Conceptually, it does not matter which KEY is chosen as the PRIMARY KEY. However, since the PRIMARY KEY is usually used to refer to entries in this table from other tables (through FOREIGN KEYs), choosing a good PRIMARY KEY can be relevant w.r.t. (a) performance and (b) maintainability:
(a) Since the primary key will usually be used in JOINs, the index on the primary key (its size, its distribution, ...) is much more relevant to performance than other indexes.
(b) Since the primary key is used as a foreign key in other tables, changing the primary key value is always a hassle, since all the foreign key values in the other tables need to be modified as well.
A PRIMARY KEY is a constraint - this is a logical object that says something about the rules that your data must adhere to. An index is an access structure - it says something about the way the machine can search through the data. To implement a PRIMARY KEY, most RDBMS-es use an index.
Some RDBMS-es (fe. MySQL) do not make the distinction between PRIMARY KEY or UNIQUE constraint and the index that is used to help implement it. But for example, Oracle does: in oracle you can do something like: ALTER TABLE t DROP pk KEEP INDEX. This is useful if you want to change the definition of the primary key (for example, you are replacing a natural primary key with a surrogate primary key) but you still want to have a unique constraint on the original primary key columns without rebuilding the index. That makes sense if the index is very large and would take considerable table and resources to rebuild.
From what I can see, MS SQL does not make the distinction. I mean a tool like Management studio does display "Keys", "Indexes" and "Constraints" in differrent folders, but changing the name of one immediately changes the name of the corresponding objects in the other folders. So I think here the distinction is not really present in this case.
I have two tables 'Elements' and 'Lists'
Lists has a primary key and a list name.
Elements has data pertaining to an individual entry in the list.
Elements needs a column that holds which list the element is in.
I've read about SQL's foreign key constraint and figure that is the best way to link the tables, but I'm using SQLite which doesn't enforce the foerign key constraint.
Is there a point to declaring the foreign key constraint if there is no enforcement?
It's always good to do, even if your database doesn't enforce the constraint (old MySQL, for instance). The reasoning for this, is that someday, someone will try reading your schema (perhaps even yourself).
If you can't use the new version, you can still declare the constraint and enforce it with triggers. In either case, I wouldn't omit the notation. It's far too helpful.
Nowadays sqlite enforces foreign keys, download the new release.
A foreign key is a field (or fields)
that points to the primary key of
another table. The purpose of the
foreign key is to ensure referential
integrity of the data. In other words,
only values that are supposed to
appear in the database are permitted.
It only enforces the "business rule". If you require this from the business side, then yes, it is required.
Indexing will not be affected.
You can still create indexes as requred.
Have a look at Foreign Key
and
Wikipedia Foreign key