Cách lập mô hình nhiều người dùng sử dụng một cách khác nhau (ví dụ: vũ khí) cho hàng tồn kho / vật thể / vật phẩm (ví dụ katana) trong cơ sở dữ liệu quan hệ

Vì vậy, tôi đang làm việc để mở rộng việc sử dụng các mục trên tại www.ninjawars.net và tôi không chắc chắn chính xác làm thế nào để thể hiện chúng một cách linh hoạt trong cơ sở dữ liệu quan hệ mà chúng tôi sử dụng.

Tôi có thể đang sủa sai cây, vì vậy hãy thoải mái đưa ra đề xuất theo các hướng khác, nhưng hiện tại tôi đang nghĩ rằng mỗi mục nên có "thẻ" quan hệ.

Ví dụ: Katana hiện là một hàng trong cơ sở dữ liệu "vật phẩm". Để biến nó thành vũ khí, và một thứ có thể giữ được, tôi đã nghĩ rằng tôi sẽ có một cơ sở dữ liệu về "đặc điểm" và một bảng item_traits liên kết đơn giản giữa chúng.

// 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

Tôi không thực sự chắc chắn làm thế nào để mô hình hóa dữ liệu bổ sung mà kết quả (ví dụ như thiệt hại mà thanh kiếm sẽ gây ra, damage_type, v.v.).

Tôi cũng không đặc biệt vui mừng khi toàn bộ một mặt hàng sẽ được lưu trữ ở nhiều nơi, ví dụ: để tạo một bản sao của một mặt hàng có tên khác, như "thanh kiếm ngắn", tôi sẽ phải sao chép từ nhiều bảng để tạo các mục trùng lặp.

Có cách nào tốt hơn để đặt những thứ này mà tôi đang thiếu không?

Chỉnh sửa: Tôi chỉ cần lưu ý rằng tôi đã sử dụng cơ sở dữ liệu postgresql trên trang web, đó là lý do tại sao tôi muốn sử dụng nó để lưu trữ dữ liệu của mình.

Chỉnh sửa: Tôi đã thêm một câu trả lời cho việc triển khai mà tôi hiện đang xem xét.

Tôi sẽ không đồng ý với tất cả mọi người và nói rằng cách tiếp cận quan hệ là hợp lý ở đây. Điều thú vị ở đây là các mặt hàng có thể có nhiều vai trò. Vấn đề chính là việc ánh xạ giữa bố cục quan hệ này và bố cục OO trong mã sẽ không cảm nhận được tự nhiên, nhưng tôi nghĩ về phía cơ sở dữ liệu, nhiều vai trò có thể được thể hiện rõ ràng (không có mã hóa hoặc dự phòng lạ, chỉ cần tham gia) .

Điều đầu tiên để quyết định là bao nhiêu dữ liệu là mục cụ thể và bao nhiêu được chia sẻ bởi tất cả các mục của một loại nhất định.

Đây là những gì tôi sẽ làm nếu tất cả dữ liệu là mục cụ thể:

// 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  | ...

Trong thiết kế này, mọi mục đều nằm trong bảng Mục, cùng với các thuộc tính mà tất cả (hoặc hầu hết) các mục có. Mỗi vai trò bổ sung mà một vật phẩm có thể đóng là một bảng riêng biệt.

Nếu bạn muốn sử dụng nó làm vũ khí, bạn sẽ tìm kiếm nó trong bảng Vũ khí. Nếu nó ở đó, thì nó có thể sử dụng như một vũ khí. Nếu nó không ở đó, thì nó không thể được sử dụng làm vũ khí. Sự tồn tại của hồ sơ cho bạn biết đó có phải là vũ khí hay không. Và nếu nó ở đó, tất cả các thuộc tính dành riêng cho vũ khí của nó được lưu trữ ở đó. Vì các thuộc tính đó được lưu trữ trực tiếp thay vì ở dạng được mã hóa, bạn sẽ có thể thực hiện các truy vấn / bộ lọc với chúng. (Ví dụ: đối với trang số liệu của trò chơi của bạn, bạn có thể muốn tổng hợp người chơi theo loại sát thương vũ khí và bạn có thể làm điều đó với một số phép nối và damage_type theo nhóm.)

Một vật phẩm có thể có nhiều vai trò và tồn tại trong nhiều bảng cụ thể theo vai trò (trong ví dụ này, cả vũ khí và ánh sáng).

Nếu nó chỉ là một kiểu boolean như "cái này có thể giữ được", tôi sẽ đặt nó vào bảng Vật phẩm. Nó có thể đáng lưu vào bộ nhớ cache "đây có phải là vũ khí" không, v.v. để bạn không phải thực hiện tra cứu Vũ khí và các bảng vai trò khác. Tuy nhiên, nó bổ sung tính dự phòng nên bạn phải cẩn thận để giữ cho nó đồng bộ.

Khuyến nghị của Ari về việc có một bảng bổ sung cho mỗi loại cũng có thể được sử dụng với phương pháp này nếu một số dữ liệu sẽ không thay đổi theo từng mục. Ví dụ: nếu sát thương vũ khí không thay đổi theo từng vật phẩm, nhưng vai trò vẫn thay đổi theo từng vật phẩm, bạn có thể tính các thuộc tính vũ khí được chia sẻ vào một bảng:

// 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

Một cách tiếp cận khác là nếu vai trò của các vật phẩm không thay đổi theo vật phẩm, mà chỉ theo loại vật phẩm. Trong trường hợp đó, bạn đặt item_type vào bảng Vật phẩm và có thể lưu trữ các thuộc tính như "nó có phải là vũ khí" và "có thể giữ được không" và "có phải là đèn" trong bảng ItemTypes không. Trong ví dụ này tôi cũng làm cho tên các mặt hàng không thay đổi theo từng mặt hàng:

// 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

Có khả năng các loại vật phẩm và vũ khí không thay đổi trong trò chơi, vì vậy bạn chỉ cần tải các bảng đó vào bộ nhớ một lần và tìm kiếm các thuộc tính đó trong bảng băm thay vì tham gia cơ sở dữ liệu.

Thật không may, các tình huống như thế này là nơi các cơ sở dữ liệu quan hệ (như SQL) bị thiếu và các cơ sở dữ liệu không liên quan (như MongoDB ) xuất sắc. Điều đó đang được nói, không thể mô hình hóa dữ liệu trong cơ sở dữ liệu quan hệ và vì có vẻ như cơ sở mã của bạn đã phụ thuộc vào SQL, đây là mô hình tôi sẽ sử dụng:

Thay vì tạo một mục và sử dụng bảng, hãy tạo một bảng và bảng tham chiếu "[item] _type" cho từng loại mục.

Đây là vài ví dụ:

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

Giải pháp này mang đến cho bạn rất nhiều tính linh hoạt và khả năng mở rộng lâu dài, nó làm giảm (nếu không loại bỏ) không gian bị lãng phí và tự ghi lại tài liệu (không giống như "item_use_data"). Nó liên quan đến việc thiết lập nhiều hơn một chút về kết thúc của nhà phát triển, nhưng, theo tôi, đó là giải pháp thanh lịch nhất có sẵn cho các tình huống bạn cần sử dụng cơ sở dữ liệu quan hệ để lưu trữ dữ liệu của mình. Nói chung, cơ sở dữ liệu phi quan hệ tốt hơn nhiều cho việc phát triển trò chơi, vì chúng linh hoạt hơn trong cách họ mô hình hóa dữ liệu, trong khi hiệu quả hơn so với cơ sở dữ liệu dựa trên SQL - làm cho chúng trở thành lựa chọn "cùng thắng".

Chỉnh sửa 1: Đã sửa lỗi với trường potion_type_id

Chỉnh sửa 2: Đã thêm chi tiết về cơ sở dữ liệu không liên quan so với quan hệ để cung cấp thêm phối cảnh

Trước hết, kết xuất phương pháp kế thừa hướng đối tượng và đi với một hệ thống dựa trên thành phần .

Khi bạn đã thực hiện điều đó, bố cục SQL đột nhiên trở nên dễ dàng hơn nhiều. Bạn có một bảng cho mỗi loại thành phần với số ID được chia sẻ. Nếu bạn muốn mục số 17, bạn hãy tìm kiếm "mục ID 17" trong mỗi bảng. Bất kỳ bảng nào có khóa được thêm thành phần của nó vào.

Bảng Vật phẩm của bạn chứa tất cả dữ liệu cần thiết cho các vật phẩm nói chung (tên, giá bán, trọng lượng, kích thước, mọi thứ khác được chia sẻ giữa tất cả các mặt hàng.) Bảng Vũ khí của bạn chứa tất cả dữ liệu phù hợp cho vũ khí, bảng Potion của bạn chứa tất cả dữ liệu phù hợp đối với potions, bảng Armor của bạn chứa tất cả dữ liệu thích hợp cho áo giáp. Muốn có một tấm giáp ngực, đó là một mục trong Vật phẩm và một mục trong Giáp. Muốn có một thanh kiếm mà bạn có thể uống, bạn chỉ cần đặt một mục trong mỗi bàn, và bam, bạn đã hoàn thành.

Hãy nhớ rằng mẫu tương tự này không đặc biệt dành riêng cho từng mặt hàng - bạn có thể sử dụng mẫu này cho sinh vật, khu vực, bất cứ thứ gì bạn muốn. Nó linh hoạt đáng ngạc nhiên.

Sử dụng SQL là sai lầm nghiêm trọng của bạn. Nó hoàn toàn KHÔNG phù hợp để lưu trữ dữ liệu thiết kế trò chơi tĩnh.

Nếu bạn không thể rời khỏi SQL, tôi sẽ xem xét việc lưu trữ các mục trong một tuần tự từ. I E

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

Tất nhiên, điều đó thật xấu xí và ném tất cả các "niceties" ra khỏi cửa sổ, nhưng bạn có thực sự cần chúng không? Rất có thể, bạn vẫn đọc tất cả dữ liệu vật phẩm của mình tại trò chơi bắt đầu và không bao giờ SELECTbằng bất cứ thứ gì khác ngoài item_id.

Tùy thuộc vào số lượng tính trạng bạn có thể cần, bạn có thể sử dụng bitmask đơn giản cho các đối tượng có các bit khác nhau tương ứng với các đặc điểm khác nhau:

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

Sau đó, bạn có thể thực hiện các kiểm tra bit đơn giản để xem liệu một đối tượng có thể được sử dụng cho một chức năng nhất định hay không.

Vì vậy, "chai thủy tinh" có thể có giá trị 101111 nghĩa là nó có thể giữ được, có thể được sử dụng làm vũ khí, nó dễ dàng phá vỡ, bạn có thể ném nó và nó có thể chứa chất lỏng.

Bất kỳ trình soạn thảo nào bạn tạo cho các mục sau đó có thể có một bộ hộp kiểm đơn giản để bật / tắt các đặc điểm trên một đối tượng.

Trong dự án của chúng tôi, chúng tôi có item_attote cho "dữ liệu bổ sung" khác nhau mà một mục có thể có. Nó được đặt ra một cái gì đó như thế này:

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

Sau đó, chúng ta có một bảng thuộc tính trông giống như vậy:

id |   name       | description
1    attackspeed    AttackSpeed:

Ari Patrick là đúng mặc dù, cuối cùng quan hệ db không được thực hiện cho điều này. Nhược điểm là chúng tôi có một số quy trình khá phức tạp để tạo các mục mới (được thực hiện thông qua một công cụ bên ngoài - mà tôi rất khuyến khích, Đừng thử và thêm thủ công, bạn sẽ chỉ tự nhầm lẫn)

Tùy chọn khác mà bạn có là sử dụng ngôn ngữ kịch bản để tạo các mẫu vật phẩm, sau đó bạn có thể dễ dàng phân tích những thứ đó và sử dụng nó để tạo các mục mới. Tất nhiên bạn vẫn phải lưu dữ liệu mục trong cơ sở dữ liệu nhưng tại thời điểm đó, bạn không cần phải lo lắng về việc tạo các mục mới, bạn có thể sao chép và tập tin tập lệnh cũ, thay đổi một số thông tin và bạn vẫn ổn đi.

Thành thật mà nói, nếu chúng ta làm lại cách chúng ta tạo các mục tĩnh mới, có lẽ chúng ta sẽ sử dụng một cách tiếp cận đơn giản hơn nhiều bằng cách sử dụng các mẫu mục kịch bản.

Đây là mối quan hệ nhiều-nhiều điển hình của bạn, không có gì quá bí truyền cho bất kỳ cơ sở dữ liệu quan hệ có khả năng. Bạn có nhiều đặc điểm cho bất kỳ một đối tượng nào và bất kỳ một đặc điểm nào cũng có thể được sử dụng bởi một hoặc nhiều loại đối tượng khác nhau. Mô hình ba mối quan hệ (bảng), với một mối quan hệ liên kết và bạn đã hoàn thành. Lập chỉ mục đúng sẽ đảm bảo cho bạn đọc dữ liệu nhanh chóng.

Tạo một ORM trong mã của bạn và bạn sẽ có rất ít vấn đề qua lại giữa DB và phần mềm trung gian. Nhiều ORM cũng có thể tự động tạo các lớp, và do đó càng trở nên "vô hình" hơn.

Đối với cơ sở dữ liệu NoQuery, không có lý do gì bạn không thể làm điều đó với những cơ sở dữ liệu đó. Hiện tại, đây là thời trang để cổ vũ cho công nghệ đó trong giẻ lau và blog thương mại, nhưng chúng đi kèm với một loạt các vấn đề của riêng nó: nền tảng tương đối non nớt, tuyệt vời cho các lần đọc thay đổi không thường xuyên (như một cặp song sinh trong một hồ sơ) nhưng kém cho việc đọc hoặc cập nhật động phức tạp, chuỗi công cụ hỗ trợ kém, dữ liệu dư thừa và các vấn đề toàn vẹn đi kèm, v.v. Tuy nhiên, chúng mang lại sự hấp dẫn về khả năng mở rộng tốt hơn vì chúng tránh được các khả năng giao dịch ở mức độ khác nhau và chi phí phân phối / sao chép dễ dàng hơn .

Hobgoblin thông thường của cơ sở dữ liệu quan hệ so với cơ sở dữ liệu NoQuery là hiệu suất. Các RDMBS khác nhau có mức độ chi phí liên quan khác nhau khiến chúng ít được ưa thích hơn để mở rộng theo cấp độ của Facebook hoặc Twitter. Tuy nhiên, rất có thể bạn sẽ không phải đối mặt với những vấn đề đó. Thậm chí sau đó, các hệ thống máy chủ dựa trên SSD đơn giản có thể khiến cuộc tranh luận về hiệu năng trở nên vô dụng.

Chúng ta hãy rõ ràng: hầu hết các cơ sở dữ liệu NoQuery là các bảng băm được phân phối cơ bản và sẽ giới hạn bạn giống như cách một bảng băm trong mã của bạn, nghĩa là. không phải tất cả dữ liệu phù hợp với mô hình đó. Mô hình quan hệ mạnh hơn nhiều để mô hình hóa quan hệ giữa các dữ liệu. (Yếu tố gây nhiễu là hầu hết các RDBMS là các hệ thống kế thừa được điều chỉnh kém cho các yêu cầu của 0,0001% phổ biến của web, cụ thể là Facebook và cộng sự).

Đây là nơi tôi thấy các trình ánh xạ HOẶC hiện đại hơn thực sự hữu ích, như Entity Framework 4 và tính năng mã đầu tiên (CTP) của nó . Bạn chỉ cần viết các lớp và mối quan hệ của chúng bằng mã thông thường và thậm chí không cần phải trang trí chúng hoặc chạy thủ công bất kỳ công cụ nào, EF sẽ tạo kho lưu trữ sao lưu ở định dạng SQL cho bạn, với các bảng liên kết bắt buộc và tất cả ... nó thực sự giải phóng sự sáng tạo imo ^^

Đây là những gì tôi đang xem xét:

Vì mọi "đặc điểm" về cơ bản đều yêu cầu thay đổi mã, vì vậy tôi đã quyết định chỉ giữ các đặc điểm (và bất kỳ dữ liệu mặc định nào chúng yêu cầu) trong chính mã (ít nhất là bây giờ).

Ví dụ $traits = array('holdable'=>1, 'weapon'=>1, 'sword'=>array('min_dam'=>1, 'max_dam'=>500));

Sau đó, các mục nhận được trường "trait_data" trong cơ sở dữ liệu sẽ sử dụng json_encode()hàm để được lưu trữ ở định dạng JSON.

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]}}}"

Kế hoạch là các mục sẽ kế thừa tất cả các số liệu thống kê mặc định từ các đặc điểm cha mẹ của chúng và sẽ chỉ có các đặc điểm vượt quá xác định sự khác biệt so với các đặc điểm được đặt làm mặc định.

Nhược điểm của trường đặc điểm là trong khi tôi có thể chỉnh sửa phần json bằng tay ... ... sẽ không thực sự dễ dàng hoặc an toàn khi làm như vậy với dữ liệu trong cơ sở dữ liệu.

Đây là một chút khó khăn và tôi không đảm bảo rằng nó có thiết kế DB tốt; Các lớp DB của tôi cách đây một thời gian và chúng không xuất hiện nhanh chóng. Nhưng nếu các mục được đảm bảo có, có ít hơn 10 mục, bạn có thể cung cấp cho mỗi mục một trường thuộc tính1 và trường thuộc tính2, v.v. lên đến thuộc tính10. Nó sẽ loại bỏ nhu cầu của bạn đối với bảng thuộc tính nhiều-nhiều, với chi phí giới hạn số lượng thuộc tính.

Nhìn lại, tôi khá chắc chắn rằng nó có thiết kế khủng khiếp, nhưng điều đó có nghĩa là bạn có thể gắn bó với một cơ sở dữ liệu quan hệ thoải mái và không phải đi vào lãnh thổ chưa được khám phá. Tùy thuộc vào bạn để quyết định xem sự đánh đổi có xứng đáng hay không.

Nevermind đã đưa ra một câu trả lời tốt, nhưng tôi tự hỏi, bạn thậm chí có cần một cơ sở dữ liệu cho việc này không? Lưu trữ tất cả dữ liệu trong một tệp đơn giản và tải nó vào chương trình khi khởi chạy có vẻ như là cách thông minh nhất để làm điều này.

Chỉnh sửa:
Đúng, trong một môi trường theo yêu cầu không trạng thái, bạn nên giữ dữ liệu trong cơ sở dữ liệu. Viết dữ liệu của bạn vào một tệp và viết một đoạn mã để biến nó thành cơ sở dữ liệu thuộc loại Nevermind đề xuất.

Luân phiên nếu số lượng đối tượng không quá lớn khai báo lô theo nghĩa đen trong tệp mã có thể là phương pháp nhanh nhất.