Có thực hành tốt để sử dụng bảng khác nhau cho chương trình kinh doanh khác nhau (nhưng tương tự) không?

Question

Có một câu hỏi rất giống: Modeling products with vastly different sets of needed-to-know information and linking them to lineitems? Nhưng tôi không thể tìm thấy câu trả lời giúp tôi;

Một người nào đó ở trên Q & Một điểm đến designing database to hold different metadata information, có câu trả lời được chấp nhận tuyệt vời, nhưng vì chức năng tìm kiếm rõ ràng là cần thiết trong chương trình của tôi, tôi không muốn hiệu suất bị xâm phạm.

---

Tôi là "kỹ thuật viên" sử dụng PHP + Oracle để theo dõi tiến trình bán hàng của công ty chúng tôi và tạo báo cáo. Quy trình làm việc của chúng tôi thường trông giống như sau:

1. Nhân viên tiếp thị cung cấp bộ dữ liệu đã chuẩn bị cho hệ thống của tôi;
2. Nhân viên tiền tuyến (bán hàng) đánh dấu tiến trình trên hệ thống của tôi;
   • Bất kỳ ai cũng có thể tìm kiếm kết quả trong hệ thống;
3. Tôi tạo báo cáo lại cho các nhân viên tiếp thị.

Vấn đề:

Nhiều cột của dữ liệu bộ đều giống nhau (hoặc có thể được coi là giống nhau), như thế này:

account|customer_name|gender|location|program_segment|... 

Nhưng nợ tiếp thị. như đưa ra những ý tưởng mới (và bỏ qua những ý tưởng hiện có), vì vậy mỗi "chương trình bán hàng (chiến dịch)" có thể có dữ liệu riêng của nó, ví dụ:

Đối với chương trình 1, chúng có thể chứa:

...|prev_coupon_code|last_usage_amount|... 

Đối với chương trình 2, tuy nhiên, chúng có thể chứa:

...|is_in_plan_1|is_in_plan_2|... 

Bạn đã có ý tưởng.

nỗ lực không thành công:

• Để giữ tất cả dữ liệu, tôi thường sử dụng "dài đủ" bảng mà có tất cả các thuộc tính có thể (cột), và để trống/tài sản không cần thiết NULL. Nhưng bây giờ tôi cảm thấy rằng nó sẽ không bao giờ "đủ dài", vì có quá nhiều "thuộc tính" và thậm chí nhiều hơn "điểm tập trung bán hàng": Tôi đã soạn thảo một bảng 41 cột cho một phiên bản mới của hệ thống và đột nhiên họ đề xuất một chương trình mới có thông tin không phù hợp.

• Ai đó đã đề xuất tôi tạo "cột giả" trong bảng và "nhớ" ý nghĩa khác của chúng trong lối vào. Điều này có thể làm việc cho một số kiểu dữ liệu, chẳng hạn như NUMBER(1) cho Y/N, DATE, v.v., nhưng khi nói về VARCHAR2, tôi không chắc chắn bao nhiêu trong số đó là đủ ... cộng với điều này làm cho bảng trông "bẩn".

Câu hỏi:

Thất vọng, tôi là bây giờ nghiêm túc xem xét sử dụng các bảng khác nhau cho các chương trình khác nhau, và sử dụng UNION khoản để tạo báo cáo lớn trong trường hợp họ đang hỏi "làm thế nào chúng ta bán này tháng/mùa/năm? "

Về mặt kỹ thuật, đây có phải là phương pháp hay không? Tôi có nên thực hiện nó?

---

Sửa # 1:

Để làm rõ, một "chương trình bán hàng" sẽ thường được chạy trong một vài tháng trước khi nó đã bị bỏ rơi, và sẽ có ít nhất một dữ liệu thiết lập mỗi tháng cho mỗi chương trình đang chạy.

Và có thể có nhiều chương trình đang chạy cùng một lúc.

Sửa # 2:

Những cột "Chương trình chỉ định" là số khác nhau: một chương trình có thể cần 10, trong khi người khác có thể chỉ cần 1.

Answer 1

Đây là một trong những tình huống không có câu trả lời đúng, chỉ là lựa chọn kludges.

Tôi xin phép sử dụng XMLType để giữ cấu trúc dữ liệu thoáng qua. XML cho chúng ta khả năng có các lược đồ được định nghĩa cho mỗi kế hoạch, nhưng việc sử dụng một XMLType sẽ làm giảm bớt sự cần thiết phải thay đổi cơ sở dữ liệu. Chúng tôi có thể lập chỉ mục các truy vấn XPath để hiệu năng vẫn có thể tốt. Find out more.

Một vấn đề là viết các truy vấn đối với XML là một chút của một pfaff, nhưng tôi nghĩ rằng các truy vấn khó xử sẽ là một vấn đề cho bất kỳ apporach nào bạn thực hiện.

Answer 2

Nếu bạn đi xuống bảng khác nhau đường dẫn bạn sẽ mãi thay đổi mã để đáp ứng các cột thay đổi, v.v.

Một tùy chọn sẽ có thêm 2 cột 'campaign_name', 'campaign_value' và đặt tên cột họ gửi cho bạn trong cột NAME và giá trị trong cột giá trị.

Vì vậy,

account|customer_name|.....|campaign_name|campaign_value 
'ACC001'|'Frank Burns'|........|'prev_coupon_code'|[value of prev_coupon_code 

và sau đó trong ví dụ thứ 2 của bạn:

account|customer_name|.....|campaign_name|campaign_value 
'ACC001'|'Frank Burns'|........|'is_in_plan_1'|[value of is_in_plan_1 

Update - vâng, điều này sẽ liên quan đến việc thay đổi hạt của bảng, do đó bạn sẽ thêm một tập hợp các dữ liệu cho mỗi của các chiến dịch. Việc nhập sẽ hơi khác một chút khi bạn UNION các bản ghi cho từng tên cột xuất hiện trên đó và báo cáo sẽ cần tính đến sự thay đổi hạt.

Nghe có vẻ như hoàn toàn lãng phí dung lượng, nhưng nếu đây là các trang tính Excel thì hiệu suất sẽ không thành vấn đề. Nếu nó đã làm bạn sẽ cần phải chia bảng vào - chiến dịch, tài khoản, accounts_campaigns

Answer 3

Bạn có thể hoặc không thể nhận thức được rằng nó có thể chỉ mục các nội dung của một LOB nhân vật trong Oracle. Bạn có thể tra cứu Oracle Intermedia/multimedia (phụ thuộc vào phiên bản của bạn) và nói chuyện với DBA của bạn để xem nó có sẵn cho bạn không.

Điều này có thể tạo cấu trúc chung cho các mục dữ liệu chung - ví dụ: chiến dịch, ngày bắt đầu, end_date, & c nhưng sau đó đổ tệp dữ liệu/csml/csv của bạn vào trường CLOB.

Việc lập chỉ mục văn bản thuần tuý không khó bằng âm thanh đầu tiên và thực sự rất dễ thương.

Answer 4

Trong công việc hiện tại của tôi, tôi đã sử dụng thành công hệ thống sau trong 2 năm.

Bạn có một bảng chính, giả sử 'báo cáo', bao gồm các cột chung cho tất cả các loại báo cáo.

id - primary, auto_increment.

tên - tên báo cáo.

Sau đó, đối với mỗi báo cáo cụ thể, bạn có một bảng khác, được gọi là "report_marketing". Ở đó bạn có cột report_id, đó là khóa ngoài cho bảng chính đầu tiên. Và tại đây bạn thêm tất cả các cột cụ thể cho báo cáo cụ thể này.

Để nhận kết quả, bạn chỉ cần sử dụng LEFT JOIN.

Nếu một số báo cáo chia sẻ một số cột từ 2 bảng trở lên, bạn luôn có thể tham gia nhiều hơn một cột.

Dưới đây là ví dụ về truy vấn mà bạn có thể có:

SELECT report.name, report_marketing.ammount FROM report WHERE report.type = 'M' 
    LEFT JOIN report_marketing ON report_marketing.report_id = report.id;