In database design typically it recommends giving out opaque natural keys, and keeping your monotonically increasing integer IDs secret and used internally.

▲

bastawhiz 6 hours ago | parent | next [-]

That is a best practice for two real reasons:

1. You don't want third parties to know how many objects you have

2. You don't want folks to be able to iterate each object by incrementing the id

But if you have composite IDs like this, that doesn't matter. All objects that belong to a repository have the repository id inside them. Incrementing the id gives you more objects from the same repo. Incrementing the repo id gives you...a random object or nothing at all. And if your IDs include a little entropy or a timestamp, you've effectively kneecapped anyone who's trying to abuse this.

	▲	maxbond 4 hours ago \| parent [-]
		> You don't want folks to be able to iterate each object by incrementing the id If you have a lot of public or semi-public data that you don't want people to page through, then I suppose this is true. But it's important to note that separate natural and primary keys are not a replacement for authorization. Random keys may mitigate an IDOR vulnerability but authorization is the correct solution. A sufficiently long and securely generated random token can be used as both as an ID and for authorization, like sharing a Google Doc with "anyone who has a link," but those requirements are important.

▲

taftster 7 hours ago | parent | prev [-]

Maybe. Until your natural key changes. Which happens. A lot.

Exposing a surrogate / generated key that is effectively meaningless seems to be wise. Maybe internally Youtube has an index number for all their videos, but they expose a reasonably meaningless coded value to their consumers.