대리 키가 사용자에게 노출되어야합니까?

Question

자연스러운 키가없는 테이블에서는 사용자가 고유하게 생성 된 식별자를 가질 수 있도록 여전히 유용합니다.테이블에 대리 주요 키가있는 경우 (그리고 그러한 경우를 기대할 수있는 경우) 키를 사용자에게 노출시켜야하거나 해당 목적으로 다른 필드를 사용해야합니까?

Surrogate 키를 노출시키지 않는 한 가지 이유는 레코드 간의 관계를 유지하는 작업을 수행 할 수는 없지만 특정 종류의 삭제 / 재 삽입과 같은 키 값을 변경할 수는 있지만 데이터를 복사하는 많은 메서드가 변경됩니다.하나의 데이터베이스,

Surrogate 키를 노출시키는 주된 이점은 어쨌든있는 필드를 사용하는 단순성입니다.

어떤 상황에서는 대리 키를 직접 노출하는 것이 더 낫습니다.

Answer 1

변경해야 할 사용자 / 고객에게 노출 된 식별자를 준비하고 데이터베이스의 행의 ID를 변경하고 모든 외래 키로 변경 해제를 전파해야합니다.

데이터에 자연스러운 비즈니스 키가 없으면 "비즈니스 식별자"에 대한 추가 필드를 추가 할 수 있습니다. 이것은 사용되는 프로세스에 대해 최적화되어야합니다. 전화 키패드 항목은 숫자만을 의미합니다. 전화 / 구두 수단을 통해 유사한 소리 기호 (B / D, M / N 등)를 피하십시오. 쉽게 기억에 남는 문구 ( "녹색 젤리")를 자발적으로 만족시킬 수도 있습니다.

이 효과는 나중에 레코드를 참조하는 방법을 변경할 수 있으며 유일한 데이터 스키마 변경은 해당 ID 스타일의 새 열을 추가하거나 이미있는 ID를 변환하는 것입니다. 변경 사항은 전체 데이터베이스를 통해 전파되지 않으며 시간이 지남에 따라 유효한 하나의 ID (대리)가 있습니다.

간단히 말해서, 대리 키를 사용자에게 노출시키지 못하게합니다. 의견이 지적하기 때문에 대리 키는 거의 변경되지 않아야합니다. 반대로 기업은 모든 것을 바꾸고 싶어합니다. 대리 키가 노출되면 비즈니스가 변경하기를 원하기 전에 시간 문제 일뿐입니다.

사이드 노트로서, 여기에 "노출"이라고 말할 때, 나는 그들이 을 직접 사용한다는 것을 기대한다. 짐마자

Answer 2

In some cases, surrogate keys are expected and make sense to users. My favorite example is "order number". Order number isn't really a natural key: a natural key might be timestamp plus user, or maybe more than that if you expect users to generate more than one order within the granularity of your timestamp.

Nonetheless, users understand and expect the convenience of an order number. There is no harm, and lots of value, if you let users know about them.

On the other hand, some surrogate keys make no sense to a user. Sure, my health insurance company has some surrogate key that identifies me based on my member id, date of birth, carrier, etc, but I don't care about that, I care about the info on my card (which often includes ids based on my employer and are not unique across the universe... Hence the surrogate key at the insurance company).

Answer 3

In layman's words:

• Surrogates should be hidden from the user.
• You should expose some other business candidate key to the user.
• If no other candidate key exist you should show the PK. But in this case the PK is not considered a surrogate since it's not a substitute for other column.

Answer 4

you should ONLY expose a field to a user that provides useful information to the user, either directly or in reporting defects to you.

conversely, you should ALWAYS expose "surrogate primary keys" when they are the principal means of identifying a record (simple or complex) for an interaction the user performs.

Answer 5

You should only expose a surrogate key if it's a properly generated GUID/UUID*. Exposing sequential surrogate keys is number 4 on the OWASP Top 10 security issues.

* In practice, it's best to assume that it wasn't properly generated for these purposes unless you know that it was created by a cryptographically secure random or pseudo-random number generator.

Answer 6

If a table has no natural key, surrogate keys allow rows like this.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

I'd call these artificial keys instead of surrogate keys, but that distinction isn't important for this question.

Now, assuming that there's important data referencing these surrogate keys through foreign keys, how would the end users know which row to update if they don't know the surrogate key values?

Answer 7

It shouldn't matter whether you expose the keys or not to the end user. Your application should perform the necessary authorization such that simply knowing an order id, for example, can't allow them access to something they normally wouldn't have access to.

caveat: this assumes a web based or n-tier application where server side authorization is possible/feasable. If you have a VB app thats directly executing sql, thats a whole 'nother issue.

Answer 8

According to the principle of encapsulation, which is a foundational concept in OOP, you should hide implementation details. Once a surrogate becomes public it becomes data. One man's surrogate key is the next man's natural key.

In practice I think surrogate keys should be encapsulated at the boundary of a service layer. If you have a service for some aggregate root then the internal domain objects and repository would all use the surrogate key. These internals would all be encapsulated. The public API would use some other format which could include nesting to hide parent keys, so hiding the surrogate key of the root record isn't exactly a seven year leap.

Answer 9

One health-care company that I did a project for had a nasty problem with their "provider IDs." These were originally hand-managed and they contained embedded information. A single provider might have more than one ID, and had to know the "right" one to use at each clinic. And, unfortunately, some provider-IDs had been assigned to more than one provider at a time!

To solve the problem and to allow several different systems to communicate with each other unambiguously, I created an internal-only system of surrogate keys: they were simply random strings of letters that were the same length as the old (numeric) provider-ID strings. This was done so that column-sizes and data types didn't have to be changed.

One master system had to take a provider-ID, "figure out who it meant," and return the proper surrogate key, which always corresponded 1:1 to a single person.

Sometimes, that same system had to go the other way ... "which (legacy) provider-ID should we give them when referring to [this_person_surrogate] in [that_system]?"

Each of the downstream systems was now re-coded to use these unambiguous surrogate keys to refer to persons, knowing that every other system would be using only the same surrogate value.

Within each system's database, auto-increment integers were conveniently used as primary and foreign keys, and these keys were of course never shared with any other system. The record for each "person" contained its surrogate.

Any request that one system made to another system always used the surrogate. No system ever knew what any other system's "primary keys" were.

Carrying this concept one step further, surrogate keys were never published externally. The company eventually re-vamped its provider-ID system in an effort to clean up their mess, but when they did so we created a new provider-id "for public consumption," and tied those values to the surrogates just as we had done with the old IDs. Thus, the "purity" of the surrogates was not compromised, and the company didn't have to give its providers "ugly character strings."