your UPI is not the order_date only. It's the combination of Customer_Number and order_date. Since Customer number is different (101 and 102), therefore there is no issue with the records.
Try this and you will get the error:
ins into order_table (101,'mack', current_Date,1000);
row inserted.
ins into order_table(101,'pawan',current_date,2000);
As per the rules, you cannot have a UPI on a table which is partitioned by something which is not a part of PI. Let's say if you had tried to define only the Customer_Number as UPI and then partitioned on Order_date, that is no possible. For that to work, you would have to define Customer_number as NUPI, even if it is unique. If you want to take the advantage of uniqueness constraint, then also make Customer_number as USI. But keep in mind that Secondary indexes take up perm space so there isa trade-off.
In your example, since order_date is a part of the PI, you can have UPI on this table.
I hope this clears your doubt?
your UPI is not the order_date only. It's the combination of Customer_Number and order_date. Since Customer number is different (101 and 102), therefore there is no issue with the records.
Try this and you will get the error:
ins into order_table (101,'mack', current_Date,1000);
row inserted.
ins into order_table(101,'pawan',current_date,2000);
As per the rules, you cannot have a UPI on a table which is partitioned by something which is not a part of PI. Let's say if you had tried to define only the Customer_Number as UPI and then partitioned on Order_date, that is no possible. For that to work, you would have to define Customer_number as NUPI, even if it is unique. If you want to take the advantage of uniqueness constraint, then also make Customer_number as USI. But keep in mind that Secondary indexes take up perm space so there isa trade-off.
In your example, since order_date is a part of the PI, you can have UPI on this table.
I hope this clears your doubt?