Postgres의 SQL 이외의 언어

StackOverflow https://stackoverflow.com/questions/39517

문제

저는 최근에 PostgreSQL을 조금 사용해 왔는데, 제가 생각하기에 멋지다고 생각하는 것 중 하나는 스크립팅 기능 등에 SQL 이외의 언어를 사용할 수 있다는 것입니다.하지만 이것이 실제로 언제 유용할까요?

예를 들어 문서에는 PL/Perl의 주요 용도는 텍스트 조작에 매우 능숙하다는 것입니다.하지만 이는 애플리케이션에 프로그래밍되어야 하는 것 이상의 의미가 있지 않습니까?

둘째, 신뢰할 수 없는 언어를 사용해야 할 타당한 이유가 있습니까?모든 사용자가 모든 작업을 실행할 수 있도록 만드는 것은 프로덕션 시스템에서는 좋지 않은 생각인 것 같습니다.

추신.누군가가 만들 수 있다면 보너스 포인트 PL/LO코드 유용할 것 같습니다.

도움이 되었습니까?

해결책

"그것은 [텍스트 조작]이 애플리케이션에 프로그래밍되어야 하는 것에 더 가깝지 않나요?"

보통 그렇습니다.일반적으로 인정되는 "삼층" 데이터베이스용 애플리케이션 설계에서는 논리가 클라이언트와 데이터베이스 사이의 중간 계층에 있어야 한다고 말합니다.그러나 때로는 트리거에 일부 논리가 필요하거나 함수에 대한 인덱스가 필요하므로 일부 코드를 데이터베이스에 배치해야 합니다.이 경우 모든 일반적인 "어떤 언어를 사용해야합니까?" 질문이 나옵니다.

약간의 로직만 필요한 경우 가장 이식성이 높은 언어(pl/pgSQL)를 사용해야 합니다.하지만 진지한 프로그래밍을 해야 한다면 좀 더 표현력이 풍부한 언어(아마도 pl/ruby)를 사용하는 것이 더 나을 수도 있습니다.이것은 항상 판단의 요청이 될 것입니다.

"신뢰할 수 없는 언어를 사용해야 할 타당한 이유가 있나요?"

위와 같이 그렇습니다.다시 말하지만, 가능하면 중간 계층에 직접 파일 액세스(예를 들어)를 두는 것이 가장 좋지만, 트리거를 기반으로 작업을 시작해야 하는 경우(중간 계층에서 직접 사용할 수 없는 데이터에 액세스해야 할 수도 있음) 신뢰할 수 없는 보안이 필요합니다. 언어.이는 이상적이지 않으며 일반적으로 피해야 합니다.그리고 이에 대한 접근을 반드시 보호해야 합니다.

다른 팁

@마이크:이런 생각이 나를 불안하게 만든다.나는 "이것은 무한히 이식 가능해야 한다"는 말을 여러 번 들었지만 질문을 받으면 다음과 같습니다.실제로 이식이 있을 것이라고 예상하시나요?정답은:아니요.

최소 공통 분모를 고수하면 추상화 계층(ORM, PHP PDO 등)을 도입할 때처럼 성능이 실제로 저하될 수 있습니다.내 의견은 다음과 같습니다.

  • 여러 RDBMS를 지원해야 하는지 현실적으로 평가하세요.예를 들어 오픈 소스 웹 애플리케이션을 작성하는 경우 최소한 MySQL 및 PostgreSQL을 지원해야 할 가능성이 있습니다(MSSQL 및 Oracle이 아닌 경우).
  • 평가 후 결정한 플랫폼을 최대한 활용하세요

그리고 그런데:관계형 데이터베이스와 비관계형 데이터베이스를 혼합하고 있습니다(CouchDB는 ~ 아니다 예를 들어 Oracle과 비교할 수 있는 RDBMS)는 이식성에 대한 인식된 필요성이 여러 번 크게 과대평가되었다는 점을 더욱 예시합니다.

요즘에는 DBMS의 "독특한" 기능이나 "멋진" 기능이 나를 엄청나게 불안하게 만듭니다.나는 발진이 생기고 가려움증이 사라질 때까지 일을 중단해야 합니다.

나는 불필요하게 플랫폼에 갇히는 것을 싫어합니다.데이터베이스 내부에 PL/Perl로 시스템의 큰 부분을 구축한다고 가정해 보세요.또는 SQL Server의 C#이나 Oracle의 PL/SQL에는 많은 예제가 있습니다*.

이제 선택한 플랫폼이 확장되지 않는다는 사실을 갑자기 발견하게 됩니다.아니면 충분히 빠르지 않습니다.또는 뭔가.더 나쁜 것은 데이터베이스 블록(MonetDB, CouchDB, Cache와 같은 것이지만 훨씬 더 멋진 것)에 모든 문제를 해결할 새로운 아이가 있다는 것입니다(나와 같은 유일한 문제가 멋지지 않은 데이터베이스 플랫폼을 가지고 있는 경우에도).그리고 신청서의 절반을 기록하지 않고는 전환할 수 없습니다.

(*물론 유료 제품은 어느 정도 사용자가 고유한 기능을 사용하도록 설득하여 사용자를 가두려고 합니다. 이는 무료 공급자를 직접 비난할 수는 없지만 효과는 동일합니다.)

그래서 그것은 질문의 첫 번째 부분에 대한 폭언입니다.하지만 진심으로.

신뢰할 수없는 언어를 사용해야 할 유효한 이유가 있습니까?모든 사용자가 작업을 실행할 수 있도록하는 것 같습니다.

맙소사, 그렇죠!일종의 "Perl 주입 공격"인가요?무슨 일이 일어나는지 보는 것만으로도 거의 할 가치가 있다고 생각했을 것입니다.

위에 설명된 철학적 이유 때문에 나는 PL/LOLCODE 챌린지를 통과할 것이라고 생각합니다.비록 그것이 현존하는 어떤 것에 대한 연결이라는 사실을 알고 다소 놀랐지만.

내 관점에서 볼 때 대답은 '상황에 따라 다르다'인 것 같다.

데이터 조작이 데이터베이스 계층에 속하므로 비즈니스 로직은 조작이 어떻게 일어나는지에 대해 지나치게 걱정할 필요가 없으며 단지 조작이 발생했다는 것만 알고 있다는 주장이 있습니다.

db 계층에서 데이터를 처리하는 또 다른 좋은 이유는 처리되는 데이터의 양이 네트워크 대역폭이 문제가 된다는 것을 의미하는 경우입니다.나는 한때 매우 많은 양의 데이터를 분류해야 했습니다.애플리케이션 계층에서 이를 처리하는 것은 처리를 위해 네트워크를 통해 모든 데이터를 전송하는 데 필요한 시간으로 인해 심각하게 제한되었습니다.

그런 다음 PL/pgSQL에 비닝 알고리즘을 작성했는데 훨씬 빠르게 작동했습니다.

신뢰할 수 없는 언어에 관해서는 Josh Berkus(포스트그레스 옹호자)로부터 처리의 일부로 MySQL에서 데이터를 가져와 통신 자체가 포스트그레스 서버에 의해 처리되는 포스트그레SQL의 애플리케이션에 대해 논의한 팟캐스트를 들었습니다.자세한 내용은 기억나지 않습니다. FLOSS 주간 팟캐스트 이는 PostGRESQL의 역사와 그에 따른 몇 가지 문제에 대한 매우 흥미로운 토론입니다.

신뢰할 수 없는 버전의 절차적 언어를 사용하면 시스템의 I/O에 액세스할 수 있습니다.트리거가 필요하거나 이메일을 보내거나 소켓 서버에 연결하여 팝업 알림을 보내는 경우 유용할 수 있습니다.이러한 유형의 용도는 다양하며 postgresql 격리 수준으로 인해 이와 같은 작업을 안전하게 수행할 수 있습니다.함수에 체크포인트를 넣어 거래가 실패하더라도 이메일이 발송되지 않도록 할 수 있습니다.이 작업의 좋은 점은 클라이언트에서 로직을 제거하여 서버에 배치한다는 것입니다.

대부분의 추가 언어가 제공되므로 정기적으로 해당 언어로 개발하면 db 함수, 트리거 등을 작성하는 것이 편안하다고 생각합니다.이러한 기능의 유용성은 가능한 한 데이터에 가깝게 데이터를 제어할 수 있다는 것입니다.

최근에 제가 pl/sql에서는 불가능했던 외부 언어로 작성한 유용한 저장 프로시저의 예는 SQL 테이블 생성기가 런타임 시 사용 가능한 여유 공간이 가장 많은 테이블스페이스를 선택할 수 있게 해주는 'df' 버전입니다.

저는 plperlu를 사용했는데, 데이터 입력에 주의해야 했지만 비교적 간단했습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top