관계형 데이터베이스 내에서 사용 가능한 인벤토리 / 객체 / 항목 (예 : katana)에 대해 여러 "사용"(예 : 무기)을 모델링하는 방법

따라서 www.ninjawars.net 에서 항목 사용을 확장하려고 노력하고 있으며 사용 하는 관계형 데이터베이스에서 유연하게 표현하는 방법을 잘 모르겠습니다.

잘못된 나무를 짖을 수도 있으므로 다른 방향으로 자유롭게 제안 해주세요. 그러나 현재 각 항목에 관계형 "태그"가 있어야한다고 생각합니다.

예를 들어, Katana는 현재 "items"데이터베이스의 행입니다. 그것을 무기로 만들 수 있고, 보유 할 수있는 물건으로 만들기 위해, 나는 "특성"의 데이터베이스와 그 사이에 단순히 연결된 item_traits 테이블을 가질 것이라고 생각했습니다.

// Objects and their basic data

item_id | item
1 | Naginata


// Things that objects can do

trait_id | trait
1 | weapon
2 | holdable

// How those objects do those things, e.g. powerfully, weakly, while on fire

_item_id | _trait_id | item_trait_data
1 | 1 | damage: 5, damage_type: sharp, whatever, etc

결과로 생성되는 추가 데이터 (예 : 칼의 피해, Damage_type 등)를 모델링하는 방법을 잘 모르겠습니다.

또한 항목 전체가 둘 이상의 위치에 저장되어 있다는 사실에 특히 만족하지 않습니다. 예를 들어 "짧은 검"과 같이 다른 이름으로 항목의 사본을 만들려면 다음에서 복사해야합니다. 중복 항목을 작성하기 위해 여러 테이블.

내가 놓친 물건을 배치하는 더 좋은 방법이 있습니까?

편집 : 나는 사이트에서 이미 사용중인 postgresql 데이터베이스를 가지고 있다는 것을 알아야합니다. 그래서 데이터 저장을 위해 데이터베이스를 사용하고 싶습니다.

편집 : 현재보고있는 구현에 대한 답변을 추가했습니다.

나는 모든 사람에 대해 약간 동의하지 않고 여기에서 관계형 접근 방식이 합리적이라고 말합니다. 여기서 흥미로운 점은 항목이 여러 역할을 가질 수 있다는 것입니다. 주요 문제는 코드 에서이 관계형 레이아웃과 OO 레이아웃 간의 매핑이 "자연스럽지 않다"고 생각하지만 데이터베이스 측면에서 여러 역할이 깔끔하게 표현 될 수 있다고 생각합니다 (이상한 인코딩이나 중복없이 조인). .

첫 번째로 결정해야 할 것은 항목 별 데이터 양과 지정된 유형의 모든 항목이 공유하는 양입니다.

모든 데이터가 항목별로 지정된 경우 수행 할 작업은 다음과 같습니다 .

// ITEMS table: attributes common to all items
item_id | name        | owner         | location             | sprite_id | ...
1       | Light Saber | 14 (Tchalvek) | 381 (Tchalvek house) | 5663      | ...

// WEAPONS table: attributes for items that are weapons
item_id | damage | damage_type | durability | ...
1       | 5      | sharp       | 13         | ...

// LIGHTING table: attributes for items that serve as lights
item_id | radius   | brightness | duration | ...
1       | 3 meters | 50         | 8 hours  | ...

이 디자인에서 모든 항목은 모든 (또는 대부분의) 항목의 속성과 함께 항목 테이블에 있습니다. 항목이 수행 할 수있는 각 추가 역할은 별도의 테이블입니다.

무기로 사용하려면 무기 테이블에서 찾아보십시오. 그것이 있으면 무기로 사용할 수 있습니다. 존재하지 않으면 무기로 사용할 수 없습니다. 기록의 존재는 그것이 무기인지 여부를 알려줍니다. 그리고 거기에 있다면, 모든 무기 특유의 속성이 거기에 저장됩니다. 이러한 속성은 인코딩 된 형식 대신 직접 저장되므로 쿼리 / 필터를 사용하여 수행 할 수 있습니다. 예를 들어 게임의 메트릭 페이지의 경우 무기 손상 유형별로 플레이어를 집계 할 수 있으며 일부 조인과 그룹 별 damage_type을 사용하여이를 수행 할 수 있습니다.

아이템은 여러 역할을 가질 수 있으며 둘 이상의 역할 별 테이블 (이 예에서는 무기와 조명 모두)에 존재할 수 있습니다.

"이것이 보류 가능"과 같은 부울 인 경우 Items 테이블에 넣습니다. 무기와 기타 역할 테이블을 조회 할 필요가 없도록 "무기"등을 캐싱하는 것이 좋습니다. 그러나 중복성을 추가하므로 동기화 상태를 유지해야합니다.

일부 데이터가 항목마다 다르지 않은 경우 유형별 로 추가 테이블을 사용하는 Ari의 권장 사항 도이 방법과 함께 사용할 수 있습니다. 예를 들어 무기 피해가 항목마다 다르지 않지만 역할이 여전히 항목마다 다른 경우 공유 무기 속성을 표로 분류 할 수 있습니다.

// WEAPONS table: attributes for items that are weapons
item_id | durability | weapon_type
1       | 13         | light_saber

// WEAPONTYPES table: attributes for classes of weapons
weapon_type_id | damage | damage_type
light_saber    | 5      | energy

항목별로 수행되는 역할이 항목별로 다르지 않고 항목 유형별로만 다른 경우가 있습니다. 이 경우 item_type을 Items 테이블에 저장하고 ItemTypes 테이블에 "무기", "보존 가능"및 "가벼움"과 같은 속성을 저장할 수 있습니다. 이 예제에서는 항목 이름도 항목마다 다르지 않습니다.

// ITEMS table: attributes per item
item_id | item_type    | owner         | location
1       | light_saber  | 14 (Tchalvek) | 381 (Tchalvek house)

// ITEMTYPES table: attributes shared by all items of a type
item_type   | name        | sprite_id | is_holdable | is_weapon | is_light
light_saber | Light Saber | 5663      | true        | true      | true

// WEAPONTYPES table: attributes for item types that are also weapons
item_type   | damage | damage_type
light_saber | 5      | energy

게임 중에 아이템 유형과 무기 유형이 변경되지 않을 가능성이 있으므로 해당 테이블을 한 번 메모리에로드하고 데이터베이스 조인 대신 해시 테이블에서 해당 속성을 조회 할 수 있습니다.

불행히도 이와 같은 상황은 관계형 데이터베이스 (예 : SQL)가 부족하고 관계형이 아닌 데이터베이스 (예 : MongoDB )가 우수합니다. 즉, 관계형 데이터베이스에서 데이터를 모델링하는 것은 불가능하지 않으며 코드베이스가 이미 SQL에 의존하는 것처럼 보이기 때문에 다음과 같이 할 모델이 있습니다.

항목을 작성하고 테이블을 사용하는 대신 각 항목 유형에 대해 테이블 ​​및 "[item] _type"참조 테이블을 작성하십시오.

다음은 몇 가지 예입니다.

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

이 솔루션은 장기적인 유연성과 확장 성을 제공하며, 낭비되는 공간을 줄이거 나 (제거하지 않을 경우) 자체 문서화합니다 ( "item_use_data"와 달리). 개발자 측에서는 약간 더 설정이 필요하지만 관계형 데이터베이스를 사용하여 데이터를 저장 해야하는 상황에서 사용할 수있는 가장 우아한 솔루션입니다. 일반적으로, 비 관계형 데이터베이스는 SQL 기반 데이터베이스보다 성능이 뛰어나면서 데이터를 모델링하는 방법이 더 유연하여 "윈윈 (win-win)"선택이되기 때문에 게임 개발에 훨씬 좋습니다.

편집 1 : potion_type_id 필드의 오류 수정

편집 2 : 관계형 데이터베이스와 비 관계형 데이터베이스에 대한 추가 정보를 추가하여 추가 관점 제공

먼저 객체 지향 상속 접근 방식을 덤프하고 구성 요소 기반 시스템을 사용하십시오 .

일단 그렇게하면 SQL 레이아웃이 갑자기 훨씬 쉬워집니다. 공유 된 ID 번호를 가진 각 구성 요소 유형마다 하나의 테이블이 있습니다. 항목 # 17을 원하면 모든 테이블에서 "항목 ID 17"을 찾으십시오. 키가있는 테이블은 구성 요소가 추가됩니다.

아이템 테이블에는 아이템에 필요한 모든 데이터가 포함되어 있습니다 (이름, 판매 가격, 무게, 크기, 모든 아이템간에 공유되는 것). 물약의 경우, 갑옷 테이블에는 갑옷에 대한 모든 적절한 데이터가 들어 있습니다. 흉갑을 원합니다. 이것은 아이템에 들어가고 방어구에 들어갑니다. 당신이 마실 수있는 검술을 원하고, 각 테이블에 항목을 입력하면됩니다.

이 동일한 패턴은 특히 항목별로 다르지 않습니다. 생물체, 영역 등 원하는 용도로 사용할 수 있습니다. 놀랍게도 다재다능합니다.

SQL을 사용하는 것은 큰 실수였습니다. 정적 게임 디자인 데이터를 저장하는 데 절대적으로 적합하지 않습니다.

SQL에서 벗어날 수 없다면 직렬화 된 항목을 저장하는 것이 좋습니다. 즉

item_id (int) | item (BLOB)
1             | <binary data>

물론, 그것은 추악하고 모든 SQL "niceness"를 창 밖으로 던지지 만 실제로는 필요 합니까? 어쨌든 게임 시작시 모든 항목 데이터를 읽 SELECT습니다 item_id.

필요한 특성의 수에 따라 다른 특성에 해당하는 다른 비트를 가진 객체에 간단한 비트 마스크를 사용할 수 있습니다.

000001 = holdable
000010 = weapon
000100 = breakable
001000 = throwable
010000 = solids container
100000 = liquids container

그런 다음 간단한 비트 테스트를 수행하여 특정 기능에 객체를 사용할 수 있는지 확인할 수 있습니다.

따라서 "유리 병"은 101111의 값을 가질 수 있으며, 보유 가능하고, 무기로 사용할 수 있으며, 쉽게 부러 질 수 있으며, 던질 수 있고 액체를 포함 할 수 있습니다.

그런 다음 항목에 대해 생성 한 편집기는 객체에 특성을 활성화 / 비활성화하는 간단한 확인란 세트를 가질 수 있습니다.

우리 프로젝트 에는 아이템이 가질 수있는 다른 "추가 데이터"에 대한 item_attributes 가 있습니다. 다음과 같이 배치되었습니다.

item_id | attribute_id    | attribute_value | order 
1        25 (attackspeed)       50             3    

그런 다음 다음과 같은 속성 테이블이 있습니다.

id |   name       | description
1    attackspeed    AttackSpeed:

아리 패트릭 (Ari Patrick)은 그렇습니다. 결국 관계형 DB는 이것을 위해 만들어지지 않았습니다. 단점은 새 항목을 생성하는 매우 복잡한 절차가 있다는 것입니다 (외부 도구를 통해 수행-강력히 권장합니다.이를 수동으로 추가하려고 시도하지 마십시오. 혼란하게됩니다)

다른 옵션으로 는 스크립팅 언어를 사용하여 항목 템플릿을 만든 다음 쉽게 템플릿을 구문 분석하고이를 사용하여 새 항목을 만들 수 있습니다. 물론 데이터베이스에 항목 데이터를 저장해야하지만 그 시점에서 새 항목 작성에 대한 세부 사항에 대해 걱정할 필요가 없습니다. 복사하고 오래된 스크립트 파일을 복사하고 일부 정보를 변경하면 좋습니다. 토고.

솔직히, 우리가 새로운 정적 아이템을 만드는 방법을 다시 수행한다면, 스크립팅 아이템 템플릿을 사용하는 훨씬 간단한 접근법을 시도 할 것입니다.

이것은 전형적인 다 대다 관계이며, 유능한 관계형 데이터베이스에는 너무 난해하지 않습니다. 하나의 오브젝트에 대해 많은 특성이 있으며 하나의 특성이 하나 이상의 다른 오브젝트 유형에 의해 사용될 수 있습니다. 세 가지 관계 (테이블)를 모델링하고 하나는 연관 관계로 작성하면 끝납니다. 적절한 색인 생성은 빠른 데이터 읽기를 보장합니다.

코드에 ORM을 계층화하면 DB와 미들웨어간에 거의 문제가 발생하지 않습니다. 많은 ORM은 클래스 자체를 자동 생성 할 수 있으므로 훨씬 더 "보이지 않는"상태가됩니다.

NoSQL 데이터베이스는 데이터베이스를 사용할 수없는 이유가 없습니다. 현재 트레이드 래그 및 블로그에서 해당 기술을 응원하는 것은 유행이지만, 상대적으로 미성숙 한 플랫폼, 자주 변경되지 않는 간단한 읽기 (프로파일의 일대 다 트위트와 같은)에 적합한 자체 문제가 많이 있지만 복잡한 동적 읽기 또는 업데이트, 열악한 지원 툴체인, 중복 데이터 및 수반되는 무결성 문제 등에는 좋지 않습니다. 그러나 다양한 수준의 트랜잭션 기능과 오버 헤드로 배제되어보다 쉬운 분산 / 복제 모델로 확장 성이 향상되었습니다. .

관계형 데이터베이스와 NoSQL 데이터베이스의 일반적인 홉보 블린은 성능입니다. 다른 RDMBS는 페이스 북 또는 트위터 수준으로 확장하기에 덜 선호되는 오버 헤드의 정도가 다릅니다. 그러나 이러한 문제에 직면 할 가능성은 거의 없습니다. 그럼에도 불구하고 단순한 SSD 기반 서버 시스템은 성능 토론을 쓸모 없게 만들 수 있습니다.

대부분의 NoSQL 데이터베이스는 기본적으로 분산 된 해시 테이블이며 코드의 해시 테이블과 같은 방식으로 제한합니다. 모든 데이터가 해당 모델에 적합하지는 않습니다. 관계형 모델은 데이터 간의 관계를 모델링하는 데 훨씬 더 강력합니다. 혼란스러운 요소는 대부분의 RDBMS가 웹의 인기있는 0.0001 %, 즉 Facebook 등의 요구에 맞게 조정되지 않은 레거시 시스템이라는 것입니다.

여기에서 Entity Framework 4 및 (CTP) 코드 우선 기능 과 같이 더 현대적인 OR 매퍼가 실제로 유용 합니다 . 클래스와 관계를 정규 코드로 작성하고 장식하거나 도구를 수동으로 실행할 필요없이 EF는 필요한 링크 테이블과 함께 모든 형식의 백업 저장소를 SQL 형식으로 생성합니다. ^^

내가 지금 고려하고있는 것은 다음과 같습니다.

모든 "특성"은 본질적으로 코드의 변경을 필요로하기 때문에 코드 (적어도 지금은)에 특성 (및 필요한 기본 데이터)을 유지하기로 결정했습니다.

예 : $traits = array('holdable'=>1, 'weapon'=>1, 'sword'=>array('min_dam'=>1, 'max_dam'=>500));

그런 다음 항목은 데이터베이스에서 json_encode()함수를 사용 하여 JSON 형식으로 저장 되는 "trait_data"필드 를 가져옵니다.

item_id | item_name | item_identity | traits
1 | Katana | katana | "{"holdable":1,"weapon":1,"sword":{"min_dam":1,"max_dam":1234,"0":{"damage_type":"fire","min_dam":5,"max_dam":50,"type":"thrown","bob":{},"ids":[1,2,3,4,5,6,7]}}}"

계획은 항목이 상위 특성에서 모든 기본 통계를 상속하며 특성이 기본값으로 설정 한 것과의 차이를 지정하는 재정의 특성 만 갖습니다.

특성 필드의 단점은 json 부분을 손으로 편집 할 수 있지만 데이터베이스에있는 데이터로는 그렇게하기가 쉽지 않거나 안전하지 않다는 것입니다.

이것은 약간 해키이며 좋은 DB 디자인이라는 것을 보장하지 않습니다. 내 DB 수업은 얼마 전에 있었으며 빠르게 생각하지 않습니다. 그러나 항목에 10 개 미만의 항목이 있다고 보장되면 각 항목에 attribute1 필드 및 attribute2 필드 등을 attribute10까지 부여 할 수 있습니다. 속성 수를 제한하는 대가로 다 대다 항목 속성 테이블이 필요하지 않습니다.

그것을 되돌아 보면, 나는 그것이 끔찍한 디자인이라고 확신하지만, 그것은 당신이 편안한 관계형 데이터베이스를 고수하고 미지의 영역으로 갈 필요가 없다는 것을 의미합니다. 트레이드 오프가 가치가 있는지 결정하는 것은 당신에게 달려 있습니다.

네버 마인드는 좋은 대답을했지만 이것에 대한 데이터베이스가 필요한지 궁금합니다. 모든 데이터를 일반 파일에 저장하고 시작시 프로그램에로드하는 것이 가장 현명한 방법 인 것 같습니다.

편집 :
상태 비 저장 요청 중심 환경에서는 데이터를 데이터베이스에 유지하는 것이 좋습니다. 파일에 데이터를 작성하고 코드를 작성하여 Nevermind 제안 유형의 데이터베이스로 변환하십시오.

또는 객체 수가 너무 많지 않으면 코드 파일에서 로트를 문자 그대로 선언하는 것이 가장 빠른 방법 일 수 있습니다.