If your partitioning key is not referenced at all in queries, then, generally speaking, it will give no performance gains as it will have to scan each partition to find the rows to satisfy the query. *

The point of partitioning is normally to divide your tables using a natural key, like a transaction date, or a month end date etc. in order to immediately narrow down the portion of the dataset that needs to be accessed.

If your clientnumber is a sequential number, you may be able to get gains by defining your partition as ranges of client numbers, but this isn't a simple subject and you shouldn't just jump into partitioning tables without knowing in detail how partitioning works in SQL Server, that you actually require them and what it means for queries.

What sort of data volumes are you dealing with in these tables? Is there always going to be a seek to a specific client number that's already highly selective?

*There are some use cases for a hashing partition like this, but it's not for typical OLTP workloads