지금 vs. 그때: 내가 지금 그것을 어떻게 지을지, 아니면 내가 그 당시에 그것을 어떻게 지을지

점진적인 진전은 가늠하기 어렵다.작년에 배운 지식을 되돌아보기 위해 나는 1, 2년 전에 내가 생각했던 간단한 응용 프로그램의 간단한 실현과 오늘날 내가 그것을 어떻게 구축할 것인지를 비교했다.

질문:

식당 종업원의 힌트를 추적하고 보고하는 프로그램을 설계하다

패턴은 어떻게 해야 하나요?

버전 1:

CREATE TABLE waiters (
    id int,
    name varchar,
    tip_total int
);

이 버전의 응용 프로그램에서는 프롬프트가 수집되면 시스템에 입력됩니다.대기 인원에 대한 업데이트 총수를 포함하는 줄입니다.
이 SQL은 다음과 같이 보일 수 있습니다.

  SELECT *  FROM waiters WHERE id=:id;

  # Application logic calculates new values 
  # Something like: new_amount = result[2] + amount

 UPDATE waiters SET tip_total=:new_amount WHERE id=:id;

저녁 끝날 때의 보도 기교는 다음과 같다.

SELECT name, tip_total FROM waiters;

그리고 모든 팁이 나눠진 후에 나는 계속 진행할 수 있고, 계수를 0으로 돌려 다음날을 위해 준비할 수 있다.간단해.

UPDATE waiters SET tip_total = 0;

그런데 잠깐만요. 종업원이 테이블에 팁을 주는 게 어때요?
두 개의 연속적인 select/업데이트 문장은 어떻습니까? 이 두 문장에서, 분할 업데이트량은 응용 프로그램 논리로 관리됩니다.

버전 2

CREATE TABLE waiters (
    id int,
    name varchar
);

CREATE TABLE tips (
    id int,
    staff_id int,
    currency_code varchar,
    amount int,
    time datetime,
    FOREIGN KEY (staff_id) REFERENCES waiters(id)
);

이 버전의 프로그램에서 알림이 시스템에 추가되면 알림표에 줄을 삽입합니다.예를 들면 다음과 같습니다.

 INSERT INTO tips VALUES (1, :table, :usd, :now)

보고는 지금 좀 복잡해졌다.대기 중인 직원에게 알림을 보고하기 위해서는 다음과 같은 것이 필요합니다.

SELECT SUM(amount), currency_code, CONVERT( Date, time) as d GROUP BY currency_code where staff_id = :staff_id AND d = :today 

이것은 tips를 받아들인 모든 화폐를 보여 주는 표를 제공할 것입니다. 그리고 프로그램 논리에서 달러로 전환해야 합니다.

이 두 가지 방법의 차이는 무엇입니까?
물론 이 두 버전 모두 진정한 생산 품질 응용 프로그램과는 거리가 멀지만, 나는 버전 2가 더 좋다고 생각하는 몇 가지 원인을 깊이 있게 연구하고 싶다.

가장 심각한 죄악에서 가장 가벼운 죄악까지

데이터를 삭제하여 정확한 계수를 유지하기 때문에 우리는 어떠한 역사 보고도 신속하게 회고하고 진행할 수 있는 능력을 잃었다.

최신 버전의 tip total을 가져와 새로운 값을 계산함으로써 tip

을 잃어버릴 수 있는 열악한 멀티쓰기 프로그램 경쟁 조건을 도입했습니다.

데이터베이스에서 수동으로 집합을 유지하려고 합니다.이것은 우리가 미래에 보고할 능력을 제한한다.

버스트 프롬프트의 경우 버전 1에서 트랜잭션을 사용하지 않습니다.이것은 프로세스가 사망하거나 부적절한 이상이 일부 알림만 적용될 수 있음을 의미한다.

버전 2 에서는 이러한 문제를 처리하는 방법을 설명합니다.

어떤 사람들은 심지어 이 점을 포함해서 모두 어리석은 것 같다고 생각할 수도 있다.나는 데이터베이스를 거의 접해 본 적이 없는 이 버전이 좋다고 생각할 것이라고 장담할 수 있다. 내 말은, 헤헤, 응용 프로그램의 요구를 충족시켰다는 것이다.그러나 내가 본 주요 단점은 현재 응용 프로그램의 요구를 충족시켰지만 미래의 증명이 아니라는 것이다.네가 이 문제를 묻자, 나의 매일 저녁 평균 팁은 얼마니?너는 운이 좀 나쁘다. 데이터가 이미 없어졌다.또 다른 믿을 수 없는 단점은 데이터 삭제가 무섭다는 것이다.만약 당신이 틀렸다면 그것을 찾을 수 없거나, 만약 당신이 전송한 프로그램 버전에 잘못된 조회가 있다면, 패치 버전이 있으면 다시 업무에 투입할 수 있습니다.

수공이 이 숫자를 유지하는 데 가져오는 가장 심각한 죄악은 우리가 그것을 계산하는 방식이라고 할 수 있다.우리는 읽은 후에 응용 프로그램 논리를 사용하여 새로운 숫자 업데이트 열을 사용합니다.만약 두 라인이 동시에 쓰기를 시도한다면 무슨 일이 일어날까요?

좋아요.만약 우리가 운이 좋지 않다면, 예를 들면:

# Bob has $15 in tips
Thread 1: Reads current tip total of $15
Thread 2: Read current tip total of $15
Thread 1: Calculates new values should be $17, and updates the database
Thread 2:  Calculates new values should be $16, and updates the database

# Final value: Bob has $16 in tips

읊다, 읊조리다우리는 방금 첫 2달러의 팁을 포기했다.
우리는 조심스러운 잠금을 도입함으로써 이 문제를 해결할 수 있다.사무 격리 단계를 REPEATABLE_READ로 설정하고 SELECT... FOR UPDATE를 사용하면 목적을 달성할 수 있습니다.이것은 매우 복잡한 문제로 잘못되기 쉽다.우리들은 그들 자신의 표에 힌트를 삽입할 것이다.동시에 표에 줄을 추가하는 것은 우리에게 어떠한 고통도 가져다 주지 않는다.데이터베이스는 이 문제를 해결할 수 있다.

데이터베이스는 집합 통계 데이터를 생성하는 데 매우 뛰어나다.데이터베이스에 남겨 두자.우리는 함수를 유지하고 있지만, 만약 우리가 평균치를 원한다면?아니면 중위수?데이터베이스에 데이터를 저장하고 데이터에 따라 계산을 실행합시다.

제 예는 사무를 많이 강조하지 않았지만 제가 작년에 배운 가장 중요한 것은 사무를 사용하는 것이 중요하다는 것입니다.toy app land에서는 복잡한 검색과 업데이트를 쉽게 피할 수 있으며 이러한 검색과 업데이트는 일치성을 유지해야 한다.리얼 앱 랜드에서 조회는 복잡해지고 진정한 사용자는 까다로운 변두리 사례를 찾을 수 있다.사무는 데이터베이스와의 상호작용을 그룹으로 나누는 기본 구조입니다.현재의 상황을 보면, 만약 데이터베이스와 관련된 일련의 일을 하고 있다면, 읽기와 쓰기의 일치성을 확보하기 위해 같은 업무로 그룹화되어야 할 수도 있다.

전반적으로 말하면, 때때로 지식은 종종 내가 진정으로 주의하지 않은 상황에서 그곳에 앉아서 축적된다.가끔 앉아서 네 머릿속의 새로운 것을 생각해 보는 것이 좋다.
즐거움 코드