거기에 DBA가있는 경우, 저는 상당히 큰 소프트웨어를 만들고 있습니다. 가장 큰 문제 중 하나는 현재 비즈니스 논리를 어디에 두어야하는지입니다. 저장 프로 시저를 즉시 수정하는 것이 쉽지만 처리 요구 사항으로 인해 DB가 크게 느려질 수 있습니다. 또한 사용자 프론트 엔드가 작동하지 않아도되는 "자체 유지 엔터티"가되기를 원하기 때문에 응용 프로그램에서 모든 비즈니스 논리를 처리하기를 원하지 않습니다.SQL Server 2008의 비즈니스 로직
내 생각에, 어딘가에 중앙 서버에서 실행될 서비스를 만들고 클라이언트가이를 통해 연결되도록하는 것입니다. 이 서비스는 모든 비즈니스 로직을 유지하고 모든 데이터베이스 작업의 프런트 엔드 역할을합니다.
아이디어가 있으십니까? 예? 아니?
나는 또한 몇 가지 주요 개념을 놓치고 있으며 일부 문학을 읽을 필요가 있음을 기꺼이 받아들입니다.
"비즈니스 논리"란 무엇을 의미합니까?
집계 및 기타 세트 기반 작업이 클라이언트 코드에서 수행 된 경우와 다른 곳의 SQL에서의 끔찍한 RBAR 연산이있는 경우를 보았습니다.
SQL은 대규모 데이터 세트, JOIN, 집계 등을 처리하는 경우 SQL이이를 수행 할 수있는 도구입니다. 그 밖의 것은 SOA 이상에 대한 순종적 인 순종이다.
내 접근 방식은 저장된 proc 또는 SQL이 수행하는 작업을 고려하는 것입니다. 절차형 코드에서 집합 기반 연산을 피하기 위해 중간 계층의 일부입니까, 아니면 순수 데이터 무결성/지속성만큼 낮습니까?
비즈니스 로직 이이면 100 % 세트를 기반으로하며, 중간 계층 (편집 : 클라이언트 코드 기반)은 매우 얇지 않는 한 틀림없이 말입니다.
아, 좀 더 자세한 정보를 제공합니다. 나는 데이터베이스가 단순히 데이터 로직을 유지하도록 할 것이다. 마찬가지로,이 필드가 null 일 수 있거나 가질 수없는 경우, 상기 제한이 적용됩니다. 이 레코드를 삭제하면 하위 레코드에 계단식으로 연결해야합니다. 그러나 연체 된 예금의 경우, 연체 상태를 기록하고 싶을 수 있습니다. 이것은 중산층 응용 프로그램에 의해 수행됩니다. 재고 목록에 불일치가 있으면 중간 핸들을 사용하게 될 것입니다. 그것이 당신이 말하는 것이라고 가정합니다. – instantmusic
@instantmusic : 예. Randy의 대답은이 점보다 더 잘 표현되어 있습니다. 연체 지불은 상태 필드 (또는 뭔가)에서 SQL에 의해 결정될 수 없으며 결정되어서는 안되는 다른 값을 가진 지불 일뿐입니다. 그러나 특정 상태에 대한 지불 합산액을 계산하는 것은 클라이언트가 어떤 상태로 SUMmed를 보낼지를 결정하는 것입니다. – gbn
맞아, 나는 데이터의 상태에 관한 정보를 제공하기 위해 필요한 저장 프로 시저를 노출 할 수있다. 즉 sp_GetCustomerDelinquentTotal (고객)은 단일 고객이 체납 한 총 $$$을 반환합니다. – instantmusic
서버 측에서 모든 비즈니스 로직을 사용하는 것이 좋습니다.
서버 측에 없어도 괜찮습니다.
사실, 귀하에게 달려 있습니다.
저장 프로 시저가 sql-ish가 아닌 경향이있는 경우 CLR stored procedure을 만들 수 있습니다.
여기에 a similar question입니다.
Wicked, 링크 주셔서 감사합니다. – instantmusic
UI 레이어, 비즈니스 레이어 (예 : C# 어셈블리 또는 Java equivolent) 및 데이터 액세스가있는 기존 n 계층 접근 방식을 적극 권장합니다. 참조 : http://en.wikipedia.org/wiki/Multitier_architecture.
모든 비즈니스 로직이 procs에 있고 회사의 유지 보수 비용이 훨씬 높았 기 때문에 SQL Server의 특정 버전으로 제한되어있었습니다. 확장 성이 없었습니다. 간단히 말해서, 애플리케이션이 단순한 문제가 아니라면 비즈니스 로직을 데이터베이스에 두지 않을 것입니다.
비즈니스 논리로 생각하는 것과 참조 무결성 제약 조건이 무엇인지의 차이를 예의 주시 할 것을 제안합니다.
데이터를 유의미하게 유지하는 모든 제약 조건이 데이터베이스 계층에 있는지 확인하십시오. 즉, 일부 삭제 또는 삽입을 계단식으로 처리해야하는 경우와 모든 기본 데이터 값의 유효성을 검사하여 모든 것을 이해할 필요가있는 경우 이러한 데이터베이스가 모두 데이터베이스에 있어야합니다.
그런 다음 클라이언트, 중간 계층 서버 또는 데이터베이스가 추가 비즈니스 논리에 적합한 지 결정하십시오.
+1 비즈니스 로직과 참조 무결성의 좋은 표현 – gbn
정확히, 데이터베이스의 역할에 대해 염두에 두었던 것입니다. 바로 그 일에 감동 한 gbn의 의견에 더 많은 정보를 추가했습니다. 명확한 설명 주셔서 감사합니다, 좋은 길을 가고 있다는 것을 알았습니다. – instantmusic
지난 몇 년 동안 클라이언트 응용 프로그램을 보았지만 데이터베이스는 여전히 존재합니다.
요즘에는 대부분의 비즈니스 로직에 저장 프로 시저가 사용됩니다. 세 가지 큰 장점 :
로 다운 타임없이, 즉시 소요 당신의 건축물. 데이터베이스 또는 응용 프로그램 계층에서 비즈니스 논리를 관리하지 않으려는 경우에는 중간 서비스 계층이 확실히 준비되어 있습니다. – kbrimington