우리가 좋아하든 그렇지 않든, 대부분의 개발자는 아니지만 정기적으로 데이터베이스를 사용하거나 언젠가는 작업해야 할 수도 있습니다. 야생에서 오용 및 남용의 양과 매일 발생하는 데이터베이스 관련 질문의 양을 고려할 때 개발자가 설계하거나 작업하지 않더라도 개발자가 알아야 할 특정 개념이 있다고 말하는 것이 공정합니다. 오늘 데이터베이스. 그래서:

개발자와 다른 소프트웨어 전문가가 데이터베이스에 대해 알아야 할 중요한 개념은 무엇입니까?

답변 지침 :

목록을 짧게 유지하십시오.
답변 당 하나의 개념이 가장 좋습니다.

구체적으로 작성하십시오 .
"데이터 모델링"은 중요한 기술 일 수 있지만 정확히 무엇을 의미합니까?

당신의 근거를 설명하십시오.
개념이 왜 중요한가요? "인덱스 사용"이라고 말하지 마십시오. "모범 사례"에 빠지지 마십시오. 청중이 더 많은 것을 배우도록 설득하십시오.

귀하의 의견에 동의하십시오.
다른 사람의 답변을 먼저 읽으십시오. 하나의 높은 순위 답변은 두 개의 낮은 순위 답변보다 더 효과적인 진술입니다. 더 추가해야 할 경우 의견을 추가하거나 원본을 참조하십시오.

개인적으로 적용되지 않기 때문에 무언가를 공감하지 마십시오.
우리는 모두 다른 영역에서 일합니다. 여기서의 목표는 데이터베이스 초보자들에게 데이터베이스 설계 및 데이터베이스 중심 개발에 대한 잘 정립되고 균형 잡힌 이해를 얻을 수있는 방향을 제공하는 것입니다.

개발자가 데이터베이스에 대해 알아야 할 첫 번째 사항은 다음과 같습니다. 데이터베이스 란 무엇 입니까? 작동 방식, 빌드 방식 및 데이터베이스의 데이터를 검색하거나 업데이트하는 코드를 작성하는 방법이 아닙니다. 그러나 그들은 무엇입니까?

불행히도 이것에 대한 대답은 움직이는 목표입니다. 1970 년대부터 1990 년대 초 데이터베이스의 데이터베이스에서는 데이터 공유를위한 데이터베이스가 사용되었습니다. 데이터베이스를 사용 중이고 데이터를 공유하지 않은 경우 학술 프로젝트에 참여했거나 본인을 포함하여 리소스를 낭비한 경우 데이터베이스를 설정하고 DBMS를 길들이는 것은 여러 번 악용 된 데이터 측면에서 투자 회수에 막대한 투자가 필요했던 엄청난 작업이었습니다.

지난 15 년 동안 데이터베이스는 단 하나의 응용 프로그램과 관련된 영구 데이터를 저장하는 데 사용되었습니다. MySQL 또는 Access 또는 SQL Server 용 데이터베이스를 구축하는 것은 일상적인 것이되어 데이터베이스는 거의 일반적인 응용 프로그램의 일부가되었습니다. 때로는 데이터의 실제 가치가 명백 해짐에 따라 초기 제한 미션이 미션 크리프에 의해 위로 밀려납니다. 불행하게도, 단일 목적을 염두에두고 설계된 데이터베이스는 전사적이며 업무상 중요한 역할을 수행하기 시작할 때 종종 실패합니다.

개발자가 데이터베이스에 대해 알아야 할 두 번째 사항 은 전 세계의 데이터 중심 관점 입니다. 데이터 중심 세계 뷰는 대부분의 개발자가 배운 것보다 프로세스 중심 세계 뷰와 다릅니다. 이 간격과 비교하여 구조적 프로그래밍과 객체 지향 프로그래밍의 간격은 비교적 작습니다.

개발자가 적어도 개요에서 배워야 할 세 번째 사항은 개념적 데이터 모델링, 논리 데이터 모델링 및 실제 데이터 모델링을 포함한 데이터 모델링입니다.

개념적 데이터 모델링 은 실제로 데이터 중심 관점에서 요구 사항을 분석하는 것입니다.

논리 데이터 모델링 은 일반적으로 개념적 데이터 모델링에서 발견 된 요구 사항에 특정 데이터 모델을 적용하는 것입니다. 관계형 모델은 다른 특정 모델보다 훨씬 많이 사용되므로 개발자는 관계형 모델을 확실히 배워야합니다. 사소한 요구 사항을위한 강력하고 관련성있는 관계형 모델을 설계하는 것은 쉬운 일이 아닙니다. 관계형 모델을 잘못 이해하면 좋은 SQL 테이블을 작성할 수 없습니다.

실제 데이터 모델링 은 일반적으로 DBMS에 따라 다르며 개발자가 데이터베이스 빌더 또는 DBA가 아니라면 자세히 배울 필요는 없습니다. 개발자가 이해해야하는 것은 실제 데이터베이스 설계를 논리적 데이터베이스 설계와 분리 할 수있는 정도와 실제 설계를 조정하여 고속 데이터베이스를 생성 할 수있는 정도입니다.

다음으로 개발자가 배워야 할 것은 속도 (성능)는 중요하지만, 설계 범위를 측정하고 확장하는 능력, 프로그래밍의 단순성 등 다른 디자인 우수성 척도는 더욱 중요하다는 것 입니다.

마지막으로, 데이터베이스를 망친 사람 은 데이터의 가치가 데이터를 캡처 한 시스템보다 오래 지속 된다는 것을 이해해야 합니다 .

아휴!

좋은 질문. 다음은 특별한 순서가 아닌 몇 가지 생각입니다.

1. 최소한 두 번째 정규 형식으로 정규화가 필수적입니다.

2. 적절한 계단식 삭제 및 업데이트 고려 사항과 함께 참조 무결성도 필수적입니다.

3. 점검 제한 조건의 적절하고 올바른 사용. 데이터베이스가 가능한 한 많은 작업을 수행하도록하십시오.

4. 데이터베이스와 미들 티어 코드 모두에 비즈니스 로직을 분산시키지 마십시오. 가급적 중간 계층 코드에서 하나를 선택하십시오.

5. 기본 키와 클러스터 키에 대한 일관된 접근 방식을 결정하십시오.

6. 인덱스를 과도하게 사용하지 마십시오. 현명하게 색인을 선택하십시오.

7. 일관된 테이블 및 열 이름. 표준을 선택하고 준수하십시오.

8. 데이터베이스에서 널값을 승인 할 열 수를 제한하십시오.

9. 방아쇠를 가지고 다니지 마십시오. 그들은 사용하지만 서둘러 복잡한 일을 할 수 있습니다.

10. UDF에주의하십시오. 그것들은 훌륭하지만 쿼리에서 얼마나 자주 호출되는지 알지 못할 때 성능 문제를 일으킬 수 있습니다.

11. 데이터베이스 디자인에 관한 Celko의 책을 얻으십시오. 남자는 거만하지만 그의 것을 알고 있습니다.

먼저 개발자는 데이터베이스에 대해 알아야 할 것이 있다는 것을 이해해야합니다. 그것들은 SQL에 넣고 결과 세트를 얻는 마술 장치 일뿐 만 아니라 자체 논리와 단점이있는 매우 복잡한 소프트웨어입니다.

둘째, 다른 목적으로 다른 데이터베이스 설정이 있습니다. 사용 가능한 데이터웨어 하우스가있는 경우 개발자가 온라인 트랜잭션 데이터베이스에서 히스토리 보고서를 작성하는 것을 원하지 않습니다.

셋째, 개발자는 조인을 포함한 기본 SQL을 이해해야합니다.

과거에는 개발자가 얼마나 밀접하게 참여하고 있는지에 달려 있습니다. 나는 개발자 였고 사실상 DBA 였고, DBA가 복도 아래에 있었고, DBA가 자신의 영역에서 벗어난 곳에서 일했습니다. 개발자가 데이터베이스 디자인에 관여한다고 가정합니다.

최소한 처음 세 가지 정규 형식 인 기본 정규화를 이해해야합니다. 그 이상으로 DBA를 얻으십시오. 미국 법정에 대한 경험이있는 사람들 (그리고 여기에 무작위 텔레비전 쇼가 포함됨)에는 "키, 전체 키 및 키에만 의존하는 것이기 때문에 Codd를 도와주십시오"라는 니모닉이 있습니다.

인덱스에 대한 단서가 필요합니다. 즉, 필요한 인덱스와 성능에 어떤 영향을 줄지에 대한 아이디어가 있어야합니다. 이것은 쓸모없는 인덱스가 없지만 쿼리를 돕기 위해 인덱스를 추가하는 것을 두려워하지 않음을 의미합니다. DBA에는 잔액과 같은 추가 정보를 남겨 두어야합니다.

데이터 무결성의 필요성을 이해하고 데이터를 확인하는 위치와 문제를 발견 한 경우 수행중인 작업을 가리킬 수 있어야합니다. 데이터베이스에있을 필요는 없지만 (사용자에게 의미있는 오류 메시지를 발행하는 것이 어려울 수 있음) 어딘가에 있어야합니다.

계획을 얻는 방법과 일반적인 계획을 읽는 방법에 대한 기본 지식이 있어야합니다 (적어도 알고리즘의 효율성 여부를 알기에 충분합니다).

트리거가 무엇인지, 뷰가 무엇인지, 데이터베이스를 분할 할 수 있다는 것을 모호하게 알아야합니다. 그들은 어떤 종류의 세부 사항도 필요하지 않지만 DBA에게 이러한 것들에 대해 물어볼 필요가 있습니다.

물론 프로덕션 데이터, 프로덕션 코드 또는 이와 유사한 것을 다루지 않아야하며 모든 소스 코드가 VCS에 들어가는 것을 알아야합니다.

의심의 여지없이 무언가를 잊어 버렸지 만 실제 DBA가있는 경우 일반 개발자는 DBA 일 필요는 없습니다.

기본 인덱싱

나는 인덱스가 없거나 임의의 / 쓸모없는 인덱스가없는 테이블이나 전체 데이터베이스를 보는 것에 항상 충격을 받았습니다. 데이터베이스를 설계 하지 않고 쿼리를 작성해야하는 경우에도 최소한 이해하는 것이 중요합니다.

• 데이터베이스에서 인덱싱 된 것과 그렇지 않은 것 :
• 스캔 유형, 선택 방법 및 쿼리 작성 방법의 차이가 해당 선택에 영향을 줄 수 있습니다.
• 커버리지의 개념 (왜 쓰지 말아야 하는가 SELECT *);
• 클러스터형 인덱스와 비 클러스터형 인덱스의 차이점
• 왜 더 많거나 더 큰 인덱스가 반드시 더 좋은 것은 아닙니다.
• 함수에서 필터 열을 줄이려고하지 않는 이유는 무엇입니까?

또한 디자이너는 다음과 같은 일반적인 색인 반 패턴을 알고 있어야합니다.

• Access 안티 패턴 (모든 열을 하나씩 색인화)
• Catch-All anti-pattern (모든 열 또는 대부분의 열에 대한 하나의 방대한 색인으로, 해당 열과 관련된 모든 가능한 쿼리의 속도가 빨라질 것이라는 잘못된 인상으로 분명히 나타남).

데이터베이스의 인덱싱의 품질 - 당신은 당신이 쓰는 쿼리로 활용 여부 -를 차지 훨씬 성능의 가장 중요한 덩어리. SO 및 다른 포럼에 게시 된 10 개의 질문 중 9 개는 성능 저하에 대해 불평하는 것은 색인 생성이 좋지 않거나 표현할 수없는 표현으로 인한 것으로 판명되었습니다.

표준화

정규화 된 디자인 ( "지역별 총 판매량 표시")으로 완전히 간단했던 지나치게 복잡한 쿼리를 작성하는 데 어려움을 겪고있는 누군가를 보게되면 항상 우울합니다.

처음부터 이것을 이해하고 그에 따라 디자인하면 나중에 많은 고통을 덜 수 있습니다. 정규화 한 후에는 성능을 쉽게 비정규화할 수 있습니다. 처음부터 그렇게 설계되지 않은 데이터베이스를 정규화하는 것은 쉽지 않습니다.

최소한 3NF가 무엇이며 어떻게 가는지 알아야합니다. 대부분의 트랜잭션 데이터베이스에서 이는 쿼리를 쉽게 작성하고 좋은 성능을 유지하는 것 사이의 균형이 아주 좋습니다.

인덱스 작동 방식

아마도 가장 중요하지는 않지만 가장 과소 평가 된 주제 일 것입니다.

인덱싱의 문제점은 일반적으로 SQL 자습서에서 전혀 언급하지 않으며 모든 장난감 예제가 인덱스없이 작동한다는 것입니다.

보다 숙련 된 개발자도 " 인덱스가 쿼리를 빠르게 만듭니다 "보다 인덱스에 대해 더 많이 알지 않고도 상당히 우수하고 복잡한 SQL을 작성할 수 있습니다 .

이는 SQL 데이터베이스가 블랙 박스로 작동 하는 데 매우 효과적 이기 때문 입니다.

필요한 것을 알려주십시오 (gimme SQL), 내가 처리 할 것입니다.

그리고 그것은 올바른 결과를 얻기 위해 완벽하게 작동합니다. SQL의 저자는 시스템이 뒤에서 무엇을하고 있는지 알 필요가 없습니다. 모든 것이 sooo slooooow가 될 때까지 ....

이때 색인 생성이 주제가됩니다. 그러나 그것은 일반적으로 매우 늦었고 누군가 (일부 회사?)는 이미 실제 문제로 고통 받고 있습니다.

그렇기 때문에 색인 작업이 데이터베이스 작업시 잊지 말아야 할 최고의 주제 라고 생각합니다 . 불행히도 잊어 버리기가 매우 쉽습니다.

부인 성명

논쟁은 무료 eBook " Use The Index, Luke " 의 서문 에서 빌려온 것 입니다. 인덱스가 작동하는 방법과 인덱스를 올바르게 사용하는 방법을 설명하는 데 많은 시간을 소비하고 있습니다.

나는 관찰을 지적하고 싶습니다. 대부분의 응답은 데이터베이스가 관계형 데이터베이스와 상호 교환 가능하다고 가정합니다. 객체 데이터베이스, 플랫 파일 데이터베이스도 있습니다. 현재 소프트웨어 프로젝트의 요구를 평가하는 것이 중요합니다. 프로그래머의 관점에서 데이터베이스 결정은 나중에까지 지연 될 수 있습니다. 반면에 데이터 모델링은 초기에 달성 할 수 있으며 많은 성공을 가져올 수 있습니다.

데이터 모델링은 핵심 구성 요소이며 비교적 오래된 개념이지만 소프트웨어 산업에서 많은 사람들이 잊어 버린 개념이라고 생각합니다. 데이터 모델링, 특히 개념 모델링은 시스템의 기능적 동작을 나타낼 수 있으며 개발을위한 로드맵으로 사용될 수 있습니다.

반면, 필요한 데이터베이스 유형은 환경, 사용자 볼륨 및 하드 드라이브 공간과 같은 사용 가능한 로컬 하드웨어를 포함하는 여러 가지 요소를 기반으로 결정될 수 있습니다.

SQL 삽입 방지 및 데이터베이스 보안 방법

모든 개발자는 이것이 거짓임을 알아야합니다. "데이터베이스 작업 프로파일 링은 프로파일 링 코드와 완전히 다릅니다."

전통적인 의미에서 분명한 Big-O가 있습니다. 당신이 EXPLAIN PLAN(또는 동등한 것을)하면 알고리즘이 표시됩니다. 일부 알고리즘에는 중첩 루프가 포함되며 O ( n ^ 2)입니다. 다른 알고리즘에는 B- 트리 조회가 포함되며 O ( n log n )입니다.

이것은 매우, 매우 심각합니다. 인덱스가 중요한 이유를 이해하는 것이 핵심입니다. 속도 정규화-비정규 화 트레이드 오프를 이해하는 것이 핵심입니다. 데이터웨어 하우스가 트랜잭션 업데이트에 대해 정규화되지 않은 스타 스키마를 사용하는 이유를 이해하는 것이 중요합니다.

사용중인 알고리즘이 확실하지 않으면 다음을 수행하십시오. 중지. Query Execution 계획을 설명하십시오. 그에 따라 색인을 조정하십시오.

또한, 추론 : 인덱스가 많을수록 좋지 않습니다.

때로는 한 작업에 초점을 맞춘 인덱스가 다른 작업의 속도를 늦출 수 있습니다. 두 작업의 비율에 따라 인덱스를 추가하면 효과가 좋거나 전체적인 영향을 미치지 않거나 전체 성능에 해를 끼칠 수 있습니다.

모든 개발자는 데이터베이스에 다른 패러다임이 필요 하다는 것을 이해해야한다고 생각합니다 .

데이터를 얻기 위해 쿼리를 작성할 때는 세트 기반 접근 방식이 필요합니다. 상호적인 배경을 가진 많은 사람들이 이것으로 어려움을 겪습니다. 그러나 솔루션을 수용 할 때 솔루션이 반복적으로 초점을 맞춘 마음에 처음 제시된 솔루션이 아닐지라도 훨씬 더 나은 결과를 얻을 수 있습니다.

훌륭한 질문입니다. 먼저 조인을 완전히 이해하지 못하는 datbase를 쿼리하는 것을 고려해서는 안됩니다. 그것은 스티어링 휠과 브레이크의 위치를 ​​모르고 차를 운전하는 것과 같습니다. 또한 데이터 유형과 가장 적합한 데이터 유형을 선택하는 방법을 알아야합니다.

개발자가 이해해야 할 또 다른 사항은 데이터베이스를 설계 할 때 고려해야 할 세 가지가 있다는 것입니다.

1. 데이터 무결성-데이터에 의존 할 수없는 경우 본질적으로 데이터가 없습니다. 이는 다른 많은 소스가 데이터베이스에 닿을 수 있으므로 필요한 논리를 응용 프로그램에 넣지 않음을 의미합니다. 데이터 무결성을 위해서는 제약 조건, 외래 키 및 트리거가 필요합니다. 당신이 그들을 좋아하지 않거나 그들을 이해하기 위해 귀찮게하고 싶지 않기 때문에 그들을 사용하지 마십시오.

2. 성능-성능이 좋지 않은 데이터베이스를 리팩토링하는 것은 매우 어렵고 처음부터 성능을 고려해야합니다. 동일한 쿼리를 수행하는 방법에는 여러 가지가 있으며 일부는 거의 항상 더 빠른 것으로 알려져 있지만 이러한 방법을 배우고 사용하지 않는 것이 근시안적입니다. 쿼리 또는 데이터베이스 구조를 디자인하기 전에 성능 조정에 대한 일부 책을 읽으십시오.

3. 보안-이 데이터는 회사의 생명력이며 도난 당할 수있는 개인 정보도 포함합니다. SQL 인젝션 공격 및 사기 및 신원 도용으로부터 데이터를 보호하는 방법을 배웁니다.

데이터베이스를 쿼리 할 때 오답을 쉽게 얻을 수 있습니다. 데이터 모델을 철저히 이해해야합니다. 실제 결정은 종종 쿼리가 반환하는 데이터를 기반으로 결정됩니다. 잘못되면 잘못된 비즈니스 결정이 내려집니다. 잘못된 쿼리에서 회사를 죽이거나 큰 고객을 잃을 수 있습니다. 데이터에는 의미가 있으며 개발자는 종종 그것을 잊어 버리는 것 같습니다.

데이터는 거의 사라지지 않습니다. 오늘날 데이터를 가져 오는 방법 대신 시간이 지남에 따라 데이터를 저장하는 관점에서 생각하십시오. 수십만 건의 레코드가 있었을 때 제대로 작동했던 데이터베이스는 10 년 동안 그리 좋지 않을 수 있습니다. 애플리케이션이 데이터만큼 오래 지속되는 경우는 거의 없습니다. 이것이 성능 설계가 중요한 이유 중 하나입니다.

데이터베이스에는 아마도 응용 프로그램이 볼 필요가없는 필드가 필요할 것입니다. 복제 용 GUID, 날짜 삽입 필드 또한 변경 내역을 저장하고이 창고에서 잘못된 변경을 복원 할 수있는 사람과 변경 내역을 저장해야 할 수도 있습니다. 업데이트시 where 절을 작성하지 않고 전체 테이블을 업데이트하는 것을 잊어 버린 문제를 해결하는 방법을 웹 사이트에 요청하기 전에이 작업을 수행 할 방법을 생각하십시오.

프로덕션 버전보다 최신 버전의 데이터베이스에서 개발하지 마십시오. 프로덕션 데이터베이스에 대해 직접 개발하지 마십시오.

데이터베이스 관리자가없는 경우 다른 사람이 백업을 작성하고 복원 방법을 알고 복원을 테스트했는지 확인하십시오.

데이터베이스 코드는 코드이므로 다른 코드와 마찬가지로 소스 제어로 유지하지 않는 것에 대한 변명은 없습니다.

진화 데이터베이스 디자인. http://martinfowler.com/articles/evodb.html

이러한 민첩한 방법론을 통해 데이터베이스 변경 프로세스를 관리 가능하고 예측 가능하며 테스트 할 수 있습니다.

개발자는 버전 관리, 지속적인 통합 및 자동화 된 테스트 측면에서 프로덕션 데이터베이스를 리팩토링하는 데 필요한 사항을 알아야합니다.

진화 데이터베이스 설계 프로세스에는 관리 측면이 있습니다. 예를 들어이 코드베이스의 모든 데이터베이스에서 수명 기간이 지나면 열이 삭제됩니다.

최소한 데이터베이스 리팩토링 개념과 방법론이 존재한다는 것을 알고 있어야합니다. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

분류 및 프로세스 설명을 통해 이러한 리팩토링을위한 툴링을 구현할 수 있습니다.

관계형 데이터베이스에 대한 나의 경험에서 모든 개발자는 다음을 알아야합니다.

-다른 데이터 유형 :

올바른 작업에 올바른 유형을 사용하면 DB 디자인이 더욱 강력 해지고 쿼리가 빨라지고 삶이 더 쉬워집니다.

-1xM 및 MxM에 대해 알아보십시오 .

이것은 관계형 데이터베이스의 빵과 버터입니다. 일대 다 및 다 대다 관계를 이해하고 필요할 때 적용하십시오.

- " KISS "원칙은 DB에도 적용됩니다 .

단순성이 항상 가장 효과적입니다. DB 작동 방식을 연구했다면 불필요한 복잡성을 피하여 유지 관리 및 속도 문제를 일으킬 수 있습니다.

-지표 :

그들이 무엇인지 안다면 충분하지 않습니다. 사용시기와 사용하지 않을시기를 이해해야합니다.

또한:

• 부울 대수는 당신의 친구입니다
• 이미지 : DB에 저장하지 마십시오. 이유를 묻지 마십시오.
• SELECT로 테스트 삭제

DBA 및 개발자 / 디자이너 / 아키텍트 모두가 비즈니스 도메인을 올바르게 모델링하는 방법과 해당 비즈니스 도메인 모델을 표준화 된 데이터베이스 논리 모델, 최적화 된 실제 모델 및 적절한 객체 지향 클래스 모델. 각각 다른 이유로, 다를 수 있으며, 언제, 왜, 어떻게 다른지 이해해야합니다.

강력한 기본 SQL 기술을 말할 것입니다. 지금까지 데이터베이스에 대해 약간 알고 있지만 항상 간단한 쿼리를 작성하는 방법에 대한 팁을 요구하는 많은 개발자를 보았습니다. 쿼리가 항상 그렇게 쉽고 간단하지는 않습니다. 정규화 된 데이터베이스를 쿼리 할 때는 여러 조인 (내부, 왼쪽 등)을 사용해야합니다.

Walter M.의 답변에 대한 다음 의견에 대해 :

"아주 잘 작성되었습니다! 그리고 역사적 관점은 당시 데이터베이스 작업을하지 않은 사람들 (예 : 저)에게 좋습니다."

역사적 관점은 어떤 의미에서 절대적으로 중요합니다. "역사를 잊어 버린 사람들은 그것을 반복 할 운명이다." 과거의 계층 적 실수를 반복하는 Cfr XML, 과거의 네트워크 실수를 반복하는 그래프 데이터베이스, 사용자에게 계층 적 모델을 강요하는 OO 시스템, 뇌의 10 분의 1 만있는 모든 사람은 계층 적 모델이 일반에 적합하지 않다는 것을 알아야합니다. 현실 세계 등의 목적 표현.

질문 자체에 관해서 :

모든 데이터베이스 개발자는 "관계형"이 "SQL"과 같지 않다는 것을 알아야합니다. 그런 다음 그들은 왜 DBMS 벤더들이 그렇게 심하게 실망하는지, 그리고 같은 벤더들에게 재미있는 양의 물건을 계속 마시고 싶다면 더 나은 물건 (예 : 진정한 관계가있는 DBMS)을 내놓으라고 말해야하는 이유를 이해할 것입니다. 그런 엉터리 소프트웨어에 대한 고객의 돈).

그리고 모든 데이터베이스 개발자는 관계 대수에 관한 모든 것을 알아야합니다. 그런 다음 더 이상 스택 오버플로에 대한 이러한 바보 같은 "내 일을하는 방법을 모르고 다른 사람이 나를 위해 해줄 것을 원합니다"라는 질문을 게시 한 개발자 한 명이 더 이상 남지 않았습니다.

나는 많은 기술적 세부 사항이 여기에서 다루어지고 있다고 덧붙이고 싶지 않습니다. 제가 말하고 싶은 한 가지는 기술적 인 것보다 사회적인 것입니다. 응용 프로그램 개발자로서 "최고를 알고있는"DBA 함정에 빠지지 마십시오.

쿼리 성능 문제가있는 경우 문제의 소유권도 가져 오십시오. 자신의 연구를 수행하고 DBA에게 무슨 일이 일어나고 있고 그들의 솔루션이 어떻게 문제를 해결하는지 설명 할 수 있도록하십시오.

연구를 마친 후에도 자신의 제안을 따르십시오. 즉, 데이터베이스 문제를 DBA에 남기지 않고 문제에 대한 협력 솔루션을 찾으려고합니다.

간단한 존중.

• 그것은 단지 저장소가 아닙니다
• 당신은 아마 벤더 나 DBA보다 잘 모른다
• 오전 3시에 선임 관리자가 소리 지르며 지원하지 않습니다.

고려 비정규을 가능한 천사가 아니라 악마, 또한 고려 되는 NoSQL 데이터베이스를 관계형 데이터베이스에 대한 대안으로.

또한 엔터티 관계 모델은 데이터베이스를 디자인하지 않더라도 모든 개발자에게 반드시 알아야 할 사항이라고 생각합니다. 데이터베이스의 모든 내용을 철저하게 이해할 수 있습니다.

잘못된 텍스트 인코딩으로 데이터를 삽입하지 마십시오.

데이터베이스가 여러 인코딩으로 오염되면 휴리스틱과 수동 노동의 조합을 적용하는 것이 가장 좋습니다.

이들이 사용하는 구문 및 개념적 옵션 (예 : 조인, 트리거 및 저장 프로 시저) 외에도 데이터베이스를 사용하는 모든 개발자에게 중요한 것은 다음과 같습니다.

엔진이 작성중인 쿼리를 구체적으로 수행하는 방법을 알고 있어야합니다.

이것이 중요하다고 생각하는 이유는 단순히 생산 안정성입니다. 코드가 어떻게 수행되는지 알고 있어야 긴 함수가 완료되기를 기다리는 동안 스레드에서 모든 실행을 중지하지 않아야합니다. 따라서 쿼리가 데이터베이스, 프로그램 및 어떻게 영향을 미치는지 알고 싶지 않은 이유는 무엇입니까? 서버?

이것은 실제로 세미콜론 등이없는 것보다 R & D 팀에 더 많은 타격을 입힌 것입니다. 테이블에 수천 행만있는 개발 시스템에서 쿼리가 실행되므로 쿼리가 빠르게 실행된다고 가정합니다. 프로덕션 데이터베이스의 크기가 동일하더라도 훨씬 더 많이 사용되므로 여러 사용자가 동시에 액세스하거나 다른 쿼리에서 다른 문제가 발생하여 지연되는 등 다른 제약 조건으로 인해 어려움을 겪을 수 있습니다. 이 쿼리의 결과

조인이 쿼리 성능에 미치는 영향과 같은 간단한 것조차 프로덕션에서 매우 중요합니다. 많은 데이터베이스 엔진에는 개념적으로 작업을 쉽게하는 많은 기능이 있지만 명확하게 생각하지 않으면 성능에 문제가 생길 수 있습니다.

데이터베이스 엔진 실행 프로세스를 알고 계획하십시오.

데이터베이스를 많이 사용하는 (매일 또는 거의 매일 쿼리 작성 / 유지 보수) 중간 정도의 전문 개발자에게는 다른 분야와 기대가 같아야한다고 생각합니다 . 대학에서 하나를 작성했습니다 .

모든 C ++ 괴짜는 대학에서 문자열 클래스를 썼습니다. 모든 그래픽 괴짜들은 대학에서 raytracer를 썼습니다. 모든 웹 괴짜는 대학에서 대화 형 웹 사이트 (보통 "웹 프레임 워크"를 갖기 전에)를 썼습니다. 모든 하드웨어 대단하다 (그리고 심지어 소프트웨어 대단하다)는 대학에서 CPU를 만들었습니다. 모든 의사는 혈압을 내고 오늘 콜레스테롤이 너무 높다고 말하더라도 대학에서 사체 전체를 해부했습니다. 데이터베이스가 다른 이유는 무엇입니까?

불행히도 오늘날 어떤 이유로 든 다르게 보입니다. 사람들은 .NET 프로그래머가 문자열이 C에서 어떻게 작동하는지 알고 싶어 하지만 RDBMS의 내부 는 그다지 걱정하지 않아도 됩니다.

그것들에 대해 읽거나 위에서 아래로 내려가는 것만으로도 동일한 수준의 이해를 얻는 것은 사실상 불가능합니다. 그러나 맨 아래에서 시작하여 각 부분을 이해하면 데이터베이스의 세부 사항을 파악하는 것이 상대적으로 쉽습니다. 관계형이 아닌 데이터베이스를 사용하는 경우와 같이 많은 데이터베이스 전문가가 생각하기 어려운 것조차도.

아마도 대학에서 컴퓨터 과학을 공부하지 않은 경우에는 다소 엄격 할 수 있습니다. 나는 그것을 톤 다운합니다 : 당신은 오늘 하나 쓸 수 있습니다 처음부터 완전히 . PostgreSQL 쿼리 옵티마이 저의 작동 방식에 대한 세부 사항을 알고 있는지는 신경 쓰지 않지만 직접 작성하기에 충분히 알고 있다면 실제로 수행 한 것과 다르지 않을 것입니다. 알다시피, 기본적인 것을 작성하는 것은 그리 어렵지 않습니다.

고유하지 않은 인덱스의 열 순서가 중요합니다.

첫 번째 열은 내용에 가장 많은 변동성이있는 열이어야합니다 (예 : 카디널리티).

이는 SQL Server가 런타임에 인덱스를 사용하는 방법에 대한 유용한 통계를 작성하는 데 도움이됩니다.

데이터베이스를 프로그래밍하는 데 사용하는 도구를 이해하십시오 !!!

왜 내 코드가 신비롭게 실패했는지 이해하려고 많은 시간을 낭비했습니다.

예를 들어 .NET을 사용하는 경우 System.Data.SqlClient네임 스페이스 에서 개체를 올바르게 사용하는 방법을 알아야합니다 . 관리 방법을 알아야합니다SqlConnection개체를 열고 닫고 필요할 때 올바르게 폐기 개체 .

을 사용할 때는을 (를) SqlDataReader별도로 닫을 필요가 있음을 알아야 합니다 SqlConnection. 데이터베이스에 대한 적중 횟수를 최소화하는 방법에 대해 적절한 경우 연결을 개방 상태로 유지하는 방법을 이해해야합니다 (컴퓨팅 시간 측면에서 상대적으로 비싸기 때문).

• 기본 SQL 기술.
• 인덱싱.
• DATE / TIME / TIMESTAMP의 다른 화신을 다루십시오.
• JDBC 드라이버사용중인 플랫폼에 대한 문서
• 이진 데이터 형식 ( CLOB , BLOB 등) 처리

일부 프로젝트의 경우 객체 지향 모델이 더 좋습니다.

다른 프로젝트의 경우 관계형 모델이 더 좋습니다.

임피던스 불일치 문제이며 공통 결함 또는 ORM을 알고 있습니다.

RDBMS 호환성

둘 이상의 RDBMS에서 애플리케이션을 실행해야하는지 확인하십시오. 그렇다면 다음을 수행해야 할 수도 있습니다.

• RDBMS SQL 확장을 피하십시오
• 트리거 제거 및 저장 프로 시저
• 엄격한 SQL 표준을 따르십시오
• 필드 데이터 형식 변환
• 트랜잭션 격리 수준 변경

그렇지 않은 경우, 이러한 질문은 개별적으로 다루어야하며 다른 버전의 응용 프로그램이 개발 될 것입니다.

SQL 쿼리에서 반환 된 행 순서에 의존하지 마십시오.

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/