Number of Measurement Records Exceed Integer Id Limit

[WustlRob]

We've run into an issue where we have more measurement records than an integer measurement_id allows in OMOP database (Over 3 billion where max 32 bit integer is 2,147,483,647). Our suggestion is to change the measurement_id field (and probably the id fields for other domains) to use a 64 bit integer. We are using PostgreSQL for our database.

[kembree1]

I'm surprised this hasn't been an issue before now.

[cgreich]

No problem to use big_int. Won't make a difference in querying in 99% of the cases, particularly if the IDs are exclusively used for foreign keys.

[gowthamrao]

I like the idea of converting all key fields to bigint. E.g. person_id, visit_occurrence_id etc. This will need changes to the omop ddl.

[clairblacketer]

I think we have been using bigint for some of our keys, especially for the MarketScan data. It makes sense to add it in to the DDL; I'll just need to figure out how to translate that translates to bigquery and impala.

[ericaVoss]

We see this mainly affecting the DDL, no need to update the WIKI.

[GeraldPulver]

BIGINT sounds like a great idea. I use 32 Bytes for my keys on some projects, to accommodate 256b hash values. Yes, I realize that 32B would be overkill for a default allocation for keys. :)

[vojtechhuser]

so this issue should be closed, right?

[WustlRob]

I just checked the cdm_v6 branch and it looks good to close. Thanks everyone!