Cần một mẹo về thiết kế db MySQL đơn giản

Tại sao bạn có thuộc tính attribute bảng ?

Thuộc tính là cột, không phải bảng.

Liên kết trang web không cho chúng tôi biết điều gì.

Toàn bộ ý tưởng của cơ sở dữ liệu là bạn kết hợp nhiều bảng nhỏ, theo yêu cầu, cho mỗi truy vấn, vì vậy bạn cần phải làm quen với điều đó. Chắc chắn, nó cung cấp cho bạn một lưới, nhưng ngắn và ngọt ngào, không có Null. Những gì bạn đang cố gắng làm là tránh các bảng; chỉ với một lưới lớn chứa đầy Null.

(ảnh cắt)

Không đặt tiền tố tên thuộc tính của bạn (tên cột) với tên bảng, điều đó là thừa. Điều này sẽ trở nên rõ ràng với bạn khi bạn bắt đầu viết SQL sử dụng nhiều bảng:sau đó bạn có thể sử dụng tên bảng hoặc bí danh để đặt tiền tố cho bất kỳ tên cột nào không rõ ràng.

Ngoại lệ là PK, được hiển thị đầy đủ và được sử dụng ở dạng đó cho dù nó là FK.

Duyệt qua trang web và đọc một số câu hỏi SQL.

Sau khi làm điều đó, sau này, bạn có thể nghĩ xem bạn có muốn strength không và defense là các thuộc tính (cột) của type; hay không. Vân vân.

Phản hồi nhận xét ngày 30 tháng 11 ngày 10 tháng 11

.
Tuyệt vời, bạn hiểu dữ liệu của mình. Đúng. Bây giờ tôi hiểu tại sao bạn có một bảng Thuộc tính.

1. Hãy chắc chắn rằng 10 ví dụ đó là đại diện, tôi đang xem xét chúng kỹ lưỡng.

   • Loại:Tên đá quý:Mặt dây chuyền Emberspark ... Hoặc, có phải là một loại NeckMis Linh tinh?
   • Unique có phải là ItemType thực sự không? Tôi nghĩ là không
   • Action.Display "Vui lòng quay lại Người tổ chức phần"
   • Các thuộc tính cho AttackPower ở đâu và HitRating ?
     .

2. Có bao nhiêu loại mặt hàng khác nhau (trong số 35.000), ala ví dụ Cụm sản phẩm của tôi. Một cách khác để nêu câu hỏi đó là, có bao nhiêu biến thể. Ý tôi là, có ý nghĩa, không phải 3500 Mục ÷ 8 Thuộc tính?

3. Item_attributes có thay đổi mà không bản phát hành s / w (ví dụ:một Inner Strength mới thuộc tính) ?

4. Mỗi mặt hàng, thuộc tính nào đang lặp lại (nhiều hơn một); cho đến nay tôi chỉ thấy Hành động?

5. Nó là một trò chơi, vì vậy bạn cần một db chặt chẽ và rất nhanh, có thể cư trú đầy đủ bộ nhớ, phải không. Không có Nulls. Không có VAR Bất cứ điều gì. Kiểu dữ liệu ngắn nhất. Không bao giờ trùng lặp bất cứ điều gì (không lặp lại chính mình). Bạn có hài lòng với bit (boolean) và vectơ không?

6. Bạn có cần dễ dàng dịch các regex đó sang SQL hay bạn hài lòng với một khẩu hiệu nghiêm túc cho mỗi câu lệnh (ví dụ:một khi bạn làm cho chúng hoạt động trong SQL, chúng khá ổn định và sau đó bạn không làm phiền nó, trừ khi bạn tìm thấy lỗi ) (không mỉa mai, câu hỏi nghiêm túc)?

   6.1 Hoặc có thể theo cách khác:db là ổ đĩa; bạn tải nó vào bộ nhớ một lần; bạn chạy regexes trên đó trong khi chơi trò chơi; thỉnh thoảng ghi vào đĩa. Do đó không cần phải dịch các regexes sang SQL?

Đây là Mô hình Dữ liệu về nơi tôi đang hướng tới, điều này không chắc chắn chút nào; nó sẽ được điều chỉnh bởi câu trả lời của bạn. Để rõ ràng:

• Biểu mẫu thông thường thứ sáu là Hàng bao gồm Khóa chính và tối đa là một Thuộc tính.

• Tôi đã rút ra (6.1) không phải (6), bởi vì dữ liệu của bạn củng cố niềm tin của tôi rằng bạn cần một cơ sở dữ liệu quan hệ 6NF thuần túy

• Mô hình dữ liệu cụm sản phẩm của tôi , ví dụ tốt hơn EAV, là 6NF, sau đó được Chuẩn hóa lại (Không theo nghĩa Biểu mẫu Thông thường) bởi DataType, để giảm không có bảng nào mà bạn đã thấy. (Những người sử dụng EAV thường chọn một hoặc một vài bảng khổng lồ.)

• Đây là 5NF thẳng, chỉ có 2 bàn bên phải trong 6NF.

Liên kết đến Mô hình dữ liệu trò chơi

Liên kết tới IDEF1X Notation dành cho những người không quen với Tiêu chuẩn mô hình quan hệ.

Phản hồi để chỉnh sửa # 2 05 ngày 10 tháng 12

1.1. Được rồi, đã sửa.

1.2. Sau đó IsUnique là một Indicator (boolean) cho Item.

1.3. Hoạt động. Tôi hiểu. Vậy bạn sẽ lưu trữ nó ở đâu?

1.4. Cổ vật có nghĩa là vật phẩm đó nằm trong cả hai danh mục của Neck và Misc . Điều đó có nghĩa là hai Item.Name=Emberspark Pendant riêng biệt , mỗi loại có một Danh mục khác nhau.

.
2. và 5. Vì vậy, bạn cần db thường trú bộ nhớ nhanh nhanh. Đó là lý do tại sao tôi đang cố gắng giúp bạn vượt qua giới hạn, rời khỏi GridLand, trở thành RelationalLand.
.
3. Ok, chúng tôi ở lại với Biểu mẫu thông thường thứ năm, không cần 6NF hoặc Cụm sản phẩm (các bảng trên mỗi Loại dữ liệu). Làm dịu Values đều là số nguyên.
.
4. Tôi có thể xem thêm:Level , RequiredLevel , IsUnique , BindsPickedUp , BindsEquipped .
.
5. Bit là boolean {0 | 1}. Vectơ là bắt buộc cho các phép chiếu (Quan hệ). Chúng tôi sẽ tìm hiểu chúng sau.
.
6. Ok, bạn đã giải thích, Bạn không dịch cụm từ thông dụng sang SQL. (Slog có nghĩa là lao động nặng nhọc) ..
7. Category.ParentId là gì? Gia phả ? Điều đó chưa từng xuất hiện trước đây.
.
8. Attribute.GeneratedId?

Vui lòng đánh giá Mô hình Dữ liệu (Đã cập nhật). Tôi có một vài cột khác, ngoài những gì bạn có trong của bạn. Nếu có bất kỳ điều gì bạn không hiểu trong Mô hình Dữ liệu, hãy đặt một câu hỏi cụ thể. Bạn đã đọc tài liệu Ký hiệu, phải không?

Tôi có Action dưới dạng một bảng, với ItemAction giữ Values :
Equip: increase attack power by 28 là Action.Name =Increase attack power by và ItemAction.Value =28.