Cara memodelkan beberapa "kegunaan" (mis. Senjata) untuk inventaris / objek / item yang dapat digunakan (mis. Katana) dalam database relasional

10

Jadi saya sedang berupaya memperluas penggunaan item di www.ninjawars.net , dan saya tidak yakin bagaimana cara mewakili mereka secara fleksibel dalam database relasional yang kami gunakan.

Saya mungkin menggonggong pohon yang salah, jadi jangan ragu untuk membuat saran ke arah lain, tetapi saat ini saya berpikir bahwa setiap item harus memiliki "tag" relasional.

Sebagai contoh, Katana saat ini adalah baris dalam database "items". Untuk membuatnya menjadi senjata, dan benda yang bisa dipegang, saya berpikir bahwa saya akan memiliki database "sifat", dan tabel item_traits yang hanya terhubung di antara mereka.

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

Saya tidak benar-benar yakin bagaimana memodelkan data tambahan yang dihasilkan (mis. Kerusakan yang dilakukan pedang, tipe damage_type, dll).

Saya juga tidak terlalu senang bahwa seluruh item akan disimpan di lebih dari satu tempat, misalnya untuk membuat salinan item dengan nama yang berbeda, seperti "pedang pendek", saya harus menyalin dari beberapa tabel untuk membuat item duplikat.

Apakah ada cara yang lebih baik untuk mengeluarkan barang ini yang saya lewatkan?

Sunting: Saya hanya perlu mencatat bahwa saya sudah punya database postgresql yang digunakan di situs, itulah sebabnya saya ingin menggunakannya untuk penyimpanan data saya.

Sunting: Saya telah menambahkan jawaban untuk implementasi yang saat ini saya lihat.

Kzqai
sumber

Jawaban:

10

Saya akan sedikit tidak setuju dengan semua orang dan mengatakan bahwa pendekatan relasional masuk akal di sini. Yang menarik di sini adalah item dapat memiliki banyak peran. Masalah utama adalah bahwa pemetaan antara tata letak relasional ini dan tata letak OO dalam kode tidak akan terasa "alami", tapi saya pikir di sisi database banyak peran dapat diekspresikan dengan bersih (tanpa pengkodean atau redundansi yang aneh, hanya bergabung) .

Hal pertama yang harus diputuskan adalah berapa banyak data spesifik item dan berapa banyak dibagi oleh semua item dari jenis tertentu.

Inilah yang akan saya lakukan jika semua data spesifik untuk item:

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

Dalam desain ini, setiap item ada di tabel Item, bersama dengan atribut yang dimiliki semua (atau sebagian besar) item. Setiap peran tambahan yang dapat dimainkan item adalah tabel terpisah.

Jika Anda ingin menggunakannya sebagai senjata, Anda akan mencarinya di tabel Senjata. Jika itu ada, maka itu dapat digunakan sebagai senjata. Jika tidak ada di sana, maka itu tidak dapat digunakan sebagai senjata. Keberadaan catatan memberi tahu Anda apakah itu senjata. Dan jika itu ada di sana, semua atribut spesifik senjata disimpan di sana. Karena atribut tersebut disimpan secara langsung alih-alih dalam bentuk yang disandikan, Anda dapat melakukan kueri / filter dengannya. (Misalnya, untuk halaman metrik game Anda, Anda mungkin ingin mengagregasi pemain berdasarkan jenis kerusakan senjata, dan Anda dapat melakukannya dengan beberapa gabungan dan grup-by damage_type.)

Item dapat memiliki beberapa peran, dan ada di lebih dari satu tabel peran-spesifik (dalam contoh ini, baik senjata maupun pencahayaan).

Jika itu hanya boolean seperti "apakah ini bisa dipegang", saya akan memasukkannya ke dalam tabel Item. Mungkin layak untuk di-cache "apakah ini senjata" dll di sana sehingga Anda tidak perlu melakukan pencarian pada Senjata dan tabel peran lainnya. Namun, itu menambah redundansi sehingga Anda harus berhati-hati untuk tetap menyinkronkannya.

Rekomendasi Ari untuk memiliki tabel tambahan per jenis juga dapat digunakan dengan pendekatan ini jika beberapa data tidak akan bervariasi per item. Misalnya, jika kerusakan senjata tidak bervariasi per item, tetapi perannya masih bervariasi per item, Anda dapat memasukkan faktor atribut senjata bersama ke dalam tabel:

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

Pendekatan lain adalah jika peran yang dimainkan oleh item tidak bervariasi berdasarkan item, tetapi hanya berdasarkan jenis item. Dalam hal ini Anda akan meletakkan item_type ke dalam tabel Items, dan dapat menyimpan properti seperti "apakah itu senjata" dan "apakah itu dapat ditampung" dan "apakah itu cahaya" di tabel ItemTypes? Dalam contoh ini saya juga membuat nama item tidak berbeda per item:

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

Kemungkinan itemtypes dan weaponontypes tidak berubah selama permainan, jadi Anda bisa memuat tabel-tabel itu ke dalam memori satu kali, dan mencari atribut-atribut itu di tabel hash alih-alih dengan penggabungan basis data.

amitp
sumber
+1. Ini adalah satu-satunya jawaban yang menggunakan basis data relasional sebagai basis data relasional. Apa pun selain dari ini atau saran lain dari gumpalan Nevermind dan hanya menggunakan DB sebagai penyimpan data, adalah rencana yang mengerikan.
+1 Namun pendekatan ini tampaknya tidak fleksibel. Saya minta maaf jika kedengarannya tidak konsisten, tetapi saya ingin dapat membuat struktur basis data untuk barang-barang pada dasarnya ... ... lalu mengkodekan lebih banyak fitur untuk barang, membuat lebih banyak sisipan ke dalam basis data untuk barang, tetapi tidak harus mengubah database lagi di masa depan (dengan pengecualian yang jarang, tentu saja).
Kzqai
Jika Anda ingin database relasional tahu tentang bidang Anda dan mengoptimalkan representasi mereka, Anda perlu menambahkannya di suatu tempat. Ini seperti tipe statis. Jika Anda ingin kompiler Anda tahu tentang bidang Anda dan mengoptimalkan representasi mereka, Anda perlu mendeklarasikan tipe. Alternatifnya adalah pendekatan yang diketik secara dinamis, digunakan oleh beberapa basis data dokumen, atau dengan menyandikan data Anda ke dalam basis data relasional dengan beberapa cara. Basis data tidak akan tahu bidang apa yang bisa mengoptimalkan penyimpanannya, tetapi Anda akan mendapatkan fleksibilitas.
amitp
4

Sayangnya, situasi seperti ini adalah tempat database relasional (seperti SQL) gagal, dan database non-relasional (seperti MongoDB ) unggul. Yang sedang berkata, bukan tidak mungkin untuk memodelkan data dalam database relasional, dan karena sepertinya basis kode Anda sudah bergantung pada SQL, berikut adalah model yang akan saya gunakan:

Alih-alih membuat item dan menggunakan tabel, buat tabel dan tabel referensi "[item] _type" untuk setiap jenis item.

Berikut ini beberapa contoh:

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

Solusi ini memberi Anda banyak fleksibilitas jangka panjang dan skalabilitas, mengurangi (jika tidak menghilangkan) ruang yang terbuang, dan mendokumentasikan diri sendiri (tidak seperti "item_use_data"). Ini melibatkan sedikit pengaturan di sisi pengembang, tetapi, menurut saya, ini adalah solusi paling elegan yang tersedia untuk situasi di mana Anda perlu menggunakan database relasional untuk menyimpan data Anda. Secara umum, database non-relasional jauh lebih baik untuk pengembangan game, karena mereka lebih fleksibel dalam cara mereka memodelkan data, sementara menjadi lebih berkinerja daripada database berbasis SQL - menjadikannya pilihan "win-win".

Sunting 1: Memperbaiki kesalahan dengan bidang potion_type_id

Sunting 2: Menambahkan lebih detail pada basis data non-relasional vs relasional untuk memberikan perspektif tambahan

Ari Patrick
sumber
Saya tidak benar-benar melihat banyak fleksibilitas yang keluar dari sistem itu. Sebagai contoh, jika saya ingin botol kaca, dapat digunakan sebagai senjata, dan menjadi 'tajam' ... ... saya akan kurang beruntung. Plus, untuk setiap jenis barang baru, saya harus benar-benar membuat struktur basis data untuknya. Bahkan jika hanya ada satu atau dua tipe.
Kzqai
Poin yang Anda kemukakan sangat valid, dan sorot contoh tambahan mengapa database relasional tidak cocok untuk situasi khusus ini. Model yang saya sajikan hanya menunjukkan cara terbaik untuk meletakkan data sedemikian rupa sehingga memori disimpan dan fungsi SQL dipertahankan. Untuk menyimpan item yang memiliki banyak jenis, cara terbaik untuk menyatakan bahwa data dalam model ini adalah dengan membuat tabel potion_weapon dengan ramuan yang tepat dan properti senjata. Sekali lagi, solusi ini BUKAN ideal, tapi itu solusi yang paling elegan saat menggunakan database relasional.
Ari Patrick 8-10
@Ari: Tidak bermaksud menghina, tetapi masalahnya justru mengapa pendekatan relasional lebih valid, tidak kurang. Diketahui bahwa basis data NoSQL (atau NoRel) bagus untuk pembacaan volume tinggi, data terdistribusi / sangat tersedia, atau skema yang tidak jelas. Kasus ini hanyalah perkumpulan klasik banyak-ke-banyak, dan dbs seperti Mongo tidak melakukan ini sebaik RDBMS. Lihat stackoverflow.com/questions/3332093/...
alphadogg
@alphadogg Bagaimana ini hubungan banyak-ke-banyak? Dalam database, senjata tahu tentang jenis senjata, tetapi jenis senjata tidak perlu tahu tentang senjata yang terkait dengannya. Jika karena alasan tertentu Anda ingin mengetahui semua senjata yang memiliki jenis senjata tertentu, Anda cukup menulis kueri yang beralih ke koleksi dokumen senjata.
Ari Patrick
@ Ari: Dalam pertanyaan OP, satu senjata mungkin memiliki banyak jenis, dan satu jenis dapat dikaitkan dengan banyak senjata. Sebagai contoh, ramuan dan pedang bisa dipegang. Pedang bisa dipegang dan juga senjata.
alphadogg
3

Pertama, buang pendekatan pewarisan berorientasi objek dan pergi dengan sistem berbasis komponen .

Setelah Anda selesai melakukannya, tata letak SQL tiba-tiba menjadi jauh lebih mudah. Anda memiliki satu tabel untuk setiap jenis komponen dengan nomor ID bersama. Jika Anda ingin item # 17, Anda mencari "item ID 17" di setiap tabel. Setiap tabel yang memiliki kunci akan ditambahkan komponennya.

Tabel Item Anda berisi semua data yang diperlukan untuk item secara umum (nama, harga jual, berat, ukuran, apa pun yang dibagikan di antara semua item.) Tabel Senjata Anda berisi semua data yang sesuai untuk senjata, tabel Ramuan Anda berisi semua data yang sesuai untuk ramuan, tabel Armor Anda berisi semua data yang sesuai untuk baju besi. Ingin penutup dada, itu entri di Item dan entri di Armor. Ingin pedang yang bisa Anda minum, Anda hanya memasukkan entri di setiap meja, dan bam, Anda sudah selesai.

Ingatlah bahwa pola yang sama ini tidak terlalu spesifik untuk barang tertentu - Anda dapat menggunakan ini untuk makhluk, zona, apa pun yang Anda inginkan. Ini sangat serbaguna.

ZorbaTHut
sumber
2

Menggunakan SQL adalah kesalahan besar Anda. Sama sekali TIDAK cocok untuk menyimpan data desain game statis.

Jika Anda tidak dapat menjauh dari SQL, saya akan mempertimbangkan menyimpan item dalam serial dari. Yaitu

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

Tentu saja, itu jelek dan membuang semua "kebaikan" SQL keluar jendela, tetapi apakah Anda benar - benar membutuhkannya ? Kemungkinan besar, Anda membaca semua data item Anda di permulaan permainan, dan tidak pernah SELECTdengan hal lain selain itu item_id.

Lupakan
sumber
3
Karena (dari pemahaman saya), gim ini multipemain dan mendukung PvP, ada kemungkinan sebagian besar informasi gameplay tidak disimpan di klien. Jika itu akurat, maka setiap kali data dibaca dari tabel, itu akan harus deserialized sebelum berguna dari jarak jauh. Akibatnya, format ini membuat kueri item dengan properti mereka SANGAT mahal; misalnya: jika Anda ingin mengambil semua item yang bertipe "senjata", Anda harus mengambil setiap item, membatalkan deserialisasi masing-masing, lalu memfilter secara manual untuk jenis "senjata", sebagai lawan menjalankan kueri sederhana .
Ari Patrick
1
Dari pengalaman saya, semua item dibaca ke dalam cache di memori pada awal permainan. Jadi Anda hanya membatalkan deserialisasi sekali pada saat startup, dan tidak menggunakan database sama sekali setelah itu. Jika tidak demikian dalam kasus ini, maka saya setuju, menyimpan objek berseri adalah ide yang buruk.
Nevermind
Hmmm, satu-satunya hal adalah ini membuat saya dengan antarmuka -required- untuk mengedit data, yang akan merepotkan.
Kzqai
2

Bergantung pada berapa banyak sifat yang mungkin Anda perlukan, Anda bisa menggunakan bitmask sederhana untuk objek dengan bit berbeda sesuai dengan ciri berbeda:

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

Kemudian Anda dapat melakukan tes bit sederhana untuk melihat apakah suatu objek dapat digunakan untuk fungsi tertentu.

Jadi "botol kaca" mungkin memiliki nilai 101111 yang berarti dapat dipegang, dapat digunakan sebagai senjata, mudah pecah, Anda dapat membuangnya dan dapat berisi cairan.

Editor apa pun yang Anda buat untuk item kemudian dapat memiliki satu set kotak centang sederhana untuk mengaktifkan / menonaktifkan sifat pada suatu objek.

Muttley
sumber
1
Saya suka ide itu, karena memungkinkan item untuk menahan sifatnya sendiri, dan saya tidak tahu bahwa saya perlu mencari basis data untuk ciri-ciri itu, tetapi saya tidak begitu yakin bagaimana cara membuatnya bekerja. dalam konteks relasional. Saya kira setiap bit akan memetakan ke id tambahan sifat-sifat dalam database ...
Kzqai
Saya kira bitmasking lebih bermanfaat untuk jumlah karakter yang tetap?
Kzqai
Sangat banyak sehingga. Apa yang terjadi jika Anda telah menggunakan "bit" terakhir Anda? Seberapa mudah untuk meningkatkan tipe data untuk mendapatkan bit dan meresapnya melalui lapisan aplikasi Anda, atau menambahkan kolom dan melakukan hal yang sama? Juga, apakah mesin basis data khusus Anda telah disesuaikan untuk pengindeksan untuk operasi bit? Yang terbaik dalam database relasional untuk tetap atom dengan kolom data. Jangan gabungkan banyak domain ke dalam satu kolom. Anda tidak dapat memanfaatkan manfaat platform.
alphadogg
1
Jika Anda menginginkan tabel pencarian dalam DB untuk sifat-sifat (mungkin ide yang bagus karena Anda dapat menambahkannya secara dinamis ke editor apa pun kemudian) maka itu hanya akan memiliki sesuatu seperti ini: id, bitmask, description. 1,1, "Dapat Ditahan"; 2,2, "Senjata"; 3,4, "Breakable", dll. Sehubungan dengan nomor tetap, ya ini benar. Tetapi jika Anda menggunakan int 64bit, Anda harus memiliki banyak ruang lingkup.
Muttley
1

Di proyek kami, kami memiliki item_attributes untuk "data ekstra" berbeda yang mungkin dimiliki suatu item. Ditata kira-kira seperti ini:

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

Kemudian kita memiliki tabel atribut yang terlihat seperti ini:

id |   name       | description
1    attackspeed    AttackSpeed:

Ari Patrick benar, akhirnya db relasional tidak dibuat untuk ini. Kelemahannya adalah kami memiliki beberapa prosedur yang cukup rumit untuk menghasilkan item baru (dilakukan melalui alat eksternal - yang saya sangat rekomendasikan, Jangan coba dan secara manual menambahkan ini, Anda hanya akan membingungkan diri Anda sendiri)

Opsi lain yang Anda miliki adalah menggunakan bahasa skrip untuk membuat templat item, maka Anda dapat dengan mudah menguraikan yang ada dan menggunakannya untuk membuat item baru. Anda tentu saja masih harus menyimpan data item dalam database tetapi pada saat itu Anda tidak perlu khawatir tentang spesifik membuat item baru, Anda dapat cukup banyak hanya menyalin dan file skrip lama, mengubah beberapa informasi dan Anda baik untuk pergi.

Sejujurnya, jika kita melakukan kembali bagaimana kita membuat item statis baru kita mungkin akan pergi untuk pendekatan yang lebih sederhana menggunakan templat item skrip.

Kyle C
sumber
1

Ini adalah hubungan banyak-ke-banyak Anda yang khas, tidak ada yang terlalu esoteris untuk basis data relasional yang mampu. Anda memiliki banyak sifat untuk satu objek, dan satu sifat apa pun dapat digunakan oleh satu atau lebih tipe objek yang berbeda. Model tiga relasi (tabel), dengan satu menjadi hubungan asosiasi, dan Anda selesai. Pengindeksan yang tepat akan memastikan Anda membaca data dengan cepat.

Lapisan ORM dalam kode Anda dan Anda harus memiliki sedikit masalah bolak-balik antara DB dan middleware. Banyak ORM yang dapat membuat sendiri kelas secara otomatis, sehingga menjadi lebih "tidak terlihat".

Adapun untuk database NoSQL, tidak ada alasan Anda tidak dapat melakukannya dengan itu. Saat ini sedang populer untuk mendukung teknologi itu dalam perdagangan kain dan blog, tetapi mereka datang dengan banyak masalah sendiri: platform yang relatif belum matang, bagus untuk bacaan sederhana yang jarang berubah (seperti satu-ke-banyak twit dalam profil) tetapi buruk untuk pembacaan atau pembaruan dinamis yang rumit, rantai alat pendukung yang buruk, data yang berlebihan dan masalah integritas yang menyertainya, dll. Namun, mereka menawarkan daya tarik skalabilitas yang lebih baik karena mereka menghindari berbagai tingkat kemampuan transaksional dan overhead-nya, dan model distribusi / replikasi yang lebih mudah .

Hobgoblin biasa dari database relasional vs database NoSQL adalah kinerja. RDMBS yang berbeda memiliki tingkat overhead yang berbeda yang terlibat yang membuatnya kurang disukai untuk penskalaan ke tingkat Facebook atau Twitter. Namun, sangat tidak mungkin Anda akan menghadapi masalah tersebut. Bahkan kemudian, sistem server berbasis SSD yang sederhana dapat membuat perdebatan kinerja menjadi tidak berguna.

Mari kita perjelas: kebanyakan basis data NoSQL adalah tabel hash yang terdistribusi secara fundamental, dan akan membatasi Anda dengan cara yang sama dengan tabel hash dalam kode Anda, yaitu. tidak semua data cocok dengan model itu. Model Relasional jauh lebih kuat untuk memodelkan hubungan antar data. (Faktor perancu adalah bahwa sebagian besar RDBMSes adalah sistem warisan yang tidak disetel dengan baik untuk tuntutan 0,0001% dari web yang populer, yaitu Facebook dkk.)

alphadogg
sumber
Jika Anda akan merujuk mereka secara kolektif, jangan repot-repot berbicara tentang database. NoSQL bukan entitas yang dapat didiskusikan secara bermakna, ini adalah referensi massa yang tidak berguna yang digunakan SQL fanbois untuk menerapkan logika yang salah bahwa jika satu database dari grup yang didefinisikan ini tidak memiliki fitur maka mereka semua tidak memiliki fitur tersebut.
aaaaaaaaaaaa
NoSQL adalah istilah yang dipilih oleh biola NoSQL untuk beradaptasi. Saya tidak tahu mengapa, itu tidak terlalu deskriptif. Tapi itu bukan semacam penghinaan. Setelah bekerja dengan beberapa, saya pikir deskripsi alphadogg tentang mereka adil.
Mungkin komentar saya agak keras, masih, saya benci nama dan pengelompokan itu, tidak mungkin untuk memiliki debat yang berkualitas tentang detail yang lebih baik dari sistem database yang berbeda ketika orang-orang mempertahankan pandangan dunia yang disederhanakan ini.
aaaaaaaaaaaa
@eBusiness: Saya menemukan komentar Anda lucu, mengingat bahwa itu adalah kamp anti-RDBMS, jika ada, yang mengatur sendiri kelompok teknologi mereka sebagai "NoSQL". Diakui, banyak dari mereka ingin melihat nama itu ditinggalkan, di belakang. Terutama karena banyak dari mereka yang akhirnya meletakkan SQL pada implementasi fisik mereka. Mengenai berbicara tentang mereka, saya tidak menganggap komentar Anda keras, atau saya memiliki kulit tebal, pilihan Anda! :) Maksud saya, orang dapat berbicara tentang Pesta Teh, mengapa tidak kelompok basis data NoSQL?
alphadogg
Itu adil, saya menyadari bahwa hubungannya sangat banyak dengan banyak orang. Hal yang menghentikan saya dari menciptakannya dalam gaya yang benar-benar dinormalisasi adalah pemikiran bahwa "barang" yang akan membentuk suatu barang kemudian akan tersebar di setidaknya dua meja. Saya tidak suka ide tidak dapat membuat sisipan atom, saya pikir.
Kzqai
0

Di sinilah saya menemukan lebih banyak pemetaan ATAU modern yang benar-benar berguna, seperti Entity Framework 4 dan fitur pertama kode- nya (CTP) . Anda cukup menulis kelas dan hubungan mereka dalam kode reguler dan bahkan tanpa harus menghiasnya atau menjalankan alat apa pun secara manual, EF akan menghasilkan backing store dalam format SQL untuk Anda, dengan tabel tautan yang diperlukan dan semua ... benar-benar melepaskan kreativitas. ^^

Oskar Duveborn
sumber
Baiklah, saya akan membuat kode dan kelas dan semua itu dalam kode hanya pertama ... ... hanya harus menerjemahkannya ke dalam struktur basis data yang ada setelah.
Kzqai
0

Inilah yang sekarang saya pertimbangkan:

Karena setiap "sifat" pada dasarnya memerlukan perubahan dalam kode, jadi saya telah memutuskan untuk tetap mempertahankan sifat (dan data default apa pun yang diperlukan) dalam kode itu sendiri (setidaknya untuk saat ini).

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

Kemudian item mendapatkan bidang "trait_data" dalam database yang akan menggunakan json_encode()fungsi untuk disimpan dalam format 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]}}}"

Plan adalah bahwa item akan mewarisi semua statistik default dari sifat induknya, dan hanya akan memiliki sifat over-ride yang menentukan perbedaan dari apa yang ditetapkan sebagai sifat bawaan.

Kelemahan dari bidang sifat adalah bahwa sementara saya bisa mengedit bagian json dengan tangan ... ... itu tidak akan benar-benar mudah atau aman untuk melakukannya dengan data yang ada di database.

Kzqai
sumber
1
Apa yang terjadi ketika Anda memperkenalkan sifat baru? Seberapa sering ini bisa terjadi? Apa efek hilir pada beban kerja pemeliharaan kode Anda? Kontras dengan menyimpannya sebagai banyak-ke-banyak di mana instance objek Anda dibangun secara dinamis (melalui ORM pilihan Anda) untuk menyimpan data itu.
alphadogg
Terima kasih, itu poin yang bagus, menambahkan sifat-sifat baru tidak akan sepele. Anda telah menambahkan ke kelumpuhan analisis saya. : p
Kzqai
Maaf, tapi ini cukup kritis. Anda hanya perlu memikirkannya. Model latihan dalam pikiran Anda tentang apa yang harus Anda lakukan ketika beberapa senjata perlu diperbarui untuk menambahkan sifat baru sehingga peningkatan permainan Anda bisa bekerja.
alphadogg
-1

Ini agak hacky, dan saya tidak menjamin itu desain DB yang bagus; kelas DB saya beberapa waktu yang lalu, dan mereka tidak datang dengan cepat ke pikiran. Tetapi jika item dijamin memiliki, katakanlah, kurang dari 10 item, Anda bisa memberikan setiap item bidang atribut1, dan bidang atribut2, dan seterusnya hingga atribut10. Ini akan menghilangkan kebutuhan Anda untuk tabel atribut item banyak-ke-banyak, dengan biaya membatasi jumlah atribut.

Melihat kembali itu, saya cukup yakin itu adalah desain yang mengerikan, tetapi itu berarti Anda dapat tetap dengan database relasional yang nyaman dan tidak harus pergi ke wilayah yang belum dipetakan. Terserah Anda untuk memutuskan apakah pertukaran itu sepadan.

Gregory Avery-Weir
sumber
Ini adalah desain yang mengerikan, tidak pernah melakukannya. Anda akan lebih baik tidak menggunakan database.
ZorbaTHut
-1

Nevermind memberikan jawaban yang baik, tapi saya ingin tahu, apakah Anda bahkan membutuhkan database untuk ini? Menyimpan semua data dalam file biasa dan memuatnya ke dalam program saat peluncuran sepertinya cara paling cerdas untuk melakukan ini.

Sunting:
Benar, dalam lingkungan yang didorong oleh permintaan kewarganegaraan, Anda sebaiknya menyimpan data dalam basis data. Tulis data Anda dalam file dan tulis sepotong kode untuk mengubahnya menjadi database dengan tipe Nevermind yang disarankan.

Bergantian jika jumlah objek tidak terlalu besar menyatakan lot secara harfiah dalam file kode mungkin metode tercepat.

aaaaaaaaaaaa
sumber
Err, saya sudah punya database yang digunakan & terintegrasi dengan sisa situs.
Kzqai