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.
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?
The clientnumbers are used a lot and highly selective. But partitioning is done by a modulo function of the clientnumbers to get an even spread over the partitions. The detail tables use the same partitioning key, most of the detail tables do not have the clientnumber but the partitioning key is there.
*There are some use cases for a hashing partition like this, but it's not for typical OLTP workloads
Just a note, partitioning is not about performance improvements most of the time. It's about maintenance, data loads, archiving and things like that.
Both of you thank for the last remarks. Partitioning is not designed for OLTP
and partitioning is not designed to be transparrant
This does clear some of my misunderstandings about partitioning.
Thanks for setting me straight,