The biggest drawback is that you require 5 values to identify a row. If your application uses an O/RM (Object/Relation Mapping) layer, then you will have fits mapping these database rows to objects in a programming language. O/RM's are easiest to set up when every table has a single column primary key.
Once you get into web application frameworks, URLs in the browser often include some sort of identifier for data in the database and assume there is only one piece of data required to identify a resource, e.g. a single column primary key. This makes using modern web application frameworks more difficult (Ruby on Rails, Microsoft's ASP.NET MVC to name a few).
Programming aside, what if in the future you need to add a column that together with the other 5 should be unique? Now you are modifying your composite key. Just keep it simple. Use a single column primary key. If you need those 5 columns to be unique, consider adding a unique constraint or unique index to those columns instead.
The next drawback of composite keys in general, and especially composite keys requiring this many columns, is all of this data needs to be specified and copied to child tables in order to set up proper relationships between tables.
- Business rule changes in the future might dictate that these values can be duplicated. How will you identify data then?
- Values are duplicated between tables when you need foreign key references
- O/RM's are harder to configure
- Modern MVC web application frameworks are harder to configure routes to include the composite keys
Nothing but downsides to me.
The biggest headache I've run into with developers is they assume "uniqueness of data" equates "identifying a row in the database". This is rarely the case. I've found applications and databases to be much more maintainable and easy to build by defaulting to single column primary keys, and using composite keys as an exception to the rule, then enforcing data uniqueness by using unique constraints or indexes on those columns.