모든 개발자가 데이터베이스에 대해 알아야 할 사항은 무엇입니까?
좋든 싫든 많은 개발자들이 데이터베이스를 정기적으로 사용하거나 언젠가는 데이터베이스를 사용해야 할 수도 있습니다.그리고 야생에서의 오용과 남용의 양과 매일 나오는 데이터베이스 관련 질문의 양을 고려할 때, 비록 오늘날 데이터베이스를 설계하거나 작업하지 않더라도 개발자들이 알아야 할 특정 개념들이 있다고 말하는 것이 타당합니다.
개발자와 다른 소프트웨어 전문가들이 데이터베이스에 대해 알아야 할 중요한 개념은 무엇입니까?
개발자들이 데이터베이스에 대해 가장 먼저 알아야 할 것은 다음과 같습니다. 데이터베이스는 무엇을 위한 것일까요?작동 방식도, 구축 방식도, 데이터베이스에서 데이터를 검색하거나 업데이트하기 위해 코드를 작성하는 방식도 없습니다.그러나 그것들은 무엇을 위한 것일까요?
유감스럽게도, 이것에 대한 답은 움직이는 목표입니다.1970년대부터 1990년대 초반까지 데이터베이스는 데이터 공유를 위한 것이었습니다.데이터베이스를 사용할 때 데이터를 공유하지 않는 경우 학술 프로젝트에 참여했거나 자신을 포함한 리소스를 낭비하고 있었습니다.데이터베이스를 설정하고 DBMS를 길들이는 것은 너무나 엄청난 작업이었기 때문에 여러 번 활용한 데이터 측면에서 투자에 걸맞게 막대한 투자 회수가 필요했습니다.
지난 15년 동안 데이터베이스는 하나의 애플리케이션과 관련된 영구 데이터를 저장하는 데 사용되었습니다.MySQL 또는 Access 또는 SQL Server에 대한 데이터베이스 구축은 매우 일상적이어서 데이터베이스는 일반 애플리케이션의 거의 일상적인 부분이 되었습니다.데이터의 실제 가치가 명백해짐에 따라 초기의 제한된 임무가 임무 크리프에 의해 위로 밀려나기도 합니다.불행하게도 단일 목적을 염두에 두고 설계된 데이터베이스는 전사적이고 미션 크리티컬한 역할로 밀려나기 시작할 때 극적으로 실패하는 경우가 많습니다.
개발자들이 데이터베이스에 대해 알아야 할 두 번째 사항은 데이터 중심의 세계관 전체입니다.데이터 중심 세계관은 대부분의 개발자들이 지금까지 배운 것보다 프로세스 중심 세계관과 더 다릅니다.이 갭에 비해 구조화된 프로그래밍과 객체 지향 프로그래밍 사이의 갭은 상대적으로 작습니다.
개발자들이 최소한 개요에서 배워야 할 세 번째 사항은 개념 데이터 모델링, 논리 데이터 모델링 및 물리 데이터 모델링을 포함한 데이터 모델링입니다.
개념적 데이터 모델링은 데이터 중심적인 관점에서 요구사항을 분석하는 것입니다.
논리적 데이터 모델링은 일반적으로 개념적 데이터 모델링에서 발견되는 요구사항에 특정 데이터 모델을 적용하는 것입니다.관계형 모델은 다른 특정 모델보다 훨씬 많이 사용되며 개발자들은 관계형 모델을 확실히 학습해야 합니다.중요하지 않은 요구 사항에 대해 강력하고 관련성 있는 관계형 모델을 설계하는 것은 사소한 작업이 아닙니다.관계형 모델을 잘못 이해하면 좋은 SQL 테이블을 만들 수 없습니다.
물리적 데이터 모델링은 일반적으로 DBMS에 따라 다르며, 개발자가 데이터베이스 구축자 또는 DBA가 아닌 한 자세히 학습할 필요가 없습니다.개발자들이 알아야 할 것은 물리적 데이터베이스 설계와 논리적 데이터베이스 설계를 분리할 수 있는 정도와 물리적 설계를 조정하는 것만으로 고속 데이터베이스를 생성할 수 있는 정도입니다.
개발자들이 다음으로 배워야 할 것은 속도(성능)도 중요하지만, 데이터베이스의 범위를 수정하고 확장할 수 있는 능력이나 프로그래밍의 단순성과 같은 설계의 우수성을 측정하는 다른 방법들도 훨씬 더 중요하다는 것입니다.
마지막으로 데이터베이스를 엉망으로 만드는 사람이라면 누구나 데이터의 가치가 데이터를 캡처한 시스템보다 오래 지속되는 경우가 많다는 사실을 이해해야 합니다.
휴!
좋은 질문입니다.다음은 특정한 순서가 아닌 몇 가지 생각입니다.
적어도 두 번째 정상 형태로 정규화하는 것이 필수적입니다.
적절한 계단식 삭제 및 업데이트 고려사항을 통해 참조 무결성 또한 필수적입니다.
검사 제약 조건을 적절하고 적절하게 사용합니다.데이터베이스가 가능한 한 많은 작업을 수행하도록 합니다.
데이터베이스와 중간 계층 코드 모두에 비즈니스 로직을 흩뿌리지 마십시오.하나 또는 다른 하나를 선택합니다. 가급적이면 중간 계층 코드입니다.
기본 키와 클러스터 키에 대한 일관된 접근 방식을 결정합니다.
색인을 넘기지 마세요.당신의 지수를 현명하게 선택하세요.
일관된 테이블 및 열 이름 지정.기준을 정하고 그것을 고수하세요.
데이터베이스에서 null 값을 허용할 열 수를 제한합니다.
방아쇠에 흥분하지 마세요.그들은 쓰임새가 있지만 일을 급하게 복잡하게 만들 수 있습니다.
UDF를 주의해야 합니다.이러한 기능은 훌륭하지만 쿼리에 얼마나 자주 호출되는지 알 수 없을 때 성능 문제를 일으킬 수 있습니다.
데이터베이스 설계에 관한 셀코의 책을 받아보세요.그 남자는 거만하지만 자기 물건을 알고 있습니다.
첫째, 개발자들은 데이터베이스에 대해 알아야 할 것이 있다는 것을 이해할 필요가 있습니다.SQL을 입력하고 결과 집합을 가져오는 단순한 마법 장치가 아니라 자체 논리와 특이점을 가진 매우 복잡한 소프트웨어입니다.
둘째, 목적에 따라 다른 데이터베이스 설정이 있다는 것입니다.데이터 웨어하우스를 사용할 수 있는 경우 개발자가 온라인 트랜잭션 데이터베이스에서 기록 보고서를 작성하는 것을 원하지 않습니다.
셋째, 개발자들은 조인을 포함한 기본적인 SQL을 이해해야 합니다.
이것은 개발자들이 얼마나 긴밀하게 참여하느냐에 달려 있습니다.저는 개발자이자 실질적인 DBA 업무를 해봤고, DBA들이 바로 아래 단계에 있었고, DBA들은 각자의 영역에서 떨어져 있었습니다. (저는 세 번째 단계가 싫습니다.)데이터베이스 설계에 개발자가 참여한다고 가정하면 다음과 같습니다.
그들은 기본적인 정규화를 이해할 필요가 있습니다. 최소한 처음의 세 가지 정규 형태 말입니다.그 이상의 것은 DBA를 구하세요.미국 법정에 가본 경험이 있는 사람들(그리고 무작위 텔레비전 쇼들은 여기에 포함됩니다)에게는 "열쇠, 전체 키, 그리고 오직 키에만 의존하라, 그러니 코드를 도와라"라는 기억법이 있습니다.
인덱스에 대한 단서가 필요합니다. 즉, 필요한 인덱스가 무엇인지, 성능에 어떤 영향을 미칠 가능성이 있는지 어느 정도 파악해야 합니다.즉, 쓸모없는 색인이 있는 것이 아니라 쿼리를 지원하기 위해 색인을 추가하는 것을 두려워하지 않는 것을 의미합니다.더 이상의 (잔액과 같은) 것은 DBA에게 맡겨야 합니다.
데이터 무결성의 필요성을 이해하고, 문제가 발견되면 데이터를 검증하는 위치와 작업을 지시할 수 있어야 합니다.이것은 데이터베이스에 있을 필요가 없고(사용자에게 의미 있는 오류 메시지를 발행하기 어려울 것입니다), 어딘가에 있어야 합니다.
그들은 계획을 얻는 방법과 계획을 일반적으로 읽는 방법에 대한 기본적인 지식을 가지고 있어야 합니다. (적어도 알고리즘이 효율적인지 아닌지를 알 수 있을 정도로)
트리거가 무엇인지, 보기가 무엇인지, 데이터베이스 조각을 분할하는 것이 가능한지에 대해 모호하게 알아야 합니다.세부 정보는 필요하지 않지만 DBA에게 이러한 사항에 대해 문의해야 합니다.
물론 운영 데이터나 운영 코드 등에 간섭하지 않아야 하며 모든 소스 코드가 VCS에 들어간다는 사실을 알아야 합니다.
분명 잊어버린 것이 있습니다만, 현재 현실적인 DBA가 있다면 일반 개발자는 DBA가 될 필요가 없습니다.
기본 색인화
인덱스가 없거나 임의/무익한 인덱스가 없는 테이블 또는 전체 데이터베이스를 보면 항상 충격을 받습니다.데이터베이스를 설계하지 않고 쿼리를 작성하기만 하면 되더라도 최소한 다음 사항을 이해하는 것이 중요합니다.
- 데이터베이스에 인덱싱된 항목과 인덱싱되지 않은 항목:
- 검색 유형 간의 차이, 선택 방법 및 쿼리 작성 방법이 해당 선택에 영향을 미칠 수 있습니다.
- 보장의 개념(쓰기만 하면 안 되는 이유)
SELECT *); - 클러스터된 인덱스와 비클러스터된 인덱스의 차이.
- 더 많은/더 큰 인덱스가 반드시 더 좋은 것은 아닌 이유;
- 함수에서 필터 열을 래핑하지 않아야 하는 이유.
설계자는 다음과 같은 일반적인 인덱스 안티패턴에 대해서도 알아야 합니다.
- Access 안티패턴(모든 열을 하나씩 인덱싱)
- Catch-All 안티패턴(전체 또는 대부분의 열에 있는 하나의 거대한 인덱스로, 해당 열 중 하나를 포함하는 모든 가능한 쿼리의 속도를 높일 것이라는 잘못된 인상을 받아 생성된 것으로 보입니다.)
데이터베이스 색인의 품질과 작성한 쿼리를 이용하여 데이터베이스 색인을 활용하는지 여부는 단연 가장 중요한 성능 부분을 차지합니다.SO를 비롯한 포럼에 게시된 10개의 질문 중 9개는 항상 색인이 좋지 않거나 표현이 검색되지 않기 때문인 것으로 드러납니다.
정규화
정규화된 설계("지역별 총 매출액을 보여주세요")를 통해 매우 간단한 쿼리를 작성하는 데 어려움을 겪는 사람을 보면 항상 우울합니다.
이것을 처음에 이해하고 그에 맞게 설계하면 나중에 많은 고통을 덜어줄 수 있을 것입니다.성능을 정상화한 후에 성능을 정상화하는 것은 쉽지 않습니다. 처음부터 그렇게 설계되지 않은 데이터베이스를 정상화하는 것은 쉽지 않습니다.
적어도 3NF가 무엇인지, 어떻게 가야 하는지는 알아야 합니다.대부분의 트랜잭션 데이터베이스에서는 쿼리를 쉽게 작성할 수 있는 것과 양호한 성능을 유지하는 것 사이의 균형이 매우 좋습니다.
인덱스 작동 방식
그것은 아마도 가장 중요한 것은 아니지만, 가장 과소평가된 주제일 것입니다.
인덱싱의 문제점은 SQL 튜토리얼에서 보통 전혀 언급하지 않고 모든 토이 예제가 색인 없이 작동한다는 것입니다.
경험이 풍부한 개발자라도 인덱스에 대해 "인덱스를 사용하면 쿼리가 빠름"보다 훨씬 정확하고 복잡한 SQL을 작성할 수 있습니다.
이는 SQL 데이터베이스가 블랙박스로서 매우 효과적이기 때문입니다.
필요하신 사항 말씀해주세요(gimme SQL), 제가 처리해드리겠습니다.
그리고 그것은 정확한 결과를 얻기 위해 완벽하게 작동합니다.SQL 작성자는 모든 것이 너무 느려지기 전까지는 시스템이 막후에서 무엇을 하고 있는지 알 필요가 없습니다.
이때 색인이 화제가 됩니다.하지만 이는 보통 매우 늦은 것이고 누군가(어떤 회사?)는 이미 심각한 문제를 겪고 있습니다.
그렇기 때문에 데이터베이스 작업을 할 때 잊지 말아야 할 1순위 주제가 색인이라고 생각합니다.안타깝게도, 그것을 잊어버리기 쉽습니다.
부인
이 주장은 무료 eBook "Use The Index, Luke"의 서문에서 차용한 것입니다.저는 인덱스가 어떻게 작동하는지 그리고 어떻게 인덱스를 적절하게 사용하는지 설명하는데 많은 시간을 할애하고 있습니다.
저는 단지 관찰을 지적하고 싶습니다. 즉, 대다수의 응답자들은 데이터베이스가 관계형 데이터베이스와 교환 가능하다고 가정하는 것 같습니다.오브젝트 데이터베이스, 플랫 파일 데이터베이스도 있습니다.당면한 소프트웨어 프로젝트의 필요성을 평가하는 것이 중요합니다.프로그래머의 관점에서 데이터베이스 결정은 나중으로 미뤄질 수 있습니다.반면에 데이터 모델링은 초기에 달성할 수 있고 많은 성공을 이끌 수 있습니다.
데이터 모델링은 핵심적인 구성 요소이며 비교적 오래된 개념이지만 소프트웨어 업계에서 많은 사람들에게 잊혀진 개념이라고 생각합니다.데이터 모델링, 특히 개념 모델링은 시스템의 기능적 동작을 드러낼 수 있으며 개발 로드맵으로 의존할 수 있습니다.
한편, 필요한 데이터베이스 유형은 환경, 사용자 볼륨, 하드 드라이브 공간과 같은 가용 로컬 하드웨어 등 여러 가지 요소를 기반으로 결정할 수 있습니다.
SQL 주입 방지 및 데이터베이스 보안 방법
모든 개발자는 이것이 거짓임을 알아야 합니다. "데이터베이스 작업을 프로파일링하는 것은 프로파일링 코드와 완전히 다릅니다.
전통적인 의미의 Big-O가 분명합니다.을 할 때.EXPLAIN PLAN(혹은 그에 상응하는) 알고리즘을 보고 있는 겁니다.일부 알고리즘은 중첩 루프를 포함하며 O( n ^ 2)입니다.다른 알고리즘은 B-트리 룩업을 포함하며 O(n logn)입니다.
이것은 매우 매우 심각한 일입니다.인덱스가 중요한 이유를 이해하는 것이 핵심입니다.속도-정상화-비정상화 트레이드오프를 이해하는 데 핵심적입니다.데이터 웨어하우스에서 트랜잭션 업데이트에 정규화되지 않은 스타 스키마를 사용하는 이유를 이해하는 것이 가장 중요합니다.
사용 중인 알고리즘이 불분명한 경우 다음을 수행합니다.멈춰요. 쿼리 실행 계획을 설명합니다.그에 따라 인덱스를 조정합니다.
또한, 결과: 더 많은 인덱스는 더 나은 것이 아닙니다.
때로는 한 작업에 초점을 맞춘 인덱스가 다른 작업의 속도를 늦출 수 있습니다.두 작업의 비율에 따라 지수를 추가하면 효과가 좋거나, 전체적인 영향이 없거나, 전체적인 성능에 해로울 수 있습니다.
모든 개발자는 데이터베이스에 다른 패러다임이 필요하다는 것을 이해해야 한다고 생각합니다.
데이터를 얻기 위한 쿼리를 작성할 때는 세트 기반 접근 방식이 필요합니다.상호작용적인 배경을 가진 많은 사람들이 이것과 씨름합니다.그럼에도 불구하고, 그들이 그것을 받아들였을 때, 그들은 더 나은 결과를 얻을 수 있습니다. 비록 그 해결책이 그들의 반복에 초점을 맞춘 마음에 처음으로 제시된 해결책은 아닐 지라도 말입니다.
아주 좋은 질문입니다.어디 보자, 먼저 조인을 완전히 이해하지 못하는 사람은 데이터베이스를 쿼리하는 것을 고려해서는 안 됩니다.그것은 핸들과 브레이크가 어디에 있는지도 모르고 차를 운전하는 것과 같습니다.데이터 종류와 가장 좋은 것을 고르는 방법도 알아야 합니다.
개발자들이 이해해야 할 또 다른 점은 데이터베이스를 설계할 때 다음과 같은 세 가지 사항을 염두에 두어야 한다는 것입니다.
데이터 무결성 - 데이터를 본질적으로 사용자에게 의존할 수 없는 경우 데이터가 없는 경우, 이는 다른 많은 소스가 데이터베이스에 영향을 미칠 수 있으므로 필요한 논리를 응용 프로그램에 넣지 않는 것을 의미합니다.제약 조건, 외부 키 및 때때로 트리거는 데이터 무결성에 필요합니다.그것들이 싫거나 이해하기 귀찮아서 사용하는 것을 잊지 마세요.
성능 - 성능이 떨어지는 데이터베이스를 재분석하는 것은 매우 어려우며 성능을 처음부터 고려해야 합니다.동일한 쿼리를 수행하는 데는 여러 가지 방법이 있으며 일부는 거의 항상 더 빠른 것으로 알려져 있지만 이러한 방법을 배우고 사용하지 않는 것은 근시안적입니다.쿼리나 데이터베이스 구조를 설계하기 전에 성능 조정에 관한 책을 읽어 보십시오.
보안 - 이 데이터는 회사의 생명줄이며 도난당할 수 있는 개인 정보도 포함하고 있습니다.SQL 주입 공격과 부정 및 ID 도용으로부터 데이터를 보호하는 방법에 대해 알아보십시오.
데이터베이스를 조회할 때 오답을 쉽게 얻을 수 있습니다.데이터 모델을 완전히 이해했는지 확인합니다.쿼리가 반환하는 데이터에 따라 실제 결정이 이루어지는 경우가 많다는 점을 기억하십시오.그것이 잘못되면, 잘못된 사업 결정이 내려집니다.당신은 나쁜 질의로 회사를 죽이거나 큰 고객을 잃을 수 있습니다.데이터에는 의미가 있으며 개발자들은 종종 이를 잊어버리는 것 같습니다.
데이터는 거의 없어지지 않습니다. 오늘날 데이터를 어떻게 확보하느냐 보다는 시간이 지남에 따라 데이터를 저장한다는 측면에서 생각해 보십시오.10만 개의 기록을 보유했을 때 잘 작동했던 데이터베이스는 10년 후에는 그렇게 좋지 않을 수도 있습니다.애플리케이션이 데이터만큼 오래 지속되는 경우는 거의 없습니다.이것이 성능을 위한 설계가 중요한 이유 중 하나입니다.
데이터베이스에는 응용프로그램이 볼 필요가 없는 필드가 필요합니다.복제를 위한 GUID, 날짜 삽입 필드 등입니다.또한 변경 내역과 변경된 사용자가 언제 변경했는지 저장해야 하며 이 저장소에서 잘못된 변경 사항을 복구할 수 있어야 합니다.웹 사이트에 업데이트에 where 조항을 넣는 것을 잊어버리고 전체 테이블을 업데이트한 문제를 해결하는 방법을 묻기 전에 이 작업을 어떻게 수행할 것인지 생각해 보십시오.
운영 버전보다 최신 버전의 데이터베이스에서는 개발하지 마십시오.프로덕션 데이터베이스에 대해 직접 개발하는 일은 절대로 없습니다.
데이터베이스 관리자가 없는 경우 백업을 수행하고 있고 복원 방법을 알고 있으며 복원 테스트를 완료했는지 확인합니다.
데이터베이스 코드는 코드이며, 코드의 나머지 부분과 마찬가지로 소스 컨트롤에 보관하지 않는 것은 변명의 여지가 없습니다.
진화적 데이터베이스 설계.http://martinfowler.com/articles/evodb.html
이러한 민첩한 방법론은 데이터베이스 변경 프로세스를 관리, 예측 및 테스트할 수 있게 해줍니다.
개발자들은 버전 제어, 지속적인 통합 및 자동화된 테스트 측면에서 프로덕션 데이터베이스를 재분류하기 위해 무엇이 필요한지 알아야 합니다.
진화형 데이터베이스 설계 프로세스에는 관리적인 측면이 있습니다. 예를 들어 열은 이 코드베이스의 모든 데이터베이스에서 수명 기간이 지나면 삭제됩니다.
적어도 데이터베이스 리팩토링(Database Refactoring) 개념과 방법론이 존재한다는 것을 알고 있습니다.http://www.agiledata.org/essays/databaseRefactoringCatalog.html
분류 및 공정 설명을 통해 이러한 재팩터링에 대해서도 툴링을 구현할 수 있습니다.
월터 M.의 답변에 대해 다음과 같이 언급합니다.
"아주 잘 쓰였습니다!그리고 그 당시 데이터베이스 작업을 하지 않았던 사람들(즉, 저)에게 역사적 관점은 훌륭합니다."
역사적 관점은 어떤 의미에서 절대적으로 중요합니다."역사를 잊은 자는 반드시 그것을 반복할 것입니다."Cfr XML은 과거의 계층적 실수를 반복하고, 그래프 데이터베이스는 과거의 네트워크 실수를 반복하고, OO 시스템은 사용자에게 계층 모델을 강요하지만, 단 10분의 1의 두뇌를 가진 모든 사람들은 계층 모델이 현실 세계의 범용적인 표현에 적합하지 않다는 것을 알아야 합니다.
질문 자체에 관해서는:
모든 데이터베이스 개발자는 "Relational"이 "SQL"과 같지 않다는 것을 알아야 합니다.그러면 DBMS 공급업체가 왜 그렇게 실망하는지, 그리고 고객들로부터 이런 형편없는 소프트웨어를 위해 계속해서 돈을 빨아들이고 싶다면 왜 같은 공급업체에게 더 나은 것(예: 정말로 관계가 있는 DBMS)을 제안하라고 말해야 하는지 이해할 수 있을 것입니다.
그리고 모든 데이터베이스 개발자는 관계 대수에 대한 모든 것을 알아야 합니다.그러면 더 이상 스택 오버플로에 이런 바보 같은 "나는 내 일을 어떻게 하는지 모르겠고 다른 사람이 대신 해줬으면 좋겠어"라는 질문을 올려야 하는 개발자가 단 한 명도 남지 않을 것입니다.
관계형 데이터베이스에 대한 제 경험으로 볼 때, 모든 개발자는 다음을 알아야 합니다.
- 다양한 데이터 유형:
올바른 작업에 적합한 유형을 사용하면 DB 설계가 보다 견고해지고 쿼리가 보다 빠르고 보다 쉽게 수행될 수 있습니다.
- 1xM 및 MxM에 대해 알아보기:
이것이 관계형 데이터베이스의 중요한 요소입니다.일대일 및 다대다 관계를 이해하고 적절한 경우 지원해야 합니다.
- "K.I.S." 원칙은 DB에도 적용됩니다.
항상 단순함이 가장 효과적입니다.DB가 어떻게 작동하는지 연구했다면 유지보수 및 속도 문제로 이어지는 불필요한 복잡성을 피할 수 있을 것입니다.
- 지수:
그들이 무엇인지 알면 충분하지 않습니다.사용할 때와 사용하지 않을 때를 이해해야 합니다.
또한:
- 부울 대수는 당신의 친구입니다.
- 이미지: DB에 저장하지 마십시오.이유를 묻지 마세요.
- SELECT를 사용하여 DELETECT
DBA와 개발자/디자이너/아키텍트를 포함한 모든 사람들이 비즈니스 도메인을 적절하게 모델링하는 방법과 비즈니스 도메인 모델을 정규화된 데이터베이스 논리 모델, 최적화된 물리적 모델, 그리고 각각 다를 수 있는 적절한 객체 지향 클래스 모델로 매핑/변환하는 방법을 이해해 주시기 바랍니다.다양한 이유, 그리고 언제, 왜, 그리고 어떻게 그것들이 서로 달라야 하는지를 이해합니다.
저는 강력한 기본적인 SQL 스킬을 말하고 싶습니다.저는 지금까지 데이터베이스에 대해 조금 알고 있으면서도 항상 꽤 간단한 쿼리를 작성하는 방법에 대한 팁을 요구하는 많은 개발자들을 봐왔습니다.쿼리가 항상 쉽고 간단한 것은 아닙니다.정규화된 데이터베이스를 쿼리할 때 여러 개의 조인(내부, 왼쪽 등)을 사용해야 합니다.
여기서 기술적인 세부 사항을 많이 다루었다고 생각하고 추가하고 싶지는 않습니다.제가 말하고 싶은 한 가지는 기술적인 것보다 사회적인 것입니다. 애플리케이션 개발자로서 "DBA가 가장 잘 알고 있다"는 함정에 빠지지 말라는 것입니다.
쿼리에 성능 문제가 있는 경우 해당 문제의 소유권도 가져갑니다.자체 조사를 통해 DBA가 현재의 상황과 해당 솔루션이 문제를 어떻게 해결하고 있는지 설명하도록 지원합니다.
조사를 마친 후에 당신도 당신만의 제안을 생각해 보세요.즉, 데이터베이스 문제를 DBA에게 맡기는 대신 문제에 대한 협력적인 해결책을 찾고자 합니다.
단순한 존경심.
- 단순한 저장소가 아닙니다.
- 공급업체나 DBA보다 더 잘 알고 있을 것입니다.
- 새벽 3시에 선배님들이 소리를 지르면서 지원을 안 하실 겁니다.
비규격화를 악마가 아닌 가능한 천사로 간주하고 NoSQL 데이터베이스를 관계형 데이터베이스의 대안으로 간주합니다.
또한, 저는 Entity-Relation 모델이 데이터베이스를 설계하지 않더라도 모든 개발자가 반드시 알아야 할 사항이라고 생각합니다.데이터베이스의 내용을 완전히 파악할 수 있게 해줍니다.
텍스트 인코딩이 잘못된 데이터를 삽입하지 마십시오.
데이터베이스가 여러 인코딩으로 오염되면 휴리스틱과 수작업의 조합을 적용하는 것이 최선입니다.
이들이 사용하는 구문 및 개념 옵션(예: 조인, 트리거 및 저장 프로시저) 외에 데이터베이스를 사용하는 모든 개발자에게 중요한 한 가지는 다음과 같습니다.
엔진이 특정하게 작성 중인 쿼리를 어떻게 수행할지 알 수 있습니다.
제가 이것이 매우 중요하다고 생각하는 이유는 단순히 생산의 안정성입니다.긴 함수가 완료될 때까지 기다리는 동안 스레드의 모든 실행을 중지하지 않도록 코드가 어떻게 작동하는지 알아야 하는데 쿼리가 데이터베이스, 프로그램 및 서버에 어떤 영향을 미치는지 알고 싶지 않은 이유는 무엇입니까?
이것은 사실 세미콜론 같은 것을 놓치는 것보다 저희 연구개발팀에 더 큰 타격을 준 것입니다.쿼리는 테이블에 몇 천 행만 있는 개발 시스템에서 실행되기 때문에 빠르게 실행될 것으로 예상됩니다.프로덕션 데이터베이스의 크기가 동일하더라도 훨씬 더 많이 사용될 가능성이 높기 때문에 여러 사용자가 동시에 액세스하거나 다른 곳에서 다른 쿼리에 문제가 발생하여 이 쿼리의 결과가 지연됩니다.
조인이 쿼리의 성능에 미치는 영향과 같은 간단한 것조차도 생산에 매우 중요합니다.많은 데이터베이스 엔진에는 개념적으로 일을 더 쉽게 만들지만 명확하게 생각하지 않으면 성능에 문제가 생길 수 있는 많은 기능이 있습니다.
데이터베이스 엔진 실행 프로세스를 알고 계획합니다.
데이터베이스를 많이 사용하는 중간급 전문 개발자(매일 또는 거의 매일 쿼리 작성/유지 관리)의 경우, 다른 분야와 동일한 기대를 가져야 한다고 생각합니다.대학 때도 썼잖아요.
모든 C++ 괴짜들은 대학에서 현악기 수업을 썼습니다.모든 그래픽 괴짜들은 대학에서 광선 추적기를 썼습니다.모든 웹 애호가들은 대학 시절 대화형 웹사이트(보통 "웹 프레임워크"가 있기 전)를 작성했습니다.모든 하드웨어 괴짜들(그리고 심지어 소프트웨어 괴짜들)은 대학 시절에 CPU를 만들었습니다.모든 의사들이 대학에서 시체 전체를 해부했어요 만약 그녀가 내 혈압을 측정하고 오늘 내 콜레스테롤이 너무 높다고 말할 지라도 말이죠데이터베이스가 다른 이유는 무엇입니까?
불행히도, 오늘날 그들은 어떤 이유에서인지 달라 보입니다.사람들이 원해요.NET 프로그래머는 문자열이 C에서 어떻게 작동하는지 알 수 있지만, RDBMS의 내부는 당신을 크게 걱정하지 않을 것입니다.
그것들에 대해 읽는 것만으로, 또는 심지어 정상에서 내려오는 방식으로 작업하는 것으로 동일한 수준의 이해를 얻는 것은 사실상 불가능합니다.그러나 맨 아래에서 시작해서 각 부분을 이해한다면 데이터베이스의 세부 사항을 파악하는 것이 비교적 쉽습니다.심지어 많은 데이터베이스 괴짜들이 관계없는 데이터베이스를 언제 사용해야 하는지와 같은 것들도 흐느끼지 못하는 것처럼 보입니다.
특히 대학에서 컴퓨터 과학을 공부하지 않았다면 아마 그것은 좀 엄격할 것입니다.좀 조용히 해보겠습니다.오늘은 아예 처음부터 끝까지 쓸 수 있을 겁니다.포스트그레 사건이 어떻게 진행되는지 자세히 알아도 상관없어요SQL 쿼리 옵티마이저는 작동하지만 직접 작성할 수 있을 만큼 충분히 알고 있다면 그들이 수행한 작업과 크게 다르지 않을 것입니다.그리고 기본적인 것을 쓰는 것은 정말 어렵지 않습니다.
고유하지 않은 인덱스의 열 순서가 중요합니다.
첫 번째 열은 내용물의 변동성(즉, 카디널리티)이 가장 큰 열이어야 합니다.
이것은 SQL Server가 런타임 시 인덱스를 사용하는 방법에 유용한 통계를 만들 수 있도록 도와줍니다.
데이터베이스를 프로그래밍하는 데 사용하는 도구를 이해하세요!!!
왜 내 코드가 불가사의하게 실패했는지 이해하려고 너무 많은 시간을 낭비했습니다.
사용하시는 분들은.예를 들어, NET의 객체를 적절하게 사용하는 방법을 알아야 합니다.System.Data.SqlClient네임스페이스.관리 방법을 알아야 합니다.SqlConnection물건이 열리고 닫히는지 확인하고 필요할 때 적절하게 배치되도록 합니다.
당신이 a를 사용할 때 당신은 그것을 알아야 합니다.SqlDataReader, 그것을 당신의 것과 별도로 닫는 것이 필요합니다.SqlConnection. 데이터베이스에 대한 히트 수를 최소화하는 방법에 적합할 때 연결을 계속 열어두는 방법을 이해해야 합니다(컴퓨팅 시간 측면에서 상대적으로 비용이 많이 들기 때문입니다).
- 기본적인 SQL 스킬.
- 인덱싱.
- DATE/TIME/TIMESTAMP의 다양한 화신을 처리합니다.
- 사용 중인 플랫폼에 대한 JDBC 드라이버 설명서.
- 이진 데이터 유형(CLOB, BLOB 등) 처리
일부 프로젝트의 경우 개체 지향 모델이 더 좋습니다.
다른 프로젝트의 경우 관계형 모형이 더 좋습니다.
임피던스 불일치 문제이며, 일반적인 결함 또는 ORM을 알고 있습니다.
RDBMS 호환성
둘 이상의 RDBMS에서 응용프로그램을 실행할 필요가 있는지 확인합니다. 만약 그렇다면 다음 작업을 수행해야 할 수도 있습니다.
- RDBMS SQL 확장 안 함
- 트리거 제거 및 프로시저 저장
- 엄격한 SQL 표준을 따릅니다.
- 필드 데이터 유형 변환
- 트랜잭션 분리 수준 변경
그렇지 않으면 이러한 질문은 별도로 처리해야 하며 애플리케이션의 다른 버전(또는 구성)이 개발됩니다.
SQL 쿼리에서 반환되는 행의 순서에 의존하지 마십시오.
세 가지가 마법의 숫자입니다.
데이터베이스도 버전 제어가 필요합니다.
커서는 느리기 때문에 필요하지 않을 수도 있습니다.
트리거가 사악함*
*거의 언제나
언급URL : https://stackoverflow.com/questions/1981526/what-should-every-developer-know-about-databases
'programing' 카테고리의 다른 글
| 부트스트랩 3 Navbar(로고 포함) (0) | 2023.09.10 |
|---|---|
| 필드를 증가시킬 때 MySQL 데이터베이스에 레이스 조건이 없는지 확인하는 방법은 무엇입니까? (0) | 2023.09.10 |
| 셀러리로 이미 실행 중인 작업을 취소하시겠습니까? (0) | 2023.09.10 |
| jQuery 컨테이너 자체를 포함한 컨테이너의 HTML 가져오기 (0) | 2023.09.05 |
| Git Pull 후 코드 변경을 확인하는 방법은 무엇입니까? (0) | 2023.09.05 |