데이터 관리에 대한 관계 모델의 아버지 중 한 명인 크리스 데이트 (Chris Date)는 한때 "모든 관계 이론은 예측 계산에 기초한다"고 말했습니다. 인간은 모두 한 가지 방식으로 스토리 캐릭터이며, 우리는 스토리 캐릭터를 우리의 일상 생활과 일상 업무에 적응시킵니다. 데이터베이스 테이블을 정의하고 데이터의 스토리를 말할 수 없다면 잘못된 작업을 수행하고 있습니다.If you are defining a database table and cannot tell the story of the data, you are doing it wrong. A Look at the Nuts and Bolts of Storytelling에 대한 리뷰 보기 좋은 이야기는 규칙을 따릅니다. Pixar는 유명하게 스토리의 요소를 스토리 척추라고 부르는 수식으로 쌓았습니다. “Once Upon a Time...” “그리고 매일...” “어느 날까지...” “그리고 그 때문에...” “그리고 그 때문에...” “마침내...” “그날 이후로...” 이 스토리 척추를 좋은 스토리 스토리를위한 모델로 생각할 수 있습니다. 헐리우드 블록버스터는 비슷한 공식을 사용합니다.사설의 "규칙"을 따르는 것은 우리가 우디를 쓰레기보다는 영웅으로, 레미를 건강 코드 위반보다는 예술가로, 네모를 희망이없는 것보다는 용감하게 보는 이유입니다. 이 모델의 규칙 내에서 창의성에 대한 많은 기회가 있습니다.좋은 스토리핑의 규칙을 내면화하는 스토리터들은 새로운 스토리와 새로운 영화를 만들기 위해 찾고 있습니다. 일부 감독, 작가 및 프로듀서는 표준 스토리 트레이닝 모델에 맞지 않는 이야기를 이야기하기 위해이 최선의 스토리 트레이닝 관행에서 벗어날 수 있지만 명확한 이야기가없는 영화는 아름답게 촬영되더라도 매번 상자에 실패 할 것입니다. 우리는 데이터로 스토리를 어떻게 엔지니어링하는가 헐리우드와 마찬가지로 기술의 세계에서 우리의 이야기는 단순히 기록되는 것이 아니라 그에 따라 행동됩니다.우리는 전자들이 우리가 정의한 구조로 런을 자르도록 지시합니다.다른 기술자 또는 지식 노동자들은 우리가 수년 동안 만들어 왔던 것에 대해 언급 할 수 있습니다. 데이터 관리의 관계 모델은 그리고 1960 년대와 70 년대에 정의 된 SQL Server, Oracle, Snowflake, Redshift, MySQL, Clickhouse, Cockroach DB, DuckDB, 그리고 그 이후의 많은 문제를 해결했습니다. 크리스 데이트 테드 코드 다음은 데이터베이스 시스템에 대한 소개 (An Introduction to Database Systems)라는 책에서 언급한 예제 테이블입니다. EMP# ENAME DEPT# SALARY E1 Lopez D1 40K E2 Cheng D1 42K E3 Finzi D2 30K E4 Saito D2 35K EMP# ENAME DEPT# SALARY E1 Lopez D1 40K E2 Cheng D1 42K E3 Finzi D2 30K E4 Saito D2 35K EMP # 하나하나 깊은 # 월급 abstract에서, 이 predicate는 다음과 같이 정의됩니다: “Employee EMP#는 ENAME라고 불리며 DEPT# 부서에서 일하며 월급을 받습니다.” 구체적으로, 우리는 이것을 다음과 같이 해석할 수 있습니다: “직원 E1은 로페즈라는 이름으로, D1 부서에서 일하고 40K의 임금을 받는다.” 이 테이블이 나타내는 데이터의 이야기를 설명하는 것은 쉽습니다.This is how you know you're doing it right. AI가 데이터베이스 성능 문제를 해결하지 못하는 이유 나는 데이터베이스 성능이 나쁘다고 생각되는 상황에 여러 번 가져 왔고, 응용 프로그램 개발자가 만든 데이터 구조가 효과적인 스토리 링을 보장하는 잘 문서화 된 최선의 관행 규칙을 수십 년 동안 완전히 무시했다는 것을 발견했습니다. 응용 프로그램 개발자 또는 비즈니스 사용자가 우리의 텍스트 처리 및 텍스트 생성 도구가 사용하는 인스턴스를 작성하면, 그 도구는 실제 작업 코드와 안정적인 데이터 구조에 통합되어야하는 텍스트를 생성합니다. 이러한 규칙을 구현하는 사람들이 규칙을 이해하고 그 이유를 이해하지 않는 한, 잘못된 데이터 구조가 더 빨리 만들어지게 될 것입니다. 귀하의 역할이 건축가, 개발자, 엔지니어, 사용자, 또는 미래에 발생할 수있는 다른 타이틀이든간에, 당신은 궁극적으로 미래의 문제를 해결하기 위해 유지, 저장, 대표 및 사용되는 것에 대한 책임이 있습니다. 수십 년 동안 존재해 왔던 이러한 최선의 관행으로 돌아가면 더 나은 창조적 인 건축가가 될 것입니다. 이것이 당신의 마크를 만드는 방법입니다. 네, 당신은 기업의 작은 부분입니다.그러나 당신은 세계에 당신의 흔적을 남기고 싶어, 그렇지 않습니까? 휘트먼은 그의 시에서 비슷한 질문을 던졌습니다 “오 나, 오 생명! "What good amid these, O me, O life?" 우리 모두를위한 대답은 : "That you are here—that life exists and identity, That the powerful play goes on, and you may contribute a verse." 어떤 이야기를 말하기로 결정할 것인가? 만약 당신이 스노우플레이스라면 데이터베이스 관리자 또는 데이터 엔지니어 , DataOps.live는 도움을 줄 수 있습니다. 오늘 시작하세요 — 매달 500분 무료로 이용하실 수 있습니다! 데이터베이스 관리자 데이터 엔지니어 매달 500분 무료로 이용하실 수 있습니다!
