1. 실제 시나리오:
데이터베이스의 주문 테이블은 공개되어 있으며 모든 사용자가 하나의 주문 테이블에 있습니다.
각 사용자의 주문 번호를 독립적인 네임스페이스로 만드는 방법은 무엇입니까? 예를 들어, 사용자 A가 두 번 주문을 하면 주문 번호는 C001과 C002여야 합니다. 사용자 B가 세 번 주문을 하면 번호의 시작 위치는 C003이 아니라 C001이어야 합니다. C003.
어떻게 하나요?
각 사용자 아래에 현재 개설된 주문 수에 대한 필드를 저장한 다음 먼저 읽어보고 추가한 다음 매번 다시 저장해야 합니까? 이건 좋지 않아요... 데이터베이스 측에서 더 좋은 방법이 있을까요? 누군가 데이터베이스 기능이나 트리거 사용에 관해 이야기하는 것을 들은 것 같습니다.
2. 데이터베이스가 위와 같은 작업을 수행할 수 있다면 일반적으로 이 C001이 기본 키 필드에 존재합니까? 아니면 기본 키가 여전히 숫자 유형의 증분 기본 키인가요? 이 C001을 저장하기 위해 테이블에 필드를 추가하기만 하면 되나요?
참고: Mysql 데이터베이스에 있습니다.
1. 실제 시나리오:
데이터베이스의 주문 테이블은 공개되어 있으며 모든 사용자가 하나의 주문 테이블에 있습니다.
각 사용자의 주문 번호를 독립적인 네임스페이스로 만드는 방법은 무엇입니까? 예를 들어, 사용자 A가 두 번 주문을 하면 주문 번호는 C001과 C002여야 합니다. 사용자 B가 세 번 주문을 하면 번호의 시작 위치는 C003이 아니라 C001이어야 합니다. C003.
어떻게 하나요?
각 사용자 아래에 현재 개설된 주문 수에 대한 필드를 저장한 다음 먼저 읽어보고 추가한 다음 매번 다시 저장해야 합니까? 이건 좋지 않아요... 데이터베이스 측에서 더 좋은 방법이 있을까요? 누군가 데이터베이스 기능이나 트리거 사용에 관해 이야기하는 것을 들은 것 같습니다.
2. 데이터베이스가 위와 같은 작업을 수행할 수 있다면 일반적으로 이 C001이 기본 키 필드에 존재합니까? 아니면 기본 키가 여전히 숫자 유형의 증분 기본 키인가요? 이 C001을 저장하기 위해 테이블에 필드를 추가하기만 하면 되나요?
참고: Mysql 데이터베이스에 있습니다.
1: 이렇게 데이터베이스에 저장할 필요는 없습니다. 모든 주문을 순회하여 순서대로 표시하기만 하면 됩니다.
2: 각 사용자 속성에 静态成员变量을 추가하고 그에 따라 데이터베이스에 필드를 추가하세요. 매번 추가되는 데이터는 말씀하신 대로 됩니다.
포스터의 의미는 서로 다른 고객 계정에 대한 통합 주문 관리 라이브러리를 구축한다는 것입니다. 서로 다른 계정은 자신의 주문만 볼 수 있으며 이는 클라우드 ERP와 다소 유사합니다.
주문 테이블에는 중복된 기본 키 ID가 있을 수 있으며, 데이터 저장 고유성 측면에서 데이터를 고유하게 확인하는 주문 코드 사용자 ID로 볼 수 있습니다.
테이블 구조의 디자인을 최적화해야 하는 경우 각 사용자에 따라 자동으로 주문 테이블을 생성하고 각 사용자의 주문 데이터를 분리할 수 있습니다. 테이블 이름은 매번 해당 테이블 이름과 유사합니다. 사용자에 따라 발견되면 데이터를 가져오지만 모든 사용자 주문 데이터에 대한 최종 종합 배경 통계는 약간 번거로울 수 있습니다.
주문의 고유성을 어떻게 보장할 수 있나요
제목의 의미에 맞게 데이터베이스를 설계한 경우에는 주문 검색 작업만 예외가 발생합니다. 주문번호로는 고유주문을 판단할 수 없기 때문입니다.
기본 키 값은 테이블의 레코드를 고유하게 식별하는 데 사용됩니다.
(프로젝트 정보
제안 사항:
주문 테이블의 기본 키는 OrderId
이고 사용자 테이블의 기본 키는 UserId
일 수 있습니다. 문제는 다음과 같습니다. 데이터베이스 테이블에 대한 기본적인 이해를 위해서는 데이터베이스 정규화 )
orderid 테이블을 사용하여 모든 사용자의 다음 주문 ID를 저장하는 것이 번거롭다면 주문 번호의 일부로 시간을 사용하는 것이 좋습니다.
은 기본 키로 사용할 수 없습니다. 기본 키 설계에는 비즈니스와 관련이 없어야 한다는 원칙이 있습니다. 따라서 기본 키는 항상 의미 없는 자동 증가 ID 등입니다.
귀하의 질문이 해결하려는 실제 요구 사항이 무엇인지 모르겠습니다
테이블 구조의 디자인은 가장 기본적인 세 가지 패러다임의 요구 사항을 준수해야 합니다. 세 가지 패러다임의 목적은 필드 간 중복성이나 종속성이 없도록 보장하는 것입니다. 위에서 언급한 문제를 반복하지 않겠습니다. 이와 같은 설계는 데이터베이스 테이블 구조 설계의 세 가지 주요 패러다임 원칙을 위반합니다. 그러한 설계를 수행해서는 안 됩니다. 그렇지 않으면 우리가 오해한 것입니다. 질문을 바꿔보세요. 또는 테이블 생성 명세서를 직접 게시하세요.
공동 기본 키를 사용하여 uid와 cid를 결합하면 고유성을 보장할 수 있습니다. 단, 다음 두 가지 사항에 주의하시기 바랍니다.
1. mysql 공동 기본 키 자동 증가를 사용하려면 MyISAM을 스토리지 엔진으로 사용해야 합니다.
2. 공용체를 사용하여 기본 키를 자동 증가시키는 경우 자동 증가 키는 기본 키의 가장 왼쪽 키가 될 수 없습니다.
주문 테이블에 user_owner_order_key를 추가한 다음 C001과 실제 order_id 간의 교환 논리를 처리하는 코드를 직접 작성하세요.
<code>//伪码 $user_owner_order_id = (select count(*) from order where user = $uid and order_id < $currentOrderId order by order_id asc) + 1; $user_owner_order_key = $uid . fillZero($user_owern_order_id);</code>
또 다른 문제를 말씀드리자면, 일반적으로 第三方支付는 同一个订单号에 대해 여러 번 지불할 수 없으므로, 그렇게 할지 신중하게 고려하는 것이 좋습니다.
사용자 테이블에는 주문 수량을 저장하는 필드가 있을 수 있습니다. 새 주문이 있을 때마다 이 값을 추가한 다음 다시 업데이트하세요.
새 주문에는 기존 주문 수에 1을 더한 값이 추가됩니다. 단, 주문을 삭제할 때는 일시 삭제해야 합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
