조회 테이블 모범 사례 : DB 테이블… 또는 열거

조회 테이블 모범 사례 : DB 테이블… 또는 열거

---

회사에서 사용 가능한 직책을 저장해야하는 경우 (예 : 관리자, 팀장 등). 저장을위한 모범 사례는 무엇입니까? 의견이있는 두 가지 의견이 있습니다. "좋아요, 환영합니다"

1. 열 ID와 이름이있는 DB 테이블로 저장하고 쿼리 및 조인을 사용하여 처리합니다.
2. Enum으로 저장하고 DB 테이블은 잊어 버리십시오.

제 생각에는 변경 항목이 있으면 첫 번째 솔루션을 선택하겠습니다. 이 옵션을 Enum으로 하드 코딩하지 않도록합니다.
데이터가 변경되지 않을 것이라는 확신이 들면 Enum 솔루션을 선택할 수 있습니다 (예 : Gender : Male, Female).

참고 : 나는 영어로 코딩하고 UI 문화는 아랍어 일 수 있습니다. Enum 솔루션으로 작업 할 경우 프레젠테이션 레이어에서 문화 기반 문자열을 하드 코딩 할 것입니다. 모범 사례 관점에서는 괜찮습니까 !!!!

귀하의 의견을 알고 싶습니다. 내 생각이 가장 권장되는 "모범 사례"에 해당하는지 ??

---

일반적으로 기본 색상 또는 대륙 이름과 같이 변경되지 않는 명확한 항목 집합이있는 경우에만 열거를 사용해야합니다. 그렇지 않으면 적절하게 구현 된 외래 키가있는 조회 테이블이 거의 항상 최상의 옵션입니다.

단순한 ID / 값 관계에 대해 잠재적으로 많은 수의 조회 테이블이있는 조회 테이블 옵션에 가능한 변형이 있습니다. 도메인 / 조회 테이블 쌍은 약간의 추가 코딩 복잡성이 있지만 필요한 테이블 수를 크게 줄일 수 있습니다. 이 경우 도메인 테이블이 있습니다.

DomainID int ID
도메인 varchar (255)

및 키 / 값 테이블

DomainID int
ID int identity
값 varchar (255)

따라서 다른 방법으로 사용할 각 조회 테이블에 해당하는 행이 Domain 테이블에 추가되고 모든 (키-도메인) / 값 쌍이 값 테이블에 추가됩니다. 데이터베이스 구조를 단순화하는 것 외에도이 접근 방식은 애플리케이션 코드에서 동적으로 '룩업 테이블'을 생성 할 수 있다는 장점이 있습니다. 이는 일부 애플리케이션에서 매우 유용 할 수 있습니다.

---

옵션 1 : 열 ID와 이름이있는 DB 테이블로 저장하고 쿼리 및 조인을 사용하여 처리하는 것이 최소한으로 수행해야합니다.

" 피해야 할 5 가지 단순 데이터베이스 설계 오류 "에서 :

애플리케이션 강화 무결성은 때때로 개발자들이 선호하는 반면, DBMS는 여전히 모든 무결성의 중앙 집중식 시행자 여야합니다.

권장되는 모범 사례는 사용자 인터페이스에 대해 전혀 모르는 것처럼 데이터베이스를 구현하는 것입니다. 즉, 데이터베이스는 데이터와 관련된 모든 규칙을 적용해야합니다. 이 경우 데이터베이스는 적절한 값을 적용해야합니다. 적절한 값을 열거하려면 일반적으로 각 유형의 조회 값에 대한 조회 테이블 을 사용하는 것이 좋습니다. 여러 번 응용 프로그램이왔다 갔다하지만 데이터베이스는 그대로 남아 재사용됩니다.

애플리케이션에서 열거를 적용하려면 확실히 그렇게 할 수 있지만 무엇을하든 데이터베이스가 데이터베이스 역할을하고 데이터의 무결성을 유지하는지 확인하십시오. 번거 롭다면 문제를 겪으십시오. 당신은 기초를 놓고 있습니다. " 데이터베이스 디자인과 피사의 사탑 "에서 저자는 데이터베이스에 기반을 올바르게 배치하는 것이 왜 그렇게 중요한지 강조합니다.

이게 도움이 되길 바란다.

---

의미있는 데이터 (즉, ID가 아닌 이름)로 쉽게 쿼리 할 수 ​​있도록 데이터베이스 옵션을 선호합니다.

값이 변경되지 않을 것이라고 확신하는 경우 응용 프로그램에 열거 할뿐만 아니라 항목의 ID를 기억할 필요가 없을 때 개발이 훨씬 쉬워지고 코드를 훨씬 더 읽기 쉽게 만들 수 있습니다.

이 접근 방식을 사용하면 조회 테이블을 쿼리에 포함할지 여부를 선택할 수 있습니다. 예를 들어 조회 값을 표시하고 싶지만 대신 열거 형에서 추론 할 수있는 경우 애플리케이션에서 데이터를로드 할 때 포함하지 않을 수있는 보고서 쿼리에 포함합니다.

분명히 값이 변경되거나 수정 될 경우 열거가 불가능할 수 있습니다.

UI 문화의 영향은 오직 당신 만이 판단 할 수 있습니다. 저는 제 사용자들의 문화에 대해 100 % 확신하므로 너무 걱정할 필요가 없습니다. :).

---

몇 가지 장점이 있기 때문에 항상 데이터베이스 옵션을 선택합니다. 주요 장점 중 하나는 코드를 변경하지 않고도 조회 목록에서 항목의 이름 / 설명을 변경할 수 있다는 것입니다. 또한 많은 작은 테이블이 아닌 단일 테이블을 갖는 것에 동의합니다. 이렇게하면 하나의 루틴을 코딩하여 데이터베이스에서 값을 검색하여 유지 관리 비용을 줄일 수 있습니다. 단일 루틴이 있다는 것은 더 많은 노력을 투자하여 잘 수행 할 수 있음을 의미합니다.

위의 Cruachan의 답변에 더해 부모가없는 행이 도메인을 설명하는 부모-자식 관계가있는 경우 하나의 테이블로 벗어날 수 있습니다. 도메인에 속한 모든 레코드에는 도메인 행이 부모로 있습니다.

ID           int autonumber -- integer primary key for performance
DomainID     int            -- null for domains
Name         varchar(100)   -- Name of the item
Description  varchar(255)

예를 들어 통화 목록에는 다음이 포함될 수 있습니다.

 ID    DomainID   Name              Description

 100   NULL       ISO Currencies    List of ISO Currency codes
 101   100        BHD               Bahrain Dinar
 102   100        GBP               British Pound
 103   100        EUR               Euro  
 104   100        USD               US Dollar

---

이 고용주 목록에 db에 넣을 계획이있는 유일한 것이 있습니까?

그렇다면 파일에 넣고 완료하십시오.

DB는 훌륭하지만 단순한 키-값이 필요한 경우 과잉입니다. 그들은 당신에게 많은 것을 제공합니다. 그러나 그들은 또한이면에서 많은 일을합니다. 그들은 당신이 지원해야 할 또 하나의 것입니다 ... 20 개의 탭으로 구분 된 줄이있는 단일 파일로 빠져 나갈 수 있다면 간단하게 가십시오.

이러한 종류의 조회가 필요한 항목이 많거나 클라이언트가 해당 항목을 읽으려고하는 동안 업데이트해야한다고 생각하거나 나중에 항목을 상호 참조하려는 경우에는 다음으로 이동하십시오. DB.

---

조회, 조회, 조회 (여기에 원숭이 춤 동영상 삽입)

내 개인적인 "모범 사례"는 모든 것을 데이터베이스에 저장하는 것입니다. 회사의 직위는 확실히 룩업 테이블입니다.

The same goes for translations, which may be a bit trickier, but generally a view definition joining the table with a translation table is a good start.

Besides, if the Position is only an int value, and your app is single-language, you can add the position titles directly to the database.

---

I tend to almost always put this kind of thing in a table. If it's needed a lot I'll cache it. If I need to programmatically refer to some of them I'll then create an enum which has its values set to the key value of the lookup item.

For example, a surrogate primary key (usually so my data access layer can seemlessly add/update it), a field for the value of the item, plus a "candidate" (candidate being in quotes since it's not required, so it's either unique or null). That way I can use the enum in quotes to refer to specific/important items in the table, but still have the flexibility of letting end users add new items. The specifics of the data model used really depend on your preference (some people may be screaming at me right now for not just using the "candidate" field as the true primary key).

---

I generally prefer both. I use table in the dal layer as they can be used for tools like tableau for reporting, SQL queries and other purpose.

I use enums in the front end and the business layer because its easy to develop with them and you dont have to get the list from the dal neither you have to remember the values from the table.

C# automatically convert the enums to corresponding ID for you if the list is same in the table and the enum.

In MVC you can use the dropdown with the enums as @Html.EnumDropdownListFor() in the View so you dont have to the hit the database itself for dropdowns.

---

If you can keep them synchronized I don't think there is much of a reason not to have both. When I was developing some state-machine functionality with a DB store it made things a lot easier to have an enumeration of the available object states within my IDE.

I wrote myself a little EnumGenerator Visual Studio Addin a while back that creates an Enumeration code snippet in C# from a the ID and DESC columns of a DB Tablet you select from right within the IDE. I haven't released it because it was the first time I'd worked with VS Addins and it was pretty junky but I bet somebody with addin/code generation experience could take the idea and run with it.

ReferenceURL : https://stackoverflow.com/questions/433490/lookup-tables-best-practices-db-tables-or-enumerations