Làm thế nào tôi nên đại diện cho một kiểu liệt kê trong cơ sở dữ liệu quan hệ?


12

Tôi đang làm việc để phát triển một cơ sở dữ liệu quan hệ theo dõi các giao dịch xảy ra trên thiết bị tôi đang làm việc cho công ty của mình. Có nhiều loại giao dịch khác nhau có thể xảy ra trên thiết bị, vì vậy chúng tôi có trường "trans_type" trong một trong các bảng ghi chính của chúng tôi. Nhóm của tôi đã quyết định biến loại của trường này thành một số nguyên và coi nó là một kiểu liệt kê. Trực giác của tôi nói với tôi rằng sẽ là một ý tưởng tốt hơn để biến trường này thành một chuỗi để dữ liệu cơ sở dữ liệu của chúng tôi dễ đọc và dễ sử dụng hơn. Đồng nghiệp của tôi dường như lo lắng rằng điều này sẽ gây ra nhiều rắc rối hơn đáng giá. Việc so sánh chuỗi đó quá tốn kém và khả năng lỗi chính tả là quá lớn.

Vì vậy, theo ý kiến ​​của bạn, khi xử lý một trường trong cơ sở dữ liệu quan hệ về cơ bản là một giá trị được liệt kê, đó là một quyết định thiết kế tốt hơn để biến trường này thành một số nguyên hay một chuỗi? Hoặc có một số thay thế khác mà tôi đã bỏ qua?

Lưu ý: các kiểu liệt kê rõ ràng không được hỗ trợ bởi cơ sở dữ liệu chúng tôi đang sử dụng. Và phần mềm chúng tôi đang phát triển sẽ giao diện với cơ sở dữ liệu này được viết bằng C ++.


Liệu nó tấn công bất cứ ai khác khi quá hạn chỉ để làm cho nó một định nghĩa loại được kiểm tra trong bảng tạo? Một cái gì đó như: CREATE TABLE hit (ip varchar (40), ip_group ENUM (0, "IPv4", 1, "IPv6")); Nó sẽ cho phép bạn kiểm tra = <và> bằng thứ tự hoặc chuỗi (ánh xạ tới thứ tự).
dlamblin

Câu trả lời:


26

Các kiểu liệt kê phải là một bảng riêng biệt trong cơ sở dữ liệu của bạn có số id và tên chuỗi và bất kỳ cột nào khác mà bạn có thể thấy hữu ích. Sau đó, mỗi loại tồn tại như một hàng trong bảng này. Sau đó, trong bảng của bạn, bạn đang ghi lại các giao dịch, trường "trans_Type" phải là khóa ngoại đối với khóa của bảng tham chiếu đó. Đây là một thực hành tiêu chuẩn trong chuẩn hóa cơ sở dữ liệu.

Bằng cách này, bạn đã lưu trữ một chuỗi tên chính thức, sử dụng so sánh số cho hiệu suất và có tính toàn vẹn tham chiếu rằng mọi giao dịch đều có loại hợp lệ.


1
Có và nếu bạn quyết định muốn thay đổi 'O' thành 'Mở', bạn chỉ phải thay đổi một hàng.
Daniel Kaplan

+1. một bảng int / chuỗi đơn giản là cách tốt nhất để biểu diễn các enum trong một db quan hệ.
mike30

Có lẽ, những khách truy cập tiếp theo đang tìm kiếm giải pháp Java thấy hữu ích
Jauhien 14/1/2015

2
Điều này. Đối với tín dụng bổ sung - nếu nhóm nhà phát triển đã xác định các số nguyên trong enum Java / C # hoặc một cái gì đó tương tự, bạn có thể viết một bài kiểm tra để kiểm tra xem định nghĩa enum mã có được chuyển hướng từ bảng tra cứu hay không. Luôn có một mối nguy hiểm là việc thêm một yếu tố ra khỏi chuỗi có thể đánh bật mọi thứ không đồng bộ và bạn không nhận ra cho đến khi một bản ghi dữ liệu trực tiếp có vẻ sai.
Julia Hayward

4

Một thực tế phổ biến là tạo một trans_typesbảng, và sau đó có bảng chính của bạn tham chiếu nó với khóa ngoại được đặt tên trans_type_id. Điều này đảm bảo rằng hồ sơ của bạn sẽ chỉ tham chiếu các loại liệt kê hợp lệ.

Thí dụ:

trans_type
----------
  Tôi
  Tên

giao dịch
------------
  Tôi
  chuyển đổi
  chi tiết
  trans_type_id (FK đến trans_type.id)

Dữ liệu mẫu:

trans_type

ID | TÊN
----------
1 | GỬI ĐI
2 | HỦY BỎ


giao dịch

ID | chuyển đổi | trans_type_id
---------------------------------
1 | 2012-12-31 | 1
2 | 2013-01-09 | 2

3

Nếu các giá trị được đưa vào cơ sở dữ liệu dưới dạng số nguyên, hãy lưu trữ chúng theo cách đó. Không cần phải đặt quá nhiều chuyển đổi thành chuỗi trong khi ghi vào cơ sở dữ liệu. Bạn luôn có thể liên quan đến bảng tra cứu với các giá trị chuỗi / văn bản (Chuẩn hóa hơn).

Điều này có thêm lợi thế là cập nhật giá trị chuỗi ở một vị trí thay vì chạy một số loại thói quen cập nhật. Thay vì 1 = 'Đỏ', nó có thể bằng 'Thực sự Đỏ'

Điều này không lý tưởng để báo cáo hiệu suất so với việc chỉ cần một bảng có giá trị chuỗi (Không chuẩn hóa). Một chỉ số trên lĩnh vực này sẽ làm cho hiệu suất đủ tốt.

Hầu hết RDBMS sẽ cho phép đủ mã lực. Mặc dù ý tưởng của bạn về việc có thể 'đọc' bảng ở dạng dữ liệu đơn giản, nhưng việc tham gia một bảng không phải là vấn đề lớn. Chỉ cần có thói quen sử dụng một khung nhìn hoặc một số đối tượng tương tự.


2

Tôi phải không đồng ý với các câu trả lời khác cho câu hỏi này ủng hộ cách tiếp cận bảng liệt kê riêng.

Tuy nhiên, tôi chắc chắn ủng hộ việc không lặp lại những gì đã được nói, vì vậy tôi sẽ chỉ đề cập đến câu trả lời được chấp nhận cho (ít nhiều) câu hỏi tương tự trên Stack Overflow: /programming//a/229919 / 114626


+1 cho câu trả lời được liên kết. Đối với câu hỏi này, câu trả lời được liên kết của bạn dường như là câu trả lời đúng. Nhưng tất nhiên, nếu người hỏi muốn linh hoạt trong các kiểu liệt kê thì một bảng tham chiếu sẽ tốt hơn nhiều.
Harke
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.