Giáo sư bảo chúng tôi lưu trữ các đối tượng Java được tuần tự hóa dưới dạng các đốm thay vì xác định các bảng quan hệ

Thay vì thực sự xác định một bảng với các thuộc tính chính xác, giáo sư của tôi nói với chúng tôi rằng chúng ta có thể ánh xạ các đối tượng thành các id như thế này:

id (int)  |   Serialized Object (blob)
   1               10010110110

Tôi có thể thấy rất nhiều vấn đề với điều này; dự phòng dữ liệu, phải theo dõi id riêng, phải kéo toàn bộ bảng vào bộ nhớ để tìm kiếm bất cứ thứ gì và ** nếu tôi muốn thay đổi mô hình của mình trong mã Java, tôi sẽ không còn có thể khử lưu trữ blob được lưu trữ trong cơ sở dữ liệu vào mô hình đó.

Hoặc là tôi mãi mãi bị mắc kẹt với mô hình đó hoặc tôi phải làm một số thứ thực sự xấu xí khác để thay đổi mô hình của mình. ** Toàn bộ điều này có vẻ như là hình thức xấu đối với tôi. Tôi có hợp lý khi không đồng ý với giáo sư của mình không? Có một số lợi ích để làm điều này mà tôi đã không nghĩ đến? Nếu tôi đúng, tôi có nên nói gì với giáo sư của mình về điều này không? Anh ấy đã giảng điều này cho cả lớp tôi và thậm chí nói rằng anh ấy đã xây dựng các dự án theo cách đó. Một ý kiến ​​thứ hai sẽ là tuyệt vời.

Khóa học có tên là Thiết kế phần mềm .

Giáo sư của tôi đã không nói rằng đây là cách tốt nhất, nhưng ông đã nói rằng đó là một cách thay thế hợp pháp để xác định các bảng quan hệ.

Mô hình không năng động theo bất kỳ cách nào.

1. Bản thân nó không phải là một điều xấu - tất cả. Tranh luận về "cái nào tốt hơn" mà không có ngữ cảnh phù hợp (= yêu cầu chính xác) là một bài tập vô ích.

2. Phần in đậm là sai. Bạn có thể dễ dàng mở rộng các đối tượng đã được tuần tự hóa để thêm các trường mới và đạt được khả năng tương thích nhị phân đầy đủ với các đối tượng cũ hơn. Bạn cũng có thể chỉ cần tạo các lớp mới thay vì thay đổi các lớp ban đầu.

Thảo luận của bạn với giáo sư nên tập trung vào ưu và nhược điểm của "quan hệ" so với "lưu trữ giá trị khóa" trong các tình huống khác nhau, chứ không phải là "sự tốt hơn" trừu tượng. Hoặc bạn cũng có thể có một cuộc thảo luận về việc Giáng sinh có tốt hơn Lễ Tạ ơn hay không.

- một chỉnh sửa, sau khi đọc câu trả lời khác.

Một trong những câu trả lời khác đi xa đến mức nói rằng "thật khó để tưởng tượng một trường hợp ưu điểm vượt trội hơn".

Bởi vì toàn bộ cuộc thảo luận phải là về các vấn đề cụ thể (nếu không chúng tôi thậm chí không thể định nghĩa "tốt hơn" và "tệ hơn"), hãy để tôi đưa ra một ví dụ cụ thể. Nó hoàn toàn được tạo ra, nhưng tôi đã cố gắng đưa ra càng nhiều chi tiết càng tốt.

Hãy tưởng tượng bạn có một trang web chơi trò chơi trực tuyến, với cơ sở dữ liệu lưu trữ số liệu thống kê về người chơi trong các trò chơi trực tuyến khác nhau (được chơi trên trình duyệt, được viết bằng GWT và được biên dịch chéo thành javascript). Một số trò chơi mang tính chiến lược, một số là game hành động, một số là platformer. Cơ sở dữ liệu là quan hệ và lưu trữ người chơi và lịch sử của các vở kịch và điểm số.

Một ngày nào đó bạn nhận được một yêu cầu bổ sung: cho phép người chơi lưu trạng thái trò chơi vào đám mây, trong trò chơi, để họ có thể khởi động lại trò chơi sau đó, cùng một lúc. Không cần phải nói, lý do duy nhất để lưu trữ trạng thái tạm thời này là quay trở lại trò chơi, chính trạng thái đó sẽ không bao giờ bị thâm nhập.

Bây giờ bạn có hai lựa chọn cơ bản:

• vì các trò chơi được viết bằng Java, bạn có thể dễ dàng lấy mô hình, gửi nó đến máy chủ, tuần tự hóa nó trong một dòng mã và lưu trữ dưới dạng một đốm màu. Bảng sẽ được gọi là "yet_games" và nó sẽ có các khóa ngoại cho người chơi, v.v. Từ quan điểm của cơ sở dữ liệu, "trò chơi lưu" là một đốm màu mờ đục, không thể chia cắt.

• bạn có thể tạo một mô hình quan hệ riêng cho mỗi trong số 100 trò chơi của mình (đây sẽ là hàng chục bảng cho mỗi trò chơi). Ví dụ, đối với pacman, bạn sẽ phải có một bảng lưu trữ các vị trí của tất cả các viên, phần thưởng, vị trí và trạng thái hiện tại của ma. Nếu ai đó, một ngày nào đó, sửa đổi trò chơi, thậm chí một chút, bạn sẽ phải cập nhật mô hình quan hệ. Ngoài ra, đối với mỗi loại trò chơi, bạn sẽ phải triển khai logic để viết mô hình Java vào cơ sở dữ liệu và đọc lại nó.

Câu trả lời của Justin Cave nói rằng, bạn nên đi với tùy chọn thứ hai. Tôi nghĩ rằng đây sẽ là một sai lầm rất lớn.

Ngoài ra, tôi có linh cảm rằng nhận thức của Justin Cave là những gì tôi trình bày ở trên là một trường hợp "cạnh" hoặc "hiếm". Tôi tin rằng trừ khi anh ta có thể trình bày một số loại dữ liệu cứng (dựa trên mẫu đại diện của tất cả các dự án CNTT trên thế giới, không chỉ là, ứng dụng doanh nghiệp ở Mỹ), tôi sẽ coi ý kiến ​​đó là một trường hợp kinh điển của dự báo thiên vị.

Trên thực tế, vấn đề của các đối tượng Java được tuần tự hóa trong cơ sở dữ liệu quan hệ sâu hơn nhiều so với vẻ ngoài của nó. Nó chạm vào chính cốt lõi của 1NF, cụ thể là miền của một thuộc tính là gì? . Nếu bạn thực sự quan tâm đến chủ đề này, thì có một bài viết tuyệt vời của Ngày của CJ, trong Ngày của anh ấy trên Cơ sở dữ liệu: Bài viết 2000-2006 .

Mọi người có thể (và làm) giao thành công các dự án thực hiện loại việc này không? Thật không may, vâng, họ làm như vậy thường xuyên hợp lý.

Đây có phải là một cách tiếp cận tốt? Không, không phải vậy. Về cơ bản, bạn đang lấy cơ sở dữ liệu tương đối đắt tiền của mình và biến nó thành một hệ thống tệp tương đối chậm. Nếu bạn thực sự muốn xây dựng một hệ thống lưu trạng thái của nó bằng cách tuần tự hóa và khử tuần tự hóa các đối tượng, bạn cũng có thể sử dụng một hệ thống tệp thay vì sử dụng cơ sở dữ liệu.

Nếu bạn xây dựng các hệ thống lưu trữ dữ liệu bằng cách tuần tự hóa các đối tượng vào cơ sở dữ liệu, bạn sẽ không kết bạn với DBA của mình. Cuối cùng bạn sẽ lưu trữ dữ liệu dư thừa. Bạn sẽ kết thúc với dữ liệu không nhất quán khủng khiếp-- bất cứ khi nào dữ liệu chia sẻ được cập nhật, một số đối tượng sẽ kết thúc với các giá trị mới và một số đối tượng sẽ kết thúc với các giá trị cũ. Bạn sẽ không thể thực hiện bất kỳ loại báo cáo nào về dữ liệu - mọi thứ mà bất kỳ ai muốn làm với dữ liệu sẽ yêu cầu ai đó viết mã bổ sung. Đó là một vấn đề lớn, rất lớn ở hầu hết các doanh nghiệp vì họ muốn làm những việc như trích xuất dữ liệu từ một hệ thống để tải vào hệ thống khác hoặc để có một hệ thống báo cáo có thể gửi báo cáo từ nhiều ứng dụng mặt trước. Ngoài ra, như bạn chỉ ra, bạn sẽ liên tục phải xử lý các vấn đề khi bạn

Có những lợi thế cho phương pháp này? Tôi đoán bạn có thể lập luận rằng việc triển khai phiên bản đầu tiên của ứng dụng khá dễ dàng. Và nó cho phép nhà phát triển hoàn toàn bỏ qua mọi thứ liên quan đến tương tác đúng với cơ sở dữ liệu. Tôi khó có thể tưởng tượng nhiều trường hợp những lợi thế này vượt trội hơn nhiều nhược điểm của phương pháp này.

Về cách bạn nên đối phó với giáo sư cụ thể này, đó là một vấn đề riêng biệt (và một vấn đề có lẽ nằm ngoài phạm vi của diễn đàn này). Nếu giáo sư của bạn đang tích cực phát triển các dự án trong thế giới thực, có lẽ anh ta sẽ không dễ chấp nhận bất kỳ tranh luận nào từ một sinh viên rằng cách tiếp cận của anh ta sai về cơ bản (ngay cả khi cách tiếp cận thực sự sai về cơ bản). Bạn có thể được phục vụ tốt hơn khi thực hiện dự án của mình theo cách giáo sư muốn và học cách thích hợp để tự lưu dữ liệu (hoặc trong một khóa học khác).

Có những tình huống mà kiểu thiết kế này hợp lý, mà không cần bạn mô tả dự án của bạn là gì và nó được sử dụng như thế nào, thật khó để nói liệu điều này có phù hợp hay không.

DBA của bạn có thể ghét bạn nếu bạn lưu trữ BLOB, nhưng trong nhiều trường hợp, cách duy nhất khác là biến các bảng thành Entity-property-value, điều này càng khiến DBA ghét hơn. Một cách khác là sử dụng cơ sở dữ liệu không liên quan, thường là cơ sở dữ liệu dựa trên đối tượng hoặc từ điển hoặc cơ sở dữ liệu hướng tài liệu, mà một số DBA, đặc biệt là những người chỉ biết quan hệ, sẽ ghét hơn cả đam mê. Cơ sở dữ liệu phi quan hệ có vấn đề riêng để giải quyết, chắc chắn có thể xảy ra trường hợp sử dụng cơ sở dữ liệu đối tượng để lưu trữ các đối tượng có thể phơi bày các vấn đề khác mà bạn có thể giải quyết dễ dàng trong các hệ thống quan hệ.

Có một số lợi ích để làm điều này mà tôi đã không nghĩ đến?

Lưu trữ đối tượng được tuần tự hóa có nghĩa là bạn có thể lưu trữ dữ liệu schemaless (lưu ý rằng mặc dù có tên, schemaless thường không có nghĩa là thực sự không có lược đồ nào cả, mà chỉ có lược đồ ngầm). Có nhiều miền vấn đề mà bạn không thể xác định lược đồ trước thời gian phát triển và theo thiết kế cơ sở dữ liệu quan hệ truyền thống có nghĩa là bạn phải thay đổi lược đồ của cơ sở dữ liệu mỗi tuần hoặc bạn kết thúc với một bảng có 80% các cột không được sử dụng 80% thời gian hoặc hàng trăm bảng khác nhau để lưu trữ những gì thực sự là cùng một dữ liệu, không có cột nào cho thấy một thiết kế tốt. Căn nguyên của vấn đề này thường là do bạn buộc phải phù hợp với một miền vấn đề không liên quan vào cơ sở dữ liệu quan hệ.

Tất nhiên, có rất nhiều dự án mà mọi người nghĩ rằng họ cần sử dụng EAV, schemaless hoặc blob store mà hóa ra không cần thiết gây ra những gì có thể là một nỗi đau có thể tránh được. Bạn chắc chắn nên thảo luận với giáo sư của bạn về lý luận của ông là gì và đưa ra lập luận của riêng bạn; lắng nghe những tranh luận, và hãy chuẩn bị rằng cuối cùng bạn có thể đồng ý với anh ta, hoặc không, có thể anh ta đã sai.

Tôi đã làm điều này trước đây - đó là một kỹ thuật hữu ích trong một số trường hợp nhất định tuy nhiên phụ thuộc vào định dạng tuần tự hóa được sử dụng. Nếu tôi làm điều này, tôi chắc chắn rằng tôi sử dụng định dạng tuần tự hóa cho phép tôi hủy nối tiếp các phiên bản cũ hơn của mô hình của mình (ví dụ: XML).

Tôi thường sử dụng điều này trong các tình huống trong đó định dạng dữ liệu sẽ dẫn đến một mô hình quan hệ phức tạp không có lợi thế (ví dụ: khi các yêu cầu nghiệp vụ không yêu cầu bất kỳ bộ lọc nào, v.v.) và tôi đã sử dụng cơ sở dữ liệu (cho dữ liệu quan hệ khác). Một trường hợp như vậy là một ứng dụng có truy vấn người dùng - mô hình quan hệ có một số bảng để lưu trữ những thứ như điều kiện, điều kiện lồng nhau (OR / AND vv ...), các tùy chọn sắp xếp, v.v ... Nó khá phức tạp và vì vậy khi chúng tôi cần thêm một tính năng mới yêu cầu thay đổi cơ sở dữ liệu Tôi đã thay thế toàn bộ bằng một bảng truy vấn duy nhất bằng một blob tuần tự đại diện cho tất cả các tùy chọn khác.

Một trường hợp khác là một hệ thống xử lý nhiều "công việc" khác nhau. Có một số loại công việc khác nhau và mỗi công việc có các tham số khác nhau, không có yêu cầu nghiệp vụ để có thể tìm kiếm / bộ lọc công việc dựa trên các tham số đó. Lưu trữ điều này như một cơ sở dữ liệu quan hệ sẽ cần ít nhất 1 bảng mới cho mỗi loại công việc, khiến việc thêm các loại công việc mới trở nên khó khăn. Thay vào đó, các tham số được lưu trữ dưới dạng blob trong cơ sở dữ liệu - mỗi loại công việc chịu trách nhiệm tuần tự hóa và khử tuần tự các tham số của chính nó.

Không thường xuyên bạn sẽ gặp các tình huống như thế này, tuy nhiên thỉnh thoảng tình huống như trên sẽ xuất hiện khi việc xê-ri hóa dữ liệu blob giúp bạn tiết kiệm công sức, giúp ứng dụng của bạn dễ bảo trì hơn và không có nhược điểm thực sự.

Justin Cave là chính xác rằng điều này có thể dẫn đến dữ liệu dư thừa, nhưng điều này thực sự phụ thuộc vào cách bạn thiết kế cơ sở dữ liệu của bạn.

Cách tiếp cận nối tiếp toàn bộ một đối tượng vào một đốm màu không quá đáng như hầu hết mọi người ở đây nghĩ. Trên thực tế, đối với một số ứng dụng, đây có thể là thiết kế tốt nhất bạn có thể làm, như tôi đã giải thích ở đây: /programming//a/12644223/1121352 .

Thật vậy, việc tuần tự hóa một đối tượng dẫn đến ít nhất hai lợi ích:

1- Giảm sự không phù hợp trở kháng : một số loại Java không có sẵn trong SQL, đặc biệt nếu bạn sử dụng nhiều lớp và loại tùy chỉnh, do đó chuyển đổi qua lại từ các đối tượng Java sang SQL có thể là một rắc rối lớn và thậm chí dẫn đến sự mơ hồ.

2- Linh hoạt hơn trong lược đồ của bạn . Thật vậy, các lược đồ quan hệ thực sự tuyệt vời cho dữ liệu có cùng cấu trúc, nhưng nếu một số đối tượng của bạn trong một lớp có thể có các thuộc tính khác nhau tùy thuộc vào các điều kiện trong thời gian chạy, các lược đồ quan hệ có thể cản trở đáng kể luồng công việc của bạn.

Vì vậy, chắc chắn có những lợi ích cho cách tiếp cận này (ít nhất là hai, nhưng chắc chắn là những cách khác mà tôi không trích dẫn), nhưng tất nhiên chi phí rất lớn phải trả là bạn mất gần như tất cả các lợi ích của lược đồ quan hệ.

Tuy nhiên, bạn có thể tận dụng tốt nhất cả hai thế giới nếu bạn thiết kế cẩn thận cơ sở dữ liệu của mình: bạn vẫn có thể đặt lược đồ quan hệ (nghĩa là: các cột khóa duy nhất) bằng cách sử dụng các thuộc tính duy nhất cho từng đối tượng và sau đó lưu trữ đối tượng trong blob . Theo cách này, bạn vẫn có thể đảm bảo truy xuất nhanh đối tượng của mình với một số định danh duy nhất được xác định bởi các thuộc tính của đối tượng, đồng thời giảm sự dư thừa, trong khi bạn hủy bỏ sự không khớp trở kháng và giữ tính linh hoạt hoàn toàn của các đối tượng Java.

Một lưu ý phụ, có một vài nỗ lực của một số nhà sản xuất DB để trộn các mô hình đối tượng và đối tượng lại với nhau, như kiểu dữ liệu JSON trong PostQuery và PostgreQuery để bạn có thể xử lý trực tiếp JSON giống như bất kỳ cột quan hệ nào, và cả SQL3 và OQL (Đối tượng Ngôn ngữ truy vấn) để thêm (giới hạn) các đối tượng hỗ trợ vào SQL.

Cuối cùng, tất cả chỉ là vấn đề thiết kế và thỏa hiệp giữa mô hình quan hệ và mô hình đối tượng.

/ EDIT sau khi đọc bình luận: tất nhiên, nếu dữ liệu của bạn phải có thể tìm kiếm được ("có thể truy vấn"), bạn KHÔNG nên lưu trữ dữ liệu của mình dưới dạng blob. Nhưng nếu một số phần dữ liệu của bạn không có nghĩa là có thể tìm kiếm được , mà là một loại dữ liệu meta nào đó, thì việc lưu trữ phần dữ liệu này dưới dạng đối tượng trong một blob có thể là một giải pháp tốt, đặc biệt nếu dữ liệu meta này có cấu trúc linh hoạt và có thể thay đổi từ đối tượng này sang đối tượng khác.

Hãy cho một ví dụ thực tế về thời điểm tôi đã làm điều này trong quá khứ.

Chúng tôi có một cơ sở dữ liệu chứa tất cả dữ liệu cho một ứng dụng đa người dùng; cơ sở dữ liệu cũng có một bảng người dùng với quyền truy cập của họ. Tất cả các dữ liệu này được chuẩn hóa như mong đợi.

Sau đó, chúng tôi có một yêu cầu rằng ứng dụng ghi nhớ những cửa sổ mà người dùng đã mở và những gì họ đang làm, để nó có thể khôi phục trạng thái khi người dùng bắt đầu làm việc vào sáng hôm sau.

• Thứ nhất, nếu điều này đôi khi thất bại, nó không phải là xấc láo

  • Ví dụ: nếu lần đầu tiên ai đó sử dụng phiên bản mới của ứng dụng, nó sẽ quên các cửa sổ họ đã mở, vậy thì ra sao

• Do đó, có một dự phòng 100% nếu các đối tượng thay đổi, và vì vậy chúng tôi không thể đọc được khối.

• Chúng tôi đã có một cơ sở dữ liệu tập trung với kiểm soát truy cập, sao lưu, v.v.
• Chi phí lưu trữ dữ liệu trong các tệp cao, vì các tệp sẽ phải được đặt trên một số loại máy chủ tệp mà tất cả các máy người dùng có quyền truy cập hoặc API sẽ phải được ghi để đọc các tệp này.

Một lần khác , chúng tôi đã có một ứng dụng thực hiện nhiều phép tính trong thời gian dài và người dùng mong muốn có thể khởi động lại các phép tính từ điểm tốt nhất cuối cùng nếu có sự cố cắt điện, v.v. các ứng dụng có thể được dự kiến ​​sẽ khởi động lại các tính toán và vì có rất nhiều đối tượng cần lưu, nên việc chuẩn hóa dữ liệu sẽ rất tốn kém.

Do cơ sở dữ liệu đã được sử dụng và được sử dụng cho dữ liệu ứng dụng chuẩn hóa được xác định rõ và không có lý do thực sự nào để không sử dụng nó để lưu trữ các blog, chúng tôi đã sử dụng tùy chọn hợp lý và nhanh chóng.

Một yếu tố rất quan trọng: Tuần tự hóa Java (một công việc được kích hoạt bằng cách triển khai Serializable) là một định dạng rất xấu, vì vậy bạn không nên thực sự sử dụng nó để lưu trữ đối tượng vĩnh viễn.

Những hạn chế của việc tuần tự hóa java bao gồm:

• Dữ liệu không thực sự có thể đọc được từ các ngôn ngữ khác.
• Không dễ để duy trì khả năng tương thích về phía trước của các đối tượng được tuần tự hóa, đó là: nếu bạn thêm (hoặc loại bỏ) các trường vào lớp thì không dễ để đọc các đối tượng được tạo bởi phiên bản trước của lớp.
• Nó không phải là nhanh (nhưng số dặm của bạn có thể thay đổi)

Vì vậy, nếu bạn sử dụng bất kỳ định dạng tuần tự hóa nào khác, bạn sẽ có được một cửa hàng Key-Value đẹp, nếu bạn sử dụng tuần tự hóa java, bạn sẽ gặp rắc rối.

Đây là một chủ đề thú vị với một số câu trả lời cũng nghĩ ra. Không phải đối thoại với tất cả ý nghĩa của việc lưu trữ và truy xuất các đối tượng nối tiếp Tôi nghĩ rằng sẽ rất thú vị khi cung cấp câu trả lời tôi có thể đưa ra cho nhóm DBA hoặc nhóm phát triển:

Chìa khóa là đáp ứng các yêu cầu hiện tại và tương lai, và giữ cho giải pháp đơn giản nhất có thể để giảm thiểu công việc hỗ trợ trong tương lai. Cả hai yêu cầu chức năng và yêu cầu phi chức năng (ví dụ: cơ sở hạ tầng và cơ sở dữ liệu) phải được đáp ứng. Hãy nhớ quy tắc 80/20. Hiểu tầm quan trọng của Ứng dụng đối với doanh nghiệp và nỗ lực phát triển nào là phù hợp.

Đừng bị treo trên không gian cơ sở dữ liệu, tốc độ và bộ nhớ nếu chúng không có vấn đề.

Nếu một DBMS nằm trong danh sách được phê duyệt của bạn, bạn có thể sử dụng nó trong một giải pháp miễn là chi phí phù hợp. Không có vấn đề gì khi sử dụng Cơ sở dữ liệu quan hệ để lưu trữ các Blobs đơn giản, đặc biệt nếu điều này đơn giản hóa mọi thứ.

Nếu giải pháp là một nguyên mẫu hoặc giai đoạn đầu / phiên bản thậm chí còn căng thẳng hơn để giữ cho mọi thứ đơn giản. Bạn luôn có thể mở rộng lược đồ dữ liệu sau này miễn là bạn có kế hoạch cho nó.

Hãy nhớ rằng cơ sở dữ liệu quan hệ không thực thi tính toàn vẹn hoặc tính nhất quán trừ khi lược đồ bao gồm một khu vực kinh doanh khép kín và các quy tắc kinh doanh nghiêm ngặt. (ví dụ: giải pháp cho Câu hỏi đối tượng được tuần tự hóa có thể xem xét kho lưu trữ kiểu từ điển / bản thể để thực thi các quy tắc).

Đáng xem xét rằng tất cả các cơ sở dữ liệu quan hệ không sử dụng các lược đồ cơ sở dữ liệu quan hệ thuần túy (ví dụ: sao, không gian, không liên quan ..), các ứng dụng cũng có thể sử dụng cơ sở dữ liệu quan hệ làm cửa hàng không liên quan, như trong câu hỏi. Nhiều cơ sở dữ liệu kinh doanh cốt lõi hoạt động theo cách này.