2

여러 고객에게 SAAS로 판매되는 애플리케이션이 있습니다. 때때로 고객은 자신의 필드 인, 특히 작업/프로젝트 추적과 관련된 영역을 추가하여 응용 프로그램의 일부 영역을 사용자 정의하려는 경우가 있습니다. 우리는 현재 이것의 소량을 허용합니다. 각 필드에 대한 ID를 사용하여 각 고객에 대한 추가 필드의 이름을 db에 저장하여 처리합니다. 그런 다음 모든 값은 잠재적 인 각 데이터 유형 (문자열, 날짜 등)에 대한 열이있는 두 번째 테이블에 저장됩니다. 이 테이블은 사용자 정의 필드의 ID와이 필드가 첨부 된 객체의 키를 참조합니다. 이렇게하면 모든 사용자 정의 필드 데이터가 단일 테이블에 저장됩니다. 이상한 고객을위한 소량의 필드로만 제한된다면이 점에 대해별로 염려하지 않겠지 만, 이제 판매 및 고객 서비스가 개별 고객을 위해 신속하게 애플리케이션을 사용자 정의 할 수있는 기회로 여겨지고 있으며, 경우에 따라 해당 항목에 원래 있던 것보다 더 많은 사용자 정의 필드를 얻습니다.사용자/고객별로 맞춤 입력란을 만드는 가장 좋은 방법은 무엇입니까?

나는 지금 우리가 이러한 대규모 사용자 정의를 보류해야한다고 확신했으며, 이러한 유형의 동작을 원한다면 적절하게 구축해야한다. 즉, 관련 데이터베이스 테이블을 작성해야한다. 데이터베이스에 here을 구현하는 2 가지 방법을 언급하는 또 다른 질문이있었습니다. 하나의 솔루션은 위에서 설명한 것과 유사합니다. 다른 하나는 테이블에 Text1, Text2, Date1, Date2 등의 사용자 지정 테이블에 중복 필드가있는 것입니다.이 필드는 사용자가 GUI에서 적절하게 이름을 바꾸는 데 필요한대로 사용할 수 있습니다.

그래, 궁금한데 다른 사람들이이 문제를 어떻게 해결 했습니까? 그들의 해결책에는 어떤 제한이 있었습니까? 그리고 내가 할 수도있는 더 읽기에 대한 제안.

환호,

답변

1

우리는 또한 SaaS는을 개발하고 우리는 또한 사용자 정의의 모든 종류를 원하는 고객이있다.

어느 정도까지 모든 고객에게 유용 할 수 있지만 고정 구현되어 있습니다. 의미, 테이블 및 필드. 이 기능은 사용자 패키지에 속한 일부 액세스 권한을 통해 활성화 또는 비활성화됩니다.

사용자가 자신의 양식을 만들기 위해 필드와 관련 하위 필드를 동적으로 정의 할 수있는 경우에도 다른 상황이 발생합니다. 그것은 복잡해집니다. 여기서는 이러한 요구를 해결하기 위해 일종의 Entity Attribute Value model을 사용합니다.

"엔터프라이즈"응용 프로그램과 관련된 것입니다. 고객이 이국적인 것을 원하며, 우리는 '아니오'라고 말할 수 없습니다.

+0

성능 향상을 위해 엔티티 속성 값 모델을 사용하여 최적화를 적용 했습니까? (캐싱 또는 색인 생성 등) –