We're designing a database in which I need to consider some FK(foreign key)
constraints. But it is not limited to
formal structuring and normalization.
We go for it only if it provides any
performance or scalability benefits.
I've been going thru some interesting articles and googling for practical benefits. Here are some links:
http://www.mssqltips.com/tip.asp?tip=1296
I wanted to know more about the benefits of FK (apart from the formal structuring and the famous cascaded delete\update).
FK are not 'indexed' by default so what are the considerations while indexing an FK?
How to handle nullable fields which are mapped as foreign key - is this allowed?
Apart from indexing, does this help in optimizing query-execution plans in SQL-Server?
I know there's more but I'd prefer experts speaking on this. Please guide me.
Foreign keys provide no performance or scalability benefits.
Foreign keys enforce referential integrity. This can provide a practical benefit by raising an error if someone attempted to delete rows from the parent table in error.
Foreign keys are not indexed by default. You should index your foreign keys columns, as this avoids a table scan on the child table when you delete/update your parent row.
You can make a foreign key column nullable and insert null.
The main benefit is that your database will not end up inconsistent if your buggy client code tries to do something wrong. Foreign keys are a type of 'constraint', so that's how you should use them.
They do not have any "functional" benefit, they will not optimize anything. You still have to create indexes yourself, etc. And yes, you can have NULL values in a column that is a foreign key.
FK constraints keep your data consistent. That's it. This is the main benefit.
FK constraints will not provide you with any performance gain.
But, unless you have denormalized on purpose db structure, I'd recommend you to use FK constraints. The main reason - consistency.
I have read at least one example on net where it was shown that Foreign Keys do improve performance because the optimiser does not have to do additional checks across tables because it knows data meets certain criteria already due to the FK. Sorry I don't have a link but the blog gave detailed output of the query plans to prove it.
As mentioned, they are for data integrity. Any performance "loss" would be utterly wiped out by the time required to fix broken data.
However, there could be an indirect performance benefit.
For SQL Server at least, the columns in the FK must have the same datatype on each side. Without an FK, you could have an nvarchar parent and a varchar child for example. When you join the 2 tables, you'll get a datatype conversions which can kill performance.
Example: different varchar lengths causing an issue
Related
What is the core differences between a table that is created with constraints like PK vs a table created or added indexes created on it only (that don't have PK) when it comes which route would anyone prefer to implement when creating a table? I have work on them but I am just curious to know what separate them Thank you
They are quite different.
Constraints check the data that is being inserted and updated meet some criteria (for example "not null"). If the data does not meet the criteria, the INSERT or UPDATE is rejected, and fails. Constraints help you to maintain the quality of the data.
Indexes improve (most of the time) the speed of a query, and are usually beneficial to SELECT, UPDATE, and DELETE operations. Indexes improve database performance.
An index has no effect on how a query behaves nor the schema definition. It only effects performance. Although some SQL servers implement features using indexes, particularly the unique constraint. The SQL standard doesn't even mention them because they're considered an implementation issue.
A primary key constraint very much does have an effect on behavior and schema definition. It says this column must be unique and not null. Most databases also happen to index it for obvious performance reasons.
Declaring primary key rather than manually saying unique not null also lets the person reading your schema know that this is the primary key. They will know what its purpose it. It also lets the database know this is the primary key which might allow it to do some extra optimizations.
I've read a lot about this issue.. (also read this: Tables with no Primary Key)
it seems like there is no reason to use tables with no PK. so why does PostgreSQL allows it? can you give an example when it's good idea to not indicate PK?
I think the answer to your question lies in trying to understand what are the drawbacks of having a Primary-Key (PK) in the first place.
One obvious 'drawback' (depending on how you see it) in maintaining a PK is that it has its own overhead during an INSERT. So, in order to increase INSERT performance (assuming for e.g. the sample case is a logging table, where Querying is done offline) I would remove all Constraints / PK if possible and definitely would increase table performance. You may argue that pure logging should be done outside the DB (in a noSQL DB such as Cassandra etc.) but then again at least its possible in PostgreSQL.
A primary key is a special form of a unique constraint. A unique constraint is always backed up by an index. And the disadvantage of an index is that it takes time to update. Tables with an index have lower update, delete and insert performance.
So if you have a table that has a lot of modifications, and few queries, you can improve performance by omitting the primary key.
AFAIK, the primary key is primarily needed for the relationships between tables as a foreign key. If you have a table that is not linked to anything you don't need a primary key. In Excel spreadsheets there're no primary keys but a spreadsheet is not a relational database.
I have large table on my database (50 columns and might get to 100,000,000 rows).
Right now my primary key is 8 columns.
It is better to make 1 primary key (automatic number) and add columns unique constrains?
The structure of a database should be driven by how the data is going to be used. One can make a judgement that the structure is normalized or denormalized, for instance. But each of those methodologies is appropriate in different circumstances.
That said, I am heavily biased to having an auto incrementing ("identity") primary key in all tables. This is beneficial in many circumstances. Here are three reasons:
For knowing the insertion order of rows (to a close approximation).
For creating foreign key relationships.
To ensure that you can uniquely identify each row for updates and deletes.
However, such a column occupies more storage. And, a single primary key index is more efficient (space-wise) than having multiple indexes.
This isn't a direct answer to your question, but it does at least give you some parameters for thinking about the issues.
Usually when you don't know any better, it's best to follow the standard guidelines in DB design. Because they work for a clear majority of the cases, and there's less chance in going wrong with them.
In this case, it means that you would very likely benefit from using an auto-incrementing ID column as a clustered primary key index. As well as adding foreign keys and nonclustered indexes to all referencing columns, in case you haven't already.
Finally, you might even look at adding a few custom (even multicolumn) indexes specifically designed for your slowest queries... basically, if you have a few problem queries, you want to index the columns in their WHERE clauses.
In addition to all this, you should of course look to see that the table and DB in general is normalized. To learn about normalization, it's best for you to google for it. It's not a complex or difficult concept, but there are a thousand tutorials far better suited for explaining the concept than us here.
By doing this you will very likely be moving in the correct direction. And if it doesn't work, then that's so much more information people here can use to determine the best alternative.
What are primary keys used aside from identifying a unique column in a table? Couldn't this be done by simply using an autoincrement constraint on a column? I understand that PK and FK are used to relate different tables, but can't this be done by just using join?
Basically what is the database doing to improve performance when joining using primary keys?
Mostly for referential integrity with foreign keys,, When you have a PK it will also create an index behind the scenes and this way you don't need table scans when looking up values
RDBMS providers are usually optimized to work with tables that have primary keys. Most store statistics which helps optimize query plans. These statistics are very important to performance especially on larger tables and they are not going to work the same without primary keys, and you end up getting unpredictable query response times.
Most database best practices books suggest creating all tables with a primary key with no exceptions, it would be wise to follow this practice. Not many things say junior software dev more than one who builds a database without referential integrity!
Some PKs are simply an auto-incremented column. Also, you typically join USING the PK and FK. There has to be some relationship to do a join. Additionally, most DBMS automatically index PKs by default, which improves join performance as well as querying for a particular record based on ID.
You can join without a primary key within a query, however, you must have a primary key defined to enforce data integrity constraints, at least with SQL Server. (Foreign Keys, etc..)
Also, here is an interesting read for you on Primary Keys.
In Microsoft Access, if you have a linked table to, say, SQL Server, the source table must have a primary key in order for the linked table to be writeable. At least, that was the case with Access 2000 and SQL Server 6.5. It may be different with later versions.
Keys are about data integrity as well as identification. The uniqueness of a key is guaranteed by having a constraint in the database to keep out "bad" data that would otherwise violate the key. The fact that data integrity rules are guaranteed in that way is precisely what makes a key usable as an identifier. That goes for any key. One key per table by convention is called a "primary" key but that doesn't make other alternate keys any less important.
In practice we need to be able to enforce uniqueness rules against all types of data (not just numbers) to satisfy the demands of data quality and usability.
As I understood from this post, there are some scenarios where foreign keys can improve query performance.
I've heard the opposite claim though, that because of referential integrity checks, foreign keys can actually hurt query performance. Under which conditions (if at all) is this true?
1) The term query seems to be misleading. I am interested in all kinds of performance penalties.
2) Does anyone have any real-world numbers about the negative impact on INSERT, DELETE or UPDATE statements (I know it depends on the specific system, but nevertheless any kind of real-world measurements would be appreciated)?
if a foreign key is needed for referential integrity then the presence of the foreign key should form the baseline for performance
you might as well ask if a car can go faster if you don't put seats in - a well formed car includes seats as much as a well formed database includes foreign keys
I'm assuming that for INSERT queries, constraints - including foreign key constraints - will slow performance somewhat. The database has to check that whatever you've told it to insert is something that your constraints allow it to insert.
For SELECT queries, foreign key constraints shouldn't make any changes to performance.
Since INSERTS are almost always very quick, the small amount of extra time won't be noticeable, except in fringe cases. (Building a several gigabyte database, you might want to disable constraints and then re-enable later, as long as you're sure the data is good.)
In theory, yes: data writes need to validate the constraints.
In practice, seldom: unless measured and proved otherwise, you can assume there is no performance impact. Overwhelmingly, performance problems occur due to other problems:
bad schema design (missing indexes, bad clustered index choice)
contention (blocking), again due to bad schema design (table scans guarantee lock conflicts)
bad query design
On a well designed schema and good queries the cost of constraints will start to show up at very high throughput. When this happens, there are preventive measures.
My 2c: Never sacrifice correctness constraints for some elusive performance goals. In the very rare case when the constraints are indeed the problem there are measurements to show that's the case, and as the saying goes: if you have to ask how much it costs, you can't afford it. If you have to ask if constraints can be a problem, you can't remove them (no offence intended).
Foreign keys can cause inserts(or some updates) in child tables or deletes from parent tables to take longer. This is a good thing however as it means that it is making sure that the data integrity remains. There is no reason whatsoever to skip using foriegn keys unless you don't want to have useful data. You wil not normally notice much differnce unless you have many foreign keys realted to the same parent table or if you are inserting or deleting many records in one batch. Further, I have noticed, users are more tolerant of a couple of extra seconds in an insert or delete than they are in a select. Users are also not tolerant at all of unreliable data which is what you have without foreign key constraints.
You will need to index them to improve performance on select queries.
For INSERT/UPDATE/DELETE the short answer is, "Yes". The database will need to check that the referential integrity is intact and the creation/modification is allowed. Or in DELETE's case, there may be some cascading to be done.
For SELECTs, it's actually quite the contrary. Foreign Keys have a secret added benefit of showing you exactly where you're most likely to be doing complex JOINs and have very commonly used fields. This makes the job of indexing much easier, and you can pretty much guarantee that all of your FK fields should be indexed. This makes SELECTs much faster.
Foreign key checking takes more time than most people think. A current test with Oracle 11g and a table with two foreign keys showed that the time for an insert of about 800.000 rows took 60 seconds with enabled foreign keys but only 20 seconds without foreign keys.
(The foreign key columns were indexed, of course)
Anyway, I agree with all the other posters, that integrity constraints are not an option, but the only way to keep data consistent. However, for imports, especially into empty tables, it could be an option to disable the foreign key for the time of the import, if time is critical.
If foreign keys had any impact in that way, it would be on INSERTS. The database does the referential checking on foreign keys when records are created/modified, not SELECTed.
Foreign keys will not adversley affect query performance in most cases, and are strongly recommended. By aiding normalization, you will eliminate redundant data, and if you follow up by adding underlying indexes (for the appropriate foreign key) you will get good performance on your queries.
Foreign-keys can help the query optimizer get the best query plans for a given query.
Foreign-key checking is a factor when you update your data (which is a separate consideration - I assume here your concern is query - unless by the word query you imply both).
Foreign keys slow down insertions and alterations, because each foreign key reference must be verified. Foreign keys can either not affect a selection, or make it go faster, depending on if the DBMS uses foreign key indexing.
Foreign keys have a complex effect on deletion. If you're deleting the thing that refers to the foreign key, it won't affect anything, but if what you're deleting is referenced by a foreign key in another row/table, then it will generally cause problems.
Foreign keys can cause a minor performance degradation in table creations and alterations.
Of course, this all assumes foreign key verification is in use.
I believe the noted post pointed out that putting an index on FK fields improved performance, not simply that a FK relationship improved performance. The existence of a FK on a table should not have any effect on a SELECT query, unless JOIN operations are being done, at which point, the FK relationship AND index on FK fields would improve performance.
If you're enforcing referential integrity, INSERTs, and UPDATEs that effect the FK field, will be slower. However, it's usually not much to worry about, especially as a lot of DBs are 80% read/20% write. It's also a price worth paying.
Creating an index on a foreign key is often beneficial, though obviously it how much depends on what SELECT statements you're running.
Generally, you need foreign keys due to normalisation (which avoids duplicate data and synchronisation problems). Normalise to the 3rd degree, and then after analysing real world performance can you consider de-normalising.