데이터베이스에 속성 테이블을 포함시키는 것은 나쁜 생각입니까?

Question

종종 admin 정보, 버전 등과 같은 시스템 속성을 저장해야 할 때 플랫 파일 (database.properties, init.properties 등)을 사용합니다. 이것은 일상적으로보고 사용하는 다른 프로그램에서 흔히있는 것처럼 보입니다.

때때로 플랫 파일은 여러 가지 이유로 이상적이지 않습니다. 수많은 클라이언트에 웹 응용 프로그램을 배포 할 때 종종 한계가 있습니다. 이러한 경우에는 데이터베이스 테이블을 사용하여 정보를 보관합니다. 예를 들어 저장하려는 일부 관리 데이터가 있고 내 환경에 대한 세부 정보가 있다고 가정 해 보겠습니다. 나는 이런 식으로 뭔가를 할 수 있습니다

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT" 
2, 0, 1, "LICENCE", "88475", "INT" 
3, 0, 1, "TOP_PROJECT", "1", "INT" 
4, 0, 1, "SHOW_WELCOME", "F", "BOOL" 
5, 0, 1, "SMTP_AUTH", "SSH", "STRING" 
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL" 

나는이 SQL의 입력을 중단하고 문자열로 유형의 모든 종류를 저장하기 위해 나를 수 있습니다 알고 있습니다. 이 좋은 습관입니까, 아니면 제가 잘못된 방향으로 가고 있습니까?

그렇지 않은 경우 어떤 식 으로든이 유형의 정보를 저장해야합니까?

Answer 1

속성 데이터를 저장하는 데 비슷한 구조를 사용했습니다. 테이블이 상대적으로 작게 유지되는 한 괜찮습니다. 이와 같은 엔티티 속성 값 (EAV) 테이블은 기존의 열 구조화 된 테이블보다 더 많은 공간을 소비하고 쿼리 성능이 저하 될 수 있지만 합리적인 크기의 응용 프로그램 속성에 대해서는 문제가되지 않습니다.

Answer 2

매우 드물게 액세스되는 소량의 데이터에 대해서는 문제가 없습니다.

스키마를 보는 사용자에게는 개별 앱 속성이 표시되지 않는 것이 좋습니다.

이렇게하면 스키마 업데이트시 문제가 줄어 듭니다. (응용 프로그램 속성은 자주 추가/제거됩니다.)

많은 양의 데이터 또는 자주 액세스되는 데이터는 검색 당 여기서 데이터베이스에서 수행해야 할 작업이 많기 때문에 적합하지 않습니다. 기존 스키마보다

Answer 3

난 괜찮다고 생각하지만, DB로 돌아갈 필요가 없도록 읽을 때 메모리에 데이터를 캐싱하는 것이 좋습니다. 데이터를 캐시 한 다음 업데이트를 가장 쉽게 만들 수있는 위치에 데이터를 저장하십시오. DB에 데이터를 저장하는 이점은 특히 응용 프로그램에 분산 환경을 사용하기 시작하면 해당 속성을 관리하기위한 인터페이스를 유지 관리하거나 작성하는 것이 더 쉬울 수 있다는 것입니다.