replace composite key of emissions records with unique key about blockchain-carbon-accounting HOT 4 CLOSED

After some research and especially this article on medium, I recommend using UUID as PK.
Of course, compared to auto-increment keys or composite keys there are downsides like performance loss and the increased storage required. However, we can generate the UUID outside of the chaincode and its a create benefit to have a "globally" unique identifier in distributed systems.
I vote for UUID as pk.
What do other folks think about this?

Another scenrio could be to use auto-incremented integers as pk and UUID as a second identifier.

from blockchain-carbon-accounting.

I've gotten a working example of this going this morning. I don't have an opinion on whether we use PK or UUID, as the logic will basically be the same except for that one value. This will leave it flexible in the future, but just a few questions:

1. For the query of ONE emission, would it require all of the same fields and then return the result ONLY unique to that?

2. For querying ALL emissions, we can have any combination of values passed in (for example, utility id only, or perhaps utility ID AND user_id, etc), and it will return all entries that match those fields. Does this sound correct? This gives a super flexible, powerful, and reusable query that we can inherit from on other channels/cc.

from blockchain-carbon-accounting.

I am also looking at this for generating UUIDs: https://www.npmjs.com/package/uuid

from blockchain-carbon-accounting.

1. To query one emission should only require the UUID key
2. Yes, to query a list of emissions, use all the same current parameters to return a list of the emissions.

from blockchain-carbon-accounting.