나중에 실행하기 위해 SQL 문을 테이블에 저장하는 것이 나쁜 생각입니까?

나중에 실행하기 위해 SQL 문을 MySQL 테이블에 저장하는 것이 나쁜 생각입니까? SQL 문은 실행할 준비가됩니다 DELETE FROM users WHERE id=1. 예를 들어 스왑 할 매개 변수가 없습니다 .

나는 게으르다 고 생각하지만 SQL 문을 주기적으로 실행하는 꽤 많은 cron 작업이 필요한 프로젝트에서 작업하고 있기 때문에이 아이디어를 생각했습니다.

그것이 당신이 요구하는 것이면 안전합니다. 데이터 보안과 마찬가지로 보안에주의를 기울이는 한.

그러나 저장 프로시 저는 테이블에 저장된 SQL의 일부입니다. 그리고 그들은 매개 변수화를 지원합니다.

또한 cron 대신 MySql Event Scheduler 를 사용하여 보안을 단순화하고 실패 지점을 줄이고 네트워크 통신을 줄일 수 있습니다 .

다른 데이터베이스에는 그와 동등한 이유가 있습니다. 이 기능이 가장 먼저 필요한 것은 아닙니다.

나중에 실행하기 위해 데이터베이스에 SQL 문을 저장하려면 테이블에 저장하는 것보다 더 나은 옵션이 있습니다.이 특정 목적을 위해 제공된 기본 제공 기능을 사용하십시오. 저장 프로 시저에 넣으십시오.

아니요, 좋은 생각이 아닙니다.

이는 모든 "실제"쿼리 / 업데이트가 데이터베이스에서 2 개의 적중이 필요함을 의미합니다. 하나는 "실제"쿼리 / 업데이트를 얻고 다른 하나는이를 실행합니다.

소규모 시스템에서는 큰 문제가되지 않지만 시스템에 대한 사용자 / 트랜잭션이 많을수록 시스템 규모는 줄어 듭니다.

이것이 코드에 SQL을 포함시키는 대안을 찾는 것에서 비롯된 것 같습니다.

Mason Wheeler가 제안한 것처럼 스토어드 프로 시저에서 SQL을 캡슐화하는 것이이 아이디어보다 훨씬 좋은 방법입니다.

죄송합니다. 좋은 생각은 아닙니다.

해당 테이블이 변경되는 경우를 고려하십시오. id 열의 이름이 new_id 로 바뀌 었다고 가정하십시오 .

변경 사항뿐만 아니라 더 이상 실행되지 않을 오래된 빈티지 데이터베이스 용으로 작성된 코드 버전이 있습니다. 물론, 코드 테이블을 체크인하는 것을 알고 있지만 다른 사람에게는 즉시 명확하지 않습니다.

내가 설명한 것과 같은 변경을 위해 일반적으로 독립 실행 형 SQL 파일, 저장 프로 시저, 트리거, 클라이언트 코드 (VB, C #, C ++ 등)의 인라인 SQL을 보았지만 마지막으로 생각할 곳은 데이터베이스 테이블에 있습니다. 어쩌면 내가 지금 할 것입니다! :)

SQL을 테이블에 저장해야하는 유효한 이유가 있습니다. 직장에서 작업하는 소프트웨어에는 이제 문서를 생성하는 시스템이 포함되어 있으며 문서는 데이터베이스의 데이터를 사용하여 상당히 복잡한 계산을 포함해야합니다. 문서는 자주 업데이트되며 필요한 데이터 및 수행해야 할 계산 측면에서 크게 다릅니다. 기본적으로 SQL은 이러한 계산을 수행하기위한 스크립팅 언어로 사용되며 SQL은 이러한 문서에 대한 다른 정보도 저장하는 테이블에 저장됩니다. 이러한 문서를 관리하는 사람들은 프로그래머 나 DBA는 아니지만 데이터베이스 스키마에 익숙하고 SQL에 능숙합니다. 해당 SQL 코드를 스토어드 프로 시저 형태로 유지 보수하는 것은 상당한 오버 헤드입니다.

"... 정기적으로 SQL 문을 실행하는 크론 작업이 많이 필요한 프로젝트"에 대해 설명했듯이, 다른 대답은 아마도 DBMS에 대해 스토어드 프로 시저 또는 이와 동등한 것을 사용했음을 암시하는 것이 맞을 것입니다. 다시 사용하십시오.

테이블에 저장 프로 시저에 SQL을 저장할 수 있는지 여부를 결정하기위한 좋은 기준은 해당 SQL을 유지할 사람을 결정하는 것입니다. 사용자가 해당 SQL을 유지 관리하는 경우, 즉 SQL을 작성하고 원할 때마다 변경하는 경우 해당 SQL을 테이블에 저장하는 것이 좋습니다. 개발자가 해당 SQL을 유지 관리하는 경우에는 (자체적으로 자동화 된) 빌드 및 배포 절차 (예 : 데이터베이스 자체의 저장 프로 시저와 같은 개체로 저장)로 업데이트 할 수있는 형식으로 저장해야합니다.

쉬운 방법은 .ini 또는 다른 구성 플레이버 파일을 사용하여 쿼리를 유지하는 것입니다.이 방법으로 한 곳에서 쿼리를 수행 할 수 있으며 데이터베이스에 액세스 할 필요없이 아무것도 변경하지 않고 데이터베이스를 여러 번 누르지 않아도됩니다 또한 어느 시점에서 매개 변수를 사용하거나 쿼리에 조건을 추가하고 싶을 수도 있습니다 (코드의 특정 경우에 대해 더 복잡한 것들로 매개 변수를 보강하십시오).

물론 데이터베이스 수준 (테이블이나 더 나은 저장 프로 시저로)을 유지할 수는 있지만 ;-)처럼 게으르지 만 성능, .ini 파일 및 PHP 와 관련이 있습니다. 그것을 읽는 사랑하는 parse_ini 메소드는 갈 길입니다 (다른 프로그래밍 언어를 사용하는 경우 비슷한 접근법을 알아 내야합니다)! 일반적으로 응용 프로그램의 부트 로더 에서이 파일을 읽고 정적 객체 (캐시 레이어가 맨 위에있을 수 있음)에 보관하여 매우 많은 수의 별개의 쿼리에 대해 이야기 할 때 실제로 속도를 높입니다.

예를 들어, 근무 외 시간 동안 수행 할 여러 조작을 큐에 대기하는 경우 SQL 문이 한 번만 필요한 경우에는 테이블에 넣는 것이 좋습니다.

지정된 간격으로 동일한 SQL 문을 실행해야하는 경우 다른 사용자가 언급 한 스토어드 프로 시저 라우트가 더 나은 선택 일 수 있습니다.

즉, 당신이 요구하는 것은 매우 이례적이며 다른 문제가 있음을 나타낼 수 있습니다. 예를 들어, 데이터베이스에서 사용자 삭제를 기다리는 경우 실제 SQL 문을 기록하지 않고 애플리케이션 코드를 통해 조작을 수행하는 스케줄 된 스크립트를 호출하는 것이 좋습니다. 이런 식으로 SQL과 코드가 동기화되지 않습니다.