IT story

가장 일반적인 SQL 안티 패턴은 무엇입니까?

hot-time 2020. 4. 19. 13:55
반응형

가장 일반적인 SQL 안티 패턴은 무엇입니까? [닫은]

관계형 데이터베이스를 다루는 우리 모두는 SQL이 다르다는 것을 알게되었습니다. 원하는 결과를 도출하고 효율적으로 수행하려면 익숙하지 않은 패러다임을 배우고 가장 친숙한 프로그래밍 패턴 중 일부가 여기서 작동하지 않는 것을 발견하는 지루한 프로세스가 필요합니다. 당신이 본 (또는 당신이 저지른) 일반적인 반 패턴은 무엇입니까?

데이터 액세스 계층에서 UI 논리를 혼합하려는 대부분의 프로그래머 경향에 대해 일관되게 실망합니다.

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

일반적으로 프로그래머는 데이터 집합을 그리드에 직접 바인딩하려고하기 때문에 클라이언트에서 형식보다 SQL Server 형식의 서버 쪽을 사용하는 것이 편리하기 때문에이 작업을 수행합니다.

위에 표시된 것과 같은 쿼리는 데이터 레이어를 UI 레이어에 밀접하게 연결하기 때문에 매우 취약합니다. 또한,이 스타일의 프로그래밍은 저장 프로 시저를 재사용 할 수 없도록 철저히 방지합니다.

여기 내 탑 3이 있습니다.

번호 1. 필드 목록을 지정하지 못했습니다. (편집 : 혼란을 피하기 위해 : 이것은 프로덕션 코드 규칙입니다. 저자가 아닌 한 일회성 분석 스크립트에는 적용되지 않습니다.)

SELECT *
Insert Into blah SELECT *

해야한다 

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

루프 변수가있는 while 루프가 수행 될 때 커서와 while 루프를 사용합니다.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

문자열 유형을 통한 DateLogic

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

해야한다

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

최근에 "한 번의 쿼리가 두 개보다 낫습니다."라는 급증을 보았습니다.

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

이 쿼리에는 매개 변수 값에 따라 두 개 또는 세 개의 다른 실행 계획이 필요합니다. 이 SQL 텍스트에 대해 하나의 실행 계획 만 생성되어 캐시에 고정됩니다. 이 계획은 매개 변수의 값에 관계없이 사용됩니다. 결과적으로 간헐적으로 성능이 저하됩니다. 의도 된 실행 계획 당 하나의 쿼리 인 두 개의 쿼리를 작성하는 것이 훨씬 좋습니다.

  • 사람이 읽을 수있는 비밀번호 필드 (예 : ad) 자기 설명.

  • 인덱스 열에 대해 LIKE를 사용하면 일반적으로 LIKE라고 말하고 싶어합니다.

  • SQL 생성 PK 값을 재활용합니다.

  • 서프라이즈 아무도 언급하지 신 테이블을 아직. 100 열의 비트 플래그, 큰 문자열 및 정수와 같은 "유기적"이라는 것은 없습니다.

  • 그런 다음 CSV 파일 , 파이프로 구분 된 문자열 또는 기타 구문 분석이 필요한 데이터를 큰 텍스트 필드에 저장하는 ".ini 파일이 누락되었습니다" 패턴이 있습니다.

  • 그리고 MS SQL 서버의 경우 커서 를 전혀 사용하지 않습니다 . 주어진 커서 작업을 수행하는 더 좋은 방법이 있습니다.

너무 많아 편집했습니다!

깊이 파고들 필요가 없습니다. 준비된 진술을 사용하지 마십시오.

무의미한 테이블 별칭 사용 :

from employee t1,
department t2,
job t3,
...

큰 SQL 문을 읽는 것보다 훨씬 어렵게 만듭니다.

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";
  1. 맹목적으로 신뢰하는 사용자 입력
  2. 매개 변수화 된 쿼리를 사용하지 않음
  3. 일반 텍스트 비밀번호

내 버그 베어는 450 명의 열 액세스 테이블이며 상무 이사의 가장 친한 친구 개 그 루머의 8 살짜리 아들과 누군가가 데이터 구조를 올바르게 정규화하는 방법을 모르기 때문에 존재하는 닷지 조회 테이블입니다.

일반적으로이 조회 테이블은 다음과 같습니다.

ID INT,
NVARCHAR (132) 이름,
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
날짜 1 DATETIME,
날짜 2 DATETIME

나는 이와 같은 가증에 의존하는 시스템을 가지고있는 고객을 보았습니다.

내가 가장 싫어하는 것은

  1. CamelCase 또는 under_scores 및 단수 또는 복수형 및 대문자 또는 소문자로 괜찮지 만 특히 [이상하게 간격이있는 경우] (예, 공백이있는 경우) 테이블 또는 열을 참조해야합니다 (예, 나는 이것에 부딪쳤다) 정말로 나를 자극한다.

  2. 비정규 화 된 데이터. 테이블을 완벽하게 정규화 할 필요는 없지만 현재 평가 점수 또는 주요 사항에 대한 정보가있는 직원 테이블에 닿으면 특정 시점에서 별도의 테이블을 만들어야 할 것입니다. 그런 다음 동기화 상태를 유지하십시오. 먼저 데이터를 정규화 한 다음 비정규 화가 도움이되는 곳을 찾으면 고려하겠습니다.

  3. 뷰 또는 커서를 과도하게 사용합니다. 뷰에는 목적이 있지만 각 테이블이 뷰에 래핑되면 너무 많습니다. 커서를 몇 번 사용해야했지만 일반적으로 다른 메커니즘을 사용할 수 있습니다.

  4. 접속하다. 프로그램이 반 패턴 일 수 있습니까? 우리 회사에는 SQL Server가 있지만 기술이 아닌 사용자에게는 "사용 편의성"및 "친 화성"이라는 가용성으로 인해 많은 사람들이 액세스를 사용합니다. 여기에 너무 많은 것이 있지만, 비슷한 환경에 있다면 알고 있습니다.

저장 프로 시저 이름의 접두사 인 SP를 먼저 사용하십시오. 왜냐하면 사용자 지정 위치가 아닌 시스템 프로 시저 위치에서 먼저 검색하기 때문입니다.

임시 테이블 및 커서의 남용.

시간 값을 저장하려면 UTC 시간대 만 사용해야합니다. 현지 시간을 사용해서는 안됩니다.

SCOPE_IDENTITY () 대신 @@ IDENTITY 사용

이 답변 에서 인용 :

  • @@ IDENTITY 는 모든 범위에서 현재 세션의 테이블에 대해 생성 된 마지막 ID 값을 반환합니다. 범위가 다르므로 여기서주의해야합니다. 현재 명령문 대신 트리거에서 값을 얻을 수 있습니다.
  • SCOPE_IDENTITY 는 현재 세션 및 현재 범위의 테이블에 대해 생성 된 마지막 ID 값을 반환합니다. 일반적으로 사용하고 싶은 것.
  • IDENT_CURRENT 는 모든 세션 및 범위에서 특정 테이블에 대해 생성 된 마지막 ID 값을 반환합니다. 이를 통해 위의 두 가지가 필요한 것이 아닌 경우 (매우 드문 경우) 값을 원하는 테이블을 지정할 수 있습니다. 레코드를 삽입하지 않은 테이블의 현재 IDENTITY 값을 가져 오려는 경우이를 사용할 수 있습니다.

의도하지 않은 용도로 '죽은'필드를 재사용합니다 (예 : '팩스'필드에 사용자 데이터 저장) – 빠른 수정으로 매우 유혹적입니다!

select some_column, ...
from some_table
group by some_column

결과가 some_column으로 정렬된다고 가정합니다. Sybase에서 가정이 유지되는 현재 부분을 보았습니다.

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

또는 모든 것을 한 줄에 넣습니다.

  • FROM TableA, TableB WHERE에 대한 구문보다는 JOINSFROM TableA INNER JOIN TableB ON

  • 쿼리가 반환 될 것이라고 가정하면 쿼리 도구에서 테스트하는 동안 ORDER BY 절을 넣지 않고 특정 방식으로 정렬됩니다.

경력의 첫 6 개월 동안 SQL을 배우고 향후 10 년 동안 다른 것을 배우지 마십시오. 특히 창 / 분석 SQL 기능을 배우거나 효과적으로 사용하지 않습니다. 특히 over () 및 by by를 사용합니다.

집계 함수와 같은 창 함수는 정의 된 행 세트 (그룹)에 대해 집계를 수행하지만 그룹당 하나의 값을 반환하는 대신 창 함수는 각 그룹에 대해 여러 값을 반환 할 수 있습니다.

윈도우 기능에 대한 훌륭한 개요는 O'Reilly SQL Cookbook 부록 A 를 참조하십시오 .

나는 목록을 완성하기 위해 현재 자신이 좋아하는 것을 여기에 넣어야합니다. 내가 가장 좋아하는 반 패턴은 쿼리를 테스트하지 않습니다 .

다음과 같은 경우에 적용됩니다.

  1. 쿼리에 둘 이상의 테이블이 포함됩니다.
  2. 쿼리에 대한 최적의 디자인이 있다고 생각하지만 가정을 테스트하지 않아도됩니다.
  3. 최적화 된 쿼리에 가까운 지에 대한 단서없이 작동하는 첫 번째 쿼리를 수락합니다.

그리고 모든 테스트는 비정형 또는 불충분 한 데이터에 대해 실행되지 않습니다. 저장 프로 시저 인 경우 테스트 문을 주석에 넣고 결과와 함께 저장하십시오. 그렇지 않으면 결과와 함께 코드에 주석을 추가하십시오.

임시 테이블 남용.

구체적으로 이런 종류의 것 :

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

쿼리에서 임시 테이블을 작성하지 말고 필요없는 행만 삭제하십시오.

그리고 예, 프로덕션 DB 에서이 형식의 코드 페이지를 보았습니다.

반대 론적 견해 : 정규화에 대한 과도한 집착.

대부분의 SQL / RBDB 시스템은 정규화되지 않은 데이터에서도 매우 유용한 기능 (트랜잭션, 복제)을 제공합니다. 디스크 공간이 저렴하고 1NF 스키마를 작성하는 것보다 페치 된 데이터를 조작 / 필터링 / 검색하는 것이 더 간단하고 (더 쉬운 코드, 개발 시간이 더 빠름), 모든 복잡한 문제 (복잡한 조인, 불쾌한 하위 선택)를 처리 할 수 ​​있습니다. 등).

과도 표준화 된 시스템은 특히 조기 개발 단계에서 조기에 최적화되는 경우가 많습니다.

(더 많은 생각은 ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

SO에 대한 SQL 응답 중 일부를 기반 으로이 것을 하나로 묶었습니다.

이벤트 핸들러가 OOP에 따라 트리거가 데이터베이스에 있다고 생각하는 것은 심각한 반 패턴입니다. 트랜잭션 (이벤트)이 테이블에서 발생할 때 발생하는 오래된 로직 만 트리거에 넣을 수 있다는 인식이 있습니다.

사실이 아니다. 가장 큰 차이점 중 하나는 트리거가 행 작업이 아닌 세트 작업에서 동기식이기 때문에 트리거가 복수라는 점입니다. OOP 측면에서 정확히 반대의 이벤트는 비동기 트랜잭션을 구현하는 효율적인 방법입니다.

주석이없는 저장 프로 시저 또는 함수 ...

1) 이것이 "공식적인"안티 패턴인지는 모르지만 데이터베이스 열에서 문자열 리터럴을 마술 값으로 사용하는 것을 싫어합니다.

MediaWiki의 테이블 'image'의 예 :

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(방금 다른 케이싱, 피해야 할 또 다른 것을 알았습니다)

int 기본 키를 사용하여 ImageMediaType 및 ImageMajorMime 테이블에 대한 int 조회와 같은 사례를 디자인합니다.

2) 특정 NLS 설정에 의존하는 날짜 / 문자열 변환

CONVERT(NVARCHAR, GETDATE())

형식 식별자없이

쿼리에서 동일한 하위 쿼리

  • Altered View (변경된보기)-통지 나 이유없이 너무 자주 변경되는보기입니다. 변경은 가장 부적절한 시간에 통지되거나 더 잘못되어 통지되지 않습니다. 누군가가 해당 열의 더 나은 이름을 생각했기 때문에 응용 프로그램이 중단 될 수 있습니다. 일반적으로 소비자와 계약을 유지하면서 기본 테이블의 유용성을 확장해야합니다. 새로운보기를 만들기 위해 문제를 해결하지만 기능을 추가하거나 변경 동작을 악화시키지 마십시오. 완화하려면 다른 프로젝트와 뷰를 공유하지 않고 플랫폼이 허용 하는 경우 CTE 를 사용하십시오. 상점에 DBA가있는 경우보기를 변경할 수 없지만 모든보기는 오래되거나 쓸모가 없습니다.

  • ! Paramed-쿼리에 둘 이상의 목적이있을 수 있습니까? 아마 다음에 읽는 사람은 깊은 명상을하기 전까지는 알 수 없을 것입니다. 지금 당장 필요하지 않더라도 디버그하는 것이 "단지"라도 가능할 것입니다. 매개 변수를 추가하면 유지 보수 시간이 줄어들고 건조가 유지됩니다. where 절이 있으면 매개 변수가 있어야합니다.

  • CASE가없는 경우- 

    SELECT  
CASE @problem  
  WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
    THEN 'Create a table for lookup and add to your from clause.'  
  WHEN 'Scrubbing values in the result set based on some business rules.'  
    THEN 'Fix the data in the database'  
  WHEN 'Formating dates or numbers.'   
    THEN 'Apply formating in the presentation layer.'  
  WHEN 'Createing a cross tab'  
    THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END

가장 많이 찾은 두 가지 성능 측면에서 상당한 비용이 발생할 수 있습니다.

  • 세트 기반 표현식 대신 커서 사용. 프로그래머가 절차 적으로 생각할 때이 문제가 자주 발생한다고 생각합니다.

  • 파생 테이블에 대한 조인이 작업을 수행 할 수있는 경우 상관 하위 쿼리를 사용합니다.

임시 테이블, 특히 SQL Server에서 Oracle로 전환하는 사람들은 임시 테이블을 과도하게 사용하는 습관이 있습니다. 중첩 된 select 문만 사용하십시오.

SQL 응용 프로그램 (개별 쿼리 및 다중 사용자 시스템 모두)이 빠르거나 느리게 만드는 이유에 대한 좋은 아이디어없이 쿼리를 작성하는 개발자. 여기에는 다음에 대한 무지가 포함됩니다.

  • 대부분의 쿼리 병목 현상이 CPU가 아닌 I / O 인 경우 물리적 I / O 최소화 전략
  • 여러 종류의 물리적 스토리지 액세스에 대한 성능 영향 (예 : 물리적 스토리지가 SSD 인 경우 적은 수의 순차적 I / O가 많은 소규모 임의 I / O보다 빠를 것입니다!)
  • DBMS가 잘못된 쿼리 계획을 생성하는 경우 쿼리를 수동으로 조정하는 방법
  • 데이터베이스 성능 저하 진단, 느린 쿼리 "디버그"방법 및 쿼리 계획을 읽는 방법 (선택한 DBMS에 따라 EXPLAIN)
  • 다중 사용자 애플리케이션에서 처리량을 최적화하고 교착 상태를 피하기위한 잠금 전략
  • 데이터 세트 처리를 처리하기위한 배치 및 기타 트릭의 중요성
  • 공간과 성능의 균형을 최상으로 유지하기위한 테이블 및 인덱스 디자인 (예 : 인덱스 커버링, 가능한 경우 인덱스를 작게 유지, 필요한 최소 크기로 데이터 유형 축소 등)

영광스러운 ISAM (Indexed Sequential Access Method) 패키지로 SQL 사용. 특히, SQL 문을 하나의 큰 명령문으로 결합하는 대신 커서를 중첩합니다. 실제로 옵티마이 저가 할 수있는 것이 많지 않기 때문에 이것은 옵티마이 저의 남용으로 간주됩니다. 이것은 비 효율성을 극대화하기 위해 준비되지 않은 진술과 결합 될 수 있습니다.

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

올바른 해결책은 (거의 항상) 두 개의 SELECT 문을 하나로 결합하는 것입니다.

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

이중 루프 버전의 유일한 장점은 내부 루프가 끝나기 때문에 Table1의 값 사이를 쉽게 구분할 수 있다는 것입니다. 이는 제어 중단 보고서의 요소가 될 수 있습니다.

또한 응용 프로그램에서의 정렬은 일반적으로 아니오입니다.

레코드 주소의 대용으로 기본 키를 사용하고 레코드에 포함 된 포인터의 대용으로 외래 키를 사용합니다.

참고 URL : https://stackoverflow.com/questions/346659/what-are-the-most-sql-anti-patterns

반응형

'IT story' 카테고리의 다른 글

Swift에서 UI_USER_INTERFACE_IDIOM ()으로 현재 장치 감지  (0) 2020.04.19
iOS 시뮬레이터에서 콘솔 로그를 얻으려면 어떻게해야합니까?  (0) 2020.04.19
명령 행을 사용하여 postgres 백업 파일을 복원 하시겠습니까?  (0) 2020.04.18
Bash의 간단한 논리 연산자  (0) 2020.04.18
끈적 끈적하고 비 스틱 세션  (0) 2020.04.18

'IT story'의 다른글

  • 현재글가장 일반적인 SQL 안티 패턴은 무엇입니까?

관련글

댓글

티스토리툴바