How should I select a primary key in my use case I have an app wherein I want to give offers to certain devices which fall in range of IMEI numbers (I have a separate algo to calculate this range).
So I want to create a structure in which I have a column as IMEI and next column as status, which can be true or false.
Now for those devices which have more than one IMEI I am pretty confused how I should structure my database?
I am expecting transactions which can rise up to a million inserts per 5 hours once the API is released and in the above table my use case is that of transactional database, which helps me generate analytics.
Two solutions come to my mind:

Make a mix of IMEI numbers seperated by a hash and set it as primary key.
Flaw: The IMEI numbers I receive from the client side are not always guaranteed to be in the same order, so maybe I will have to use a like query on the primary key thus created, slowing my transactional database yet again.

I create a new record for each IMEI and set it as true. Which means upon selecting I have to run queries on multiple primary keys with a where clause.


Please advise
Since a device can have more than one IMEI number, that is obviously not the primary key of the devices. Is there no existing attribute, such as serial number, that can serve as unique identifier? If not, then you probably need a devices master table with one entry per device and a generated ID for the primary key. This value would then be used in the transaction table along with the IMEI number. Something like
Table: Device
   DeviceID  int serial primary key

Table: DeviceIMEI
   DeviceID  int FK references Device.DeviceID
   IMEI      character(16)  primary key,
   Status    Boolean

The IMEI is defined as globally unique so can be the PK of DeviceIMEI, even though it may not be the only IMEI for its DeviceID.
One million transactions over 5 hours is about 55 per second. A modern relational DBMS can handle that.