4D 아키텍처 설계: 완전한 가이드

4D 아키텍처 설계는 애플리케이션이 성장함에 따라 속도, 유지 관리 및 보안을 유지할 수 있도록 4D 데이터베이스(테이블, 필드, 관계, 인덱스 및 액세스 수준)를 구조화하는 프로세스입니다. 잘 계획된 4D 스키마에는 일반적으로 테이블 세분성, 관계 전략, 기본 키 유형, 인덱스 위치, 인터페이스 논리에서 데이터 분리 등 5가지 핵심 결정이 포함됩니다. 처음부터 이를 올바르게 수행하면 향후 비용이 많이 드는 마이그레이션을 방지하는 데 도움이 됩니다.

주요 내용

• 4D 아키텍처 설계는 데이터 모델(테이블, 필드, 관계), 비즈니스 로직 계층(메서드, 클래스, 트리거) 및 프레젠테이션 계층(양식, 목록 상자, 대화 상자)의 세 가지 관심사를 분리합니다.
• 관계 유형은 테이블 수보다 중요합니다. 다대다 링크에는 접합 테이블이 필요한 반면, 일대다 링크는 외래 키 필드와 관계를 사용합니다.
• 인덱스는 읽기 속도는 빠르지만 쓰기 속도는 느립니다. 모든 필드가 아니라, 외래 키와 쿼리의 WHERE 절에 사용되는 필드만 인덱스하십시오.
• 4D의 ORDA(객체 관계형 데이터 액세스) 레이어는 스키마에 대한 생각을 변화시킵니다. 이름이 잘 지정된 테이블과 필드는 코드에서 읽을 수 있는 데이터 클래스와 속성 이름이 됩니다.
• 클라이언트-서버 배포와 단일 사용자 배포는 나중에 배포를 고려하는 것이 아니라 아키텍처 결정입니다. 이는 잠금, 캐싱 및 쿼리 작성 방법에 영향을 미칩니다.
• 첫날부터 일관되게 적용되는 명명 규칙은 다른 단일 습관보다 리팩토링 시간을 더 많이 절약합니다.

데이터베이스 컨텍스트에서 “4D 아키텍처”가 의미하는 것

4D 아키텍처 디자인은 원래 1984년 Laurent Ribardière 팀이 출시했고 현재는 4D SAS에서 관리하고 있는 관계형 데이터베이스 및 로우 코드 개발 환경인 4D 플랫폼(4th Dimension)을 기반으로 구축된 애플리케이션의 구조적 디자인을 의미합니다. 순수한 SQL 데이터베이스와 달리 4D는 데이터 엔진, 프로그래밍 언어, 양식 디자이너 및 웹/REST 서버를 하나의 제품으로 묶습니다. 따라서 여기서 “아키텍처”는 스키마와 그 위에 있는 애플리케이션 계층 모두에 걸쳐 있습니다.

이 용어는 때때로 건축 시각화(4D BIM, 건물 설계의 네 번째 차원인 시간)와 혼동되기도 합니다. 이 가이드에서는 소프트웨어 측면, 즉 4D 데이터베이스 및 해당 애플리케이션 레이어를 배치하는 방법을 다룹니다. 건물 디자인을 찾으러 왔다면 아래 개념은 적용되지 않습니다.

4D 애플리케이션의 세 가지 계층

4D 아키텍처 설계 프로젝트는 명시적인 계층 모델의 이점을 활용합니다. 책임을 분할하면 성장하는 앱이 복잡한 양식 스크립트로 변하는 것을 방지할 수 있습니다.

레이어 1 - 데이터 모델

데이터 모델은 4D 구조 파일에 저장된 테이블, 필드, 관계 및 인덱스의 집합입니다. 이 레이어에는 사용자 인터페이스 코드가 포함되어서는 안 되며 다른 곳에 존재할 수 있는 비즈니스 규칙도 포함되어서는 안 됩니다. 필드 유형(텍스트, 정수, 실수, 날짜, 시간, 부울, blob, 개체, 그림) 및 필드 길이는 여기에서 고정되며 나중에 라이브 데이터베이스에서 변경하려면 주의가 필요합니다.

레이어 2 - 비즈니스 로직

비즈니스 로직은 프로젝트 메서드, 클래스 및 테이블 트리거에 있습니다. 최신 4D에서는 클래스(4D v18 R3에서 도입되고 이후 확장됨)를 사용하면 양식 메서드 전체에 논리를 분산시키는 대신 재사용 가능하고 테스트 가능한 코드를 작성할 수 있습니다. 테이블의 트리거는 생성, 저장 및 삭제 시 실행됩니다. 감사 추적에 유용하지만 사용자 인터페이스를 호출하는 트리거는 헤드리스 서버 컨텍스트에서 중단됩니다.

관련 항목: Airtable — 자동화, 보기 및 공유 가능한 인터페이스를 갖춘 실제 관계형 데이터베이스 위에 있는 간단한 스프레드시트 인터페이스입니다..

레이어 3 - 프리젠테이션

프레젠테이션에는 양식, 목록 상자, 입력 대화 상자 및 모든 웹 또는 REST 출력이 포함됩니다. 4D 양식은 필드 및 변수에 직접 바인딩되므로 편리하지만 양식에 논리를 넣게 만들기 쉽습니다. 클래스 메소드를 호출하고 결과를 표시하는 등 양식 메소드를 얇게 유지하는 것은 대부분의 4D 프로젝트에서 유지 관리에 있어서 가장 큰 이점입니다.

데이터 모델 설계: 테이블, 관계 및 키

4D 아키텍처 설계의 데이터 모델링 결정은 4D 관련 메커니즘이 계층화되어 있는 관계형 원칙을 따릅니다.

테이블 세분성 선택

테이블은 하나의 항목 유형을 나타내야 합니다. 고객이 여러 주소를 가질 수 있는 경우 “고객” 테이블을 “고객”과 “고객_주소”로 분할하는 것이 합리적입니다. 고객당 주소가 정확히 하나이고 재사용이 없을 때 이를 병합하는 것이 합리적입니다. 많은 작은 테이블을 과도하게 정규화하면 관계 및 조인 수가 증가하여 목록 보기의 성능이 저하됩니다.

쇼핑하는 경우: Zoho Creator — 더 넓은 Zoho 제품군에 연결되고 앱당 가격이 아닌 사용자당 가격으로 제공되는 로우 코드 앱 빌더입니다..

관계 유형

4D는 구조 편집기에서 정의된 자동 관계와 코드에서 생성된 수동 관계를 지원합니다. 일반적인 패턴:

관계	4D 구현	일반적인 용도
일대다	”다” 측의 외래 키 필드와 관계	송장 → 송장 라인
다대다	두 개의 외래 키가 있는 접합 테이블	제품 ⇔ 공급업체
일대일	공유 기본 키 또는 고유 외래 키	사용자 → 사용자 프로필
자기 참조	동일한 테이블을 다시 가리키는 외래 키	직원 → 관리자

기본 키 전략

4D는 자동 증가 longint 기본 키와 UUID(텍스트) 기본 키를 제공합니다. Longint 키는 작고 색인이 빠릅니다. UUID는 전역적으로 고유하므로 여러 사이트의 데이터를 병합하거나 외부 시스템과 동기화할 때 중요합니다. 일반적인 절충안은 longint 내부 키와 별도의 고유한 “외부 참조” 텍스트 필드입니다.

인덱싱 및 쿼리 성능

인덱스는 4D 아키텍처 설계에서 가장 활용도가 높은 성능 수단이자 가장 쉽게 과도하게 적용할 수 있는 수단입니다.

색인 생성 대상

관계의 외래 키로 사용되는 모든 필드, 쿼리의 검색 기준에 자주 사용되는 모든 필드, 큰 목록 상자에서 정렬에 사용되는 모든 필드를 색인화합니다. 4D는 표준 B-트리 인덱스, 단어 기반 텍스트 검색을 위한 키워드 인덱스, 여러 필드를 포괄하는 복합 인덱스를 지원합니다.

색인을 생성하지 말아야 할 항목

모든 인덱스에는 쓰기 비용과 스토리지가 추가됩니다. 두 가지 가능한 값으로 부울 필드를 인덱싱하는 것은 거의 도움이 되지 않습니다. 전체 레코드 표시의 일부로만 읽혀지는 필드를 인덱싱하면 이득 없이 오버헤드가 추가됩니다. 미리 추측하기보다는 애플리케이션에 실제 사용 패턴이 나타난 후 인덱스를 검토하세요.

쿼리 전략

ORDA 쿼리(ds.Invoice.query("Status = :1"; "Open"))는 일반적으로 새 코드에 대한 기존 QUERY 명령보다 선호됩니다. 쿼리를 다시 수행하지 않고 메서드 간에 정렬, 필터링 및 전달할 수 있는 엔터티 선택을 반환하기 때문입니다. 매우 큰 테이블의 경우 인덱싱되지 않은 필터를 적용하기 전에 인덱싱된 기준으로 쿼리를 제한하면 응답 시간을 예측할 수 있습니다.

관련 항목: Knack — 포털, 디렉토리 및 내부 도구를 목표로 하는 코드 없는 데이터베이스 빌더로, 사용자당 요금 대신 정액 요금이 적용됩니다..

ORDA 및 최신 4D 아키텍처

ORDA(Object Relational Data Access)는 4D v17에서 도입된 4D의 객체 지향 데이터 액세스 계층입니다. 테이블을 데이터 클래스로 노출하고 레코드를 엔터티로 노출하므로 ‘Invoice’라는 테이블은 ‘ds.Invoice’가 되고 ‘TotalNet’이라는 필드는 ‘$invoice.TotalNet’이 됩니다.

이는 4D 아키텍처 설계에 대한 아키텍처적 결과를 가져옵니다. 테이블 및 필드 이름은 이제 공개 API의 일부입니다. 필드 이름을 바꾸면 컴파일 타임에 표시되는 방식으로 코드가 중단되지만 이름 지정이 일관되지 않으면 ORDA 코드를 읽기가 어렵습니다. 단일 테이블 이름, PascalCase 필드, 약어 없음 등의 규칙을 채택하면 즉시 성과를 거둘 수 있습니다.

ORDA는 목록 화면의 성능 프로필을 변경하는 부분적으로만 로드되는 클라이언트 측 엔터티 선택도 지원합니다. 엔터티 선택에 바인딩된 목록 상자는 뒤에 있는 쿼리가 인덱싱되었다고 가정하면 모든 레코드를 로드하지 않고도 수천 개의 행을 표시할 수 있습니다.

우리의 선택: Claris FileMaker Pro — 단일 파일의 데스크톱, 웹, 모바일용 맞춤형 앱이 필요한 팀을 위한 장기 실행 관계형 데이터베이스 플랫폼입니다..

클라이언트-서버, 단일 사용자 및 웹 배포

배포 토폴로지는 많은 개발자가 기대하는 것보다 4D 아키텍처 설계에 예상보다 더 큰 영향을 미칩니다.

단일 사용자 애플리케이션은 하나의 프로세스에서 데이터 엔진과 인터페이스를 실행합니다. 잠금은 간단합니다. 성능 조정은 주로 로컬 디스크 속도에 관한 것입니다.

클라이언트-서버는 4D 서버(데이터 엔진)를 4D 클라이언트(인터페이스)에서 분리합니다. 레코드는 서버에 잠겨 있으며 각 쿼리의 네트워크 왕복 비용이 상당히 커집니다. 화면당 많은 작은 쿼리를 실행하는 아키텍처는 여기서 제대로 작동하지 않습니다. 쿼리를 일괄 처리하고 엔터티 선택을 사용하면 왕복 횟수가 줄어듭니다.

웹 및 REST 배포는 4D의 REST 서버 또는 컴파일된 웹 메서드를 통해 동일한 데이터 모델을 노출합니다. 보안이 최우선으로 이동합니다. 테이블 및 필드 액세스는 역할 및 권한을 통해 제한되어야 하며, 양식 방법에만 적용되는 모든 비즈니스 규칙은 웹 클라이언트에 대해 효과적으로 적용되지 않습니다.

명명 규칙 및 문서

일관된 이름 지정은 화려하지 않지만 4D 아키텍처 디자인에 결정적입니다. 4D에 대해 실행 가능한 규칙:

• 테이블: 단수 명사, PascalCase(“고객”, “InvoiceLine”).
• 필드: 유형 접두어가 없는 PascalCase(“dInvDate”가 아닌 “InvoiceDate”).
• 관계: 대상 테이블(“Customer_Invoices”)에 따라 이름이 지정됩니다.
• 메서드: 동사 우선(“CreateInvoice”, “RecalculateTotals”).
• 클래스: 명사 우선(“InvoiceService”, “TaxCalculator”).

각 테이블, 해당 목적 및 주요 관계를 나열하는 단일 Markdown 파일로 스키마를 문서화하면 온보딩 및 향후 마이그레이션이 훨씬 쉬워집니다. 4D의 구조 편집기는 관계를 그래픽으로 표시하지만 테이블이 존재하는 이유는 설명하지 않습니다.

일반적인 4D 아키텍처 설계 실수

양식 메소드에 비즈니스 로직 넣기. 양식 메소드는 웹 컨텍스트나 예약된 작업에서 호출할 수 없으므로 거기에 트랩된 로직을 복제해야 합니다.

새 코드 전반에 걸쳐 선택 기반 클래식 명령을 사용합니다. 클래식 선택은 프로세스에 국한되며 프로세스 간에 잘 이동하지 않습니다. ORDA 엔터티 선택이 더 유연합니다.

접합 테이블을 건너뛰는 것입니다. 단일 텍스트 필드(쉼표로 구분된 ID)에 여러 값을 저장하면 색인 생성이 실패하고 보고가 어려워집니다.

모든 항목을 인덱싱하는 것입니다. 쓰기 성능이 저하되고 이점이 거의 실현되지 않습니다.

배포할 때까지 권한을 무시하는 것입니다. 완성된 애플리케이션에 보안 모델을 개조하는 것은 스키마와 함께 설계하는 것보다 훨씬 어렵습니다.

결정 방법: 실용적인 체크리스트

4D 아키텍처 디자인을 구축하기 전에 다음 질문을 해결하세요.

1. 동시 사용자는 몇 명이며 LAN, WAN 또는 웹을 통해 연결됩니까?
2. 자연스러운 일대다 관계를 갖는 엔터티와 접합 테이블이 필요한 엔터티는 무엇입니까?
3. 큰 테이블의 검색 기준이나 정렬 순서에 어떤 필드가 표시됩니까?
4. 진입점(양식, 웹, 가져오기)에 관계없이 어떤 비즈니스 규칙을 유지해야 합니까?
5. UUID 키가 필요한 데이터가 다른 시스템과 병합될 예정입니까?
6. 누가 이것을 2년 동안 유지관리하며, 이름이 이해가 됩니까?

이 6가지 질문에 대한 답변이 4D 프로젝트의 구조적 결정 대부분을 결정합니다.

추가 자료

개발자.4d.com의 공식 4D 문서에서는 ORDA, 클래스, 권한 및 배포에 대해 자세히 다루고 있습니다. 플랫폼에 관계없이 적용되는 관계형 모델링 기본 사항은 데이터베이스 정규화에 대한 Wikipedia 문서를 참조하세요. 로우 코드 및 신속한 애플리케이션 개발 플랫폼의 더 넓은 맥락에서는 로우 코드 개발 플랫폼에 대한 Wikipedia 항목이 합리적인 출발점이 됩니다. 4D SAS는 또한 ORDA, 클래스 및 기타 4d 아키텍처 설계 기능이 도입된 시기를 설명하는 릴리스 노트와 마이그레이션 가이드를 게시합니다.

자주 묻는 질문

4D 아키텍처 설계란 무엇인가요?

4D 아키텍처 디자인은 4D(4차원) 애플리케이션의 구조(테이블, 필드, 관계, 인덱스, 비즈니스 로직 레이어 및 프리젠테이션 레이어)를 계획하는 프로세스입니다. 이는 애플리케이션의 성능, 얼마나 쉽게 변경할 수 있는지, 데스크톱, 클라이언트-서버 또는 웹 클라이언트에 얼마나 안전하게 배포할 수 있는지를 결정합니다.

4D 아키텍처는 4D BIM과 동일한가요?

아니요. 4D BIM은 건설 일정을 위한 건축 정보 모델링에 시간을 4번째 차원으로 추가합니다. 소프트웨어 의미의 4D 아키텍처는 4D 데이터베이스 플랫폼에서 애플리케이션을 설계하는 것을 의미합니다. 두 필드는 약어를 공유하지만 다른 것은 공유하지 않습니다.

ORDA 또는 클래식 4D 명령을 사용해야 합니까?

ORDA는 새로운 개발을 위한 최선의 선택입니다. 다시 쿼리할 필요 없이 메서드 간에 전달, 정렬 및 필터링할 수 있는 엔터티 선택을 반환하고 테이블과 필드를 읽을 수 있는 개체의 속성으로 노출합니다. 클래식 선택 기반 명령은 레거시 코드와 일부 특수한 경우에 여전히 유용합니다.

4D 테이블에는 몇 개의 인덱스가 있어야 합니까?

정해진 숫자는 없습니다. 외래 키, 일반 검색 기준에 사용되는 필드 및 큰 목록을 정렬하는 데 사용되는 필드를 색인화합니다. 일반적으로 쓰기 비용이 읽기 이점보다 크기 때문에 부울 값 또는 2~3개의 값이 있는 상태 필드와 같이 카디널리티가 낮은 필드를 인덱싱하지 마세요.

4D에서는 어떤 기본 키 유형을 선택해야 하나요?

자동 증가 longint 키는 작고 빠르며 단일 사이트 애플리케이션에 적합합니다. UUID 텍스트 키는 더 크지만 전역적으로 고유하므로 여러 사이트의 데이터를 병합하거나 외부 시스템과 통합할 때 중요합니다. 많은 프로젝트에서는 내부적으로 longint 키와 고유한 외부 참조 필드를 사용합니다.

배포 후 4D 데이터 모델을 변경할 수 있나요?

네, 하지만 조심하세요. 테이블, 필드 및 인덱스를 추가하는 것은 일반적으로 간단합니다. 필드 유형 변경, ORDA 코드에서 사용되는 필드 이름 변경 또는 라이브 데이터베이스의 관계 재구성에는 계획된 마이그레이션이 필요하며 가급적 프로덕션 데이터의 복사본에서 먼저 테스트하는 것이 좋습니다.