2010-02-23 28 views
6

Thông thường, khi tôi cần lưu trữ các thuộc tính hệ thống như thông tin quản trị, phiên bản, v.v., tôi sử dụng tệp phẳng (database.properties, init.properties, v.v.). Điều này có vẻ phổ biến trong các chương trình khác mà tôi thấy và sử dụng hàng ngày.Có ý tưởng tồi khi có bảng thuộc tính trong cơ sở dữ liệu không?

Đôi khi tệp phẳng không lý tưởng vì một số lý do. Triển khai một ứng dụng web cho nhiều khách hàng thường đi kèm với những hạn chế. Trong những trường hợp này, tôi sử dụng một bảng cơ sở dữ liệu để chứa thông tin. Ví dụ: giả sử tôi có một số dữ liệu quản trị mà tôi muốn lưu và có thể một số chi tiết cụ thể về môi trường của tôi. Tôi có thể làm điều gì đó như thế này:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT" 
2, 0, 1, "LICENCE", "88475", "INT" 
3, 0, 1, "TOP_PROJECT", "1", "INT" 
4, 0, 1, "SHOW_WELCOME", "F", "BOOL" 
5, 0, 1, "SMTP_AUTH", "SSH", "STRING" 
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL" 

Tôi nhận ra điều này phá vỡ gõ SQL và cho phép tôi để lưu trữ tất cả các loại của các loại như dây đàn. Đây là thực hành tốt hay tôi đã đi về điều này một cách sai lầm?

Nếu không, tôi nên lưu trữ loại thông tin này theo cách nào?

+1

miễn là bộ nhớ của nó dành cho một số thuộc tính hệ thống, v.v. Chỉ cần không có ý tưởng để lưu trữ ** tất cả ** dữ liệu của bạn như thế này! Xem tại đây để thảo luận, tại sao: http://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/ –

+0

cũng có thể là động lực cho câu hỏi này, tại sao tôi bị bỏ phiếu ở đây: http://stackoverflow.com/questions/2300356/using-a-single-row-configuration-table-in-sql-server-database-bad-idea/2300450#2300450 – Stephano

Trả lời

1

Tôi đã sử dụng một cấu trúc tương tự để lưu trữ dữ liệu thuộc tính và tôi nghĩ rằng miễn là bảng này vẫn còn tương đối nhỏ. Bảng thực thể-thuộc tính-giá trị (EAV) có thể tiêu thụ nhiều không gian hơn và thể hiện hiệu suất truy vấn chậm hơn so với bảng có cấu trúc cột truyền thống, nhưng đó không phải là vấn đề cho một tập hợp thuộc tính ứng dụng hợp lý.

+0

liên kết tốt đẹp. có vẻ như tôi có một số đọc sách vào buổi chiều muộn để làm. – Stephano

0

Điều này là tốt cho một lượng nhỏ dữ liệu được truy cập rất thường xuyên.

Có thể thực sự tốt hơn cho người dùng xem lược đồ để không thấy các thuộc tính ứng dụng riêng lẻ.

Điều này làm giảm các vấn đề với cập nhật lược đồ. (Các thuộc tính ứng dụng thường được thêm/xóa.)

Điều gì không phù hợp với số lượng lớn dữ liệu hoặc dữ liệu được truy cập thường xuyên, vì cơ sở dữ liệu hoạt động nhiều hơn trong mỗi lần truy xuất và nhiều không gian hơn , so với một giản đồ thông thường.

2

Tôi nghĩ rằng điều này là tốt nhưng bạn có thể muốn xem xét bộ nhớ đệm dữ liệu của bạn trong bộ nhớ khi bạn đọc nó để bạn không phải tiếp tục quay trở lại DB. Nếu bạn lưu trữ dữ liệu của mình, hãy lưu trữ dữ liệu ở bất cứ nơi nào sẽ làm cho bản cập nhật của bạn trở nên dễ dàng nhất. Ưu điểm của việc lưu trữ dữ liệu trong DB của bạn là việc duy trì hoặc tạo các giao diện để quản lý các thuộc tính đó dễ dàng hơn, đặc biệt khi bạn bắt đầu sử dụng môi trường phân tán cho ứng dụng của bạn.

+1

ý tưởng thú vị để lưu trữ thông tin. Tôi đã làm điều này trong quá khứ bằng cách lưu vào bộ nhớ đệm một số dữ liệu trên giao diện người dùng mà tôi cần có sẵn. – Stephano

Các vấn đề liên quan