# Why Object IDs & Primary Keys Are Implementation Details

DevFeed: [Why Object IDs & Primary Keys Are Implementation Details](<https://devfeed.tech/articles/why-object-ids-primary-keys-are-implementation-details-33393.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2012/03/24/why-object-ids-primary-keys-are>)

Published: 2012-03-24T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [implementation](<https://devfeed.tech/topics/implementation.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [business logic](<https://devfeed.tech/topics/business-logic.md>), [Apache Cassandra](<https://devfeed.tech/topics/cassandra.md>)

Tags: [business-logic](<https://devfeed.tech/tags/business-logic.md>), [cassandra](<https://devfeed.tech/tags/cassandra.md>), [database](<https://devfeed.tech/tags/database.md>), [declarative](<https://devfeed.tech/tags/declarative.md>), [ids](<https://devfeed.tech/tags/ids.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [object](<https://devfeed.tech/tags/object.md>)

## AI overview

The article argues that object identifiers and primary keys should be treated as implementation details and hidden from the business domain when possible. It explains that tightly coupling data logic to business logic can force application changes when database requirements evolve, such as changing an identifier type or switching databases.

## Source excerpt

Recently I wrote a post about a project that I was working on with an abstracted data layer concept that can work in the context of either relational or document data store. In retrospect I think I brushed too quickly over the details of why I think object identifiers (and primary keys) are a part of the implementation that should be hidden, when possible. To explain what I mean I'll use a surreal-world story.