Sử dụng XML làm lưu trữ dữ liệu [đã đóng]

Tôi đã suy nghĩ về định dạng XML và trích dẫn sau:

XML XML không phải là một cơ sở dữ liệu. Nó không bao giờ có nghĩa là một cơ sở dữ liệu. Nó sẽ không bao giờ là một cơ sở dữ liệu. Cơ sở dữ liệu quan hệ là công nghệ đã được chứng minh với hơn 20 năm kinh nghiệm thực hiện. Họ là những sản phẩm vững chắc, ổn định, hữu ích. Họ sẽ không biến mất. XML là một công nghệ rất hữu ích để di chuyển dữ liệu giữa các cơ sở dữ liệu khác nhau hoặc giữa các cơ sở dữ liệu và các chương trình khác. Tuy nhiên, bản thân nó không phải là một cơ sở dữ liệu. Đừng sử dụng nó như một. Nhận - XML hiệu quả: 50 cách cụ thể để cải thiện XML của bạn bởi Elliotte Rusty Harold (trang 230, Phần 4, Mục 41, đoạn 2)

Điều này dường như thực sự nhấn mạnh rằng không nên sử dụng XML để lưu trữ dữ liệu và chỉ nên được sử dụng cho chương trình để có khả năng tương tác của chương trình.

Cá nhân, tôi không đồng ý và app.configtệp .NET được sử dụng để lưu trữ cài đặt của chương trình là một ví dụ về lưu trữ dữ liệu trong tệp XML. Tuy nhiên, đối với cơ sở dữ liệu thay vì cấu hình, v.v. XML không nên được sử dụng.

Để phát triển quan điểm của mình, tôi sẽ sử dụng hai ví dụ:
A) Dữ liệu về khách hàng với các trường đều ở một cấp tức là có một số trường liên quan đến một khách hàng không có con
B) Dữ liệu về cấu hình của một ứng dụng trong đó các trường lồng nhau và các tính chất có rất nhiều ý nghĩa

Vì vậy, câu hỏi của tôi là, Đây có phải là một tuyên bố hợp lệ và bây giờ có thể chấp nhận để lưu trữ dữ liệu bằng XML không?

EDIT: Tôi đã gửi email cho tác giả của trích dẫn đó để hỏi về bối cảnh đầu vào / thêm của anh ấy.

Báo giá này không phải là về việc sử dụng XML làm định dạng lưu trữ nói chung (mà nó vẫn ổn, tùy thuộc vào yêu cầu), nhưng đối với lưu trữ kiểu cơ sở dữ liệu .

Khi mọi người nói về cơ sở dữ liệu, họ thường có nghĩa là hệ thống lưu trữ lưu trữ lượng dữ liệu khổng lồ , thường là trong phạm vi gigabyte hoặc terabyte. Một cơ sở dữ liệu có khả năng lớn hơn nhiều so với dung lượng RAM có sẵn trên máy chủ lưu trữ nó. Vì không ai cần tất cả dữ liệu trong cơ sở dữ liệu cùng một lúc, cơ sở dữ liệu nên được tối ưu hóa để truy xuất nhanh các tập hợp con chọn lọc của dữ liệu của họ: đây là những gì SELECTtuyên bố dành cho và cơ sở dữ liệu quan hệ cũng như các giải pháp NoQuery tối ưu hóa định dạng lưu trữ nội bộ của họ nhanh chóng thu hồi các tập con như vậy.

XML, tuy nhiên, không thực sự phù hợp với các yêu cầu này. Do cấu trúc thẻ lồng nhau của nó, không thể xác định vị trí nào trong tệp có giá trị nhất định (về phần bù byte vào tệp) mà không đi bộ toàn bộ cây tài liệu, ít nhất là phù hợp. Cơ sở dữ liệu quan hệ có các chỉ mục và tìm kiếm một giá trị trong một chỉ mục, ngay cả với triển khai tìm kiếm nhị phân nguyên thủy, là một tra cứu O (log n), và sau đó nhận được các giá trị thực tế không gì khác ngoài tìm kiếm tệp (ví dụ: fseek(data_file_handle, row_index * row_size)), đó là O (1). Trong tệp XML, cách hiệu quả nhất là chạy trình phân tích cú pháp SAX trên tài liệu của bạn, thực hiện rất nhiều lần đọc và tìm kiếm trước khi bạn nhận được dữ liệu thực tế của mình; bạn khó có thể có được điều này tốt hơn O (n), trừ khi bạn sử dụng các chỉ mục, nhưng sau đó, bạn phải xây dựng lại toàn bộ chỉ mục cho mỗi lần chèn (xem bên dưới).

Chèn thậm chí còn tồi tệ hơn. Cơ sở dữ liệu quan hệ không đảm bảo thứ tự hàng, có nghĩa là họ chỉ có thể nối thêm các hàng mới hoặc ghi đè lên bất kỳ hàng nào được đánh dấu là 'đã xóa'. Điều này cực kỳ nhanh: DB chỉ có thể giữ một nhóm các vị trí có thể ghi được xung quanh; nhận được một mục từ hồ bơi là O (1) trừ khi hồ bơi trống; trường hợp xấu nhất, pool trống và một trang mới phải được tạo, nhưng đây cũng là O (1). Ngược lại, cơ sở dữ liệu dựa trên XML sẽ phải di chuyển mọi thứ sau điểm chèn để tạo khoảng trống; đây là O (n). Khi các chỉ mục đi vào hoạt động, mọi thứ trở nên thú vị hơn: các chỉ mục cơ sở dữ liệu quan hệ điển hình có thể được cập nhật với độ phức tạp tương đối thấp, giả sử O (log n); nhưng nếu bạn muốn lập chỉ mục các tệp XML của mình, mọi thao tác chèn có khả năng thay đổi vị trí trên đĩa của mọi giá trị trong tài liệu, vì vậy bạn phảixây dựng lại toàn bộ chỉ số . Điều này cũng áp dụng cho các bản cập nhật, bởi vì việc cập nhật, giả sử, nội dung văn bản của một phần tử, có thể thay đổi kích thước của nó, có nghĩa là XML liên tiếp phải thay đổi. Một cơ sở dữ liệu quan hệ hoàn toàn không phải chạm vào chỉ mục nếu bạn cập nhật một cột không được lập chỉ mục; một cơ sở dữ liệu XML sẽ phải xây dựng lại toàn bộ chỉ mục cho mỗi bản cập nhật thay đổi kích thước của nút XML được cập nhật.

Đó là những nhược điểm quan trọng nhất, nhưng có nhiều hơn. XML rất dài dòng, rất tốt cho giao tiếp giữa máy chủ với máy chủ, bởi vì nó tăng thêm tính an toàn (máy chủ nhận có thể thực hiện tất cả các loại kiểm tra tính toàn vẹn trên XML và nếu có bất kỳ lỗi nào xảy ra trong quá trình chuyển, tài liệu không có khả năng xác thực ). Tuy nhiên, đối với lưu trữ dung lượng lớn, điều này rất nguy hiểm: không có gì lạ khi có 100% chi phí trở lên cho dữ liệu XML (không có gì lạ khi thấy tỷ lệ chi phí trong phạm vi 1000% cho những thứ như tin nhắn SOAP), trong khi lưu trữ DB quan hệ điển hình các lược đồ chỉ có một chi phí không đổi cho siêu dữ liệu bảng, cộng với một bit nhỏ trên mỗi hàng; hầu hết các chi phí trong cơ sở dữ liệu quan hệ đến từ độ rộng cột cố định. Nếu bạn có một terabyte dữ liệu, 500% chi phí đơn giản là không thể chấp nhận được, vì nhiều lý do.

XML là tệ hại cho việc lưu trữ dữ liệu. Đầu tiên, nó rất dài dòng. Dữ liệu được lưu trữ trong tệp XML sẽ chiếm nhiều dung lượng đĩa hơn sau đó cùng dữ liệu được lưu trữ trong bất kỳ hệ thống cơ sở dữ liệu hợp lý nào. Trong bản ghi XML, tên của một trường cụ thể sẽ được lưu trữ hai lần, cùng với biểu diễn chuỗi của dữ liệu. Vì vậy, ví dụ, để lưu trữ một số nguyên trong một trường có tên là "foobar", bạn kết thúc với chuỗi 19 byte này:

<foobar>42</foobar>

Mặt khác, một cơ sở dữ liệu thực sẽ lưu trữ giá trị này dưới dạng một giá trị tích phân duy nhất, lấy 4 byte. Nếu cơ sở dữ liệu của bạn nhỏ, điều đó không có nghĩa gì nhiều, nhưng nếu bạn có 10.000 hồ sơ, đó là một vấn đề.

Thứ hai, một XML phải được phân tích cú pháp từ văn bản mỗi khi tệp được đọc. Đối với trường trên, một cơ sở dữ liệu thực sự chỉ cần đọc dữ liệu nhị phân vào bộ nhớ từ phần bù mà nó biết nó đã lưu trữ trường "foobar". Nếu tệp được lưu dưới dạng XML, nó phải đọc trường "foobar", phân tích văn bản đó , xác định nó là trường nào, sau đó phân tích chuỗi "42" và chuyển đổi nó thành nhị phân 42.

Do đó, các hình phạt về hiệu suất khi sử dụng XML là rất lớn. Lợi ích của XML là nó có thể dễ đọc với con người và cho phép dễ dàng chuyển dữ liệu giữa các hệ thống hoàn toàn riêng biệt. Không có những lợi thế đó áp dụng cho một cơ sở dữ liệu địa phương.

Một ngoại lệ là các tệp cấu hình, thường nhỏ và thường phải được con người chỉnh sửa.

Một cơ sở dữ liệu XML hoàn toàn sẽ lớn hơn và chậm hơn bất kỳ hệ thống SQL hợp lý nào. Trừ khi bạn có thể tìm thấy một lợi thế đối trọng về khả năng đọc hoặc khả năng tương tác của con người, không có lý do gì để sử dụng nó để lưu trữ dữ liệu.

XML khả thi tùy thuộc vào ngữ cảnh. Nếu dữ liệu của bạn khá tĩnh và không thay đổi nhiều (ví dụ dữ liệu mẫu), có XML là một cách sử dụng tốt.

Các cài đặt cấu hình, dữ liệu mẫu (ngay cả khi hàng triệu hàng, nhưng hiếm khi thay đổi), đều là những cách sử dụng tốt của XML.

Đọc / ghi đĩa cứng rất tốn kém, nhiều hơn so với việc truy cập dữ liệu từ ngăn xếp Oracle / Sql.

Điều này dường như thực sự nhấn mạnh rằng không nên sử dụng XML để lưu trữ dữ liệu và chỉ nên được sử dụng cho chương trình để có khả năng tương tác của chương trình.

Tiền đề của bạn là thiếu sót.

Đoạn bạn trích dẫn thực sự nói rằng XML không phải là sự thay thế cho cơ sở dữ liệu , không phải là nó không nên được sử dụng để lưu trữ dữ liệu .

Rõ ràng là một tệp cài đặt không giống với cơ sở dữ liệu và vì vậy các công nghệ khác nhau có thể (và nên?) Được sử dụng.

Sửa lỗi cho tôi nếu tôi sai, nhưng bạn dường như có nhiều kinh nghiệm với các ngôn ngữ đánh dấu hơn cơ sở dữ liệu. Nếu bạn có một chút kinh nghiệm với cơ sở dữ liệu, bạn sẽ nhận ra hai miền công nghệ khác nhau phù hợp với.

Điều này thực sự chủ quan. Câu nói đó là, như, ý kiến ​​của ai đó, người đàn ông.

Thành thật mà nói, tôi nghĩ rằng XML là một sự thay thế khả thi cho cơ sở dữ liệu vì nó có nhiều lợi thế hơn RDMS, bao gồm cả chi phí thấp, tương đương với lưu trữ rẻ hơn (đặc biệt là khi sử dụng dịch vụ lưu trữ tính phí riêng cho cơ sở dữ liệu).

Hãy xem dasBlog và BlogEngine . Cả hai ứng dụng này đều sử dụng xml để lưu trữ làm mặc định.

Mà nói. Đó không phải là RDMS và nếu bạn có độ biến động cao (nhiều cập nhật, chèn hoặc xóa) trong dữ liệu của bạn hoặc yêu cầu tính sẵn sàng cao, hãy sử dụng cơ sở dữ liệu. XML là tốt để lưu trữ những thứ nhỏ như dữ liệu cấu hình và dữ liệu biến động thấp.

Câu hỏi của tôi là, Đây có phải vẫn là một tuyên bố hợp lệ và hiện có thể chấp nhận lưu trữ dữ liệu bằng XML không?

Tôi thấy quan điểm của bạn trong ví dụ về tập tin cấu hình .NET. Tuy nhiên, bất kỳ định dạng tập tin khác có thể đã được sử dụng. Trong thực tế, ngày xưa, các cài đặt như vậy thường được lưu trữ trong các tệp văn bản thông thường được gọi là tệp INI.

Tôi thấy rằng tuyên bố bạn đã trình bày bằng màu xám, là hợp lệ và chính xác nếu bạn xác định cơ sở dữ liệu là một hệ thống phần mềm.

Định nghĩa của XML trong Định nghĩa XML nói rằng "(XML) là ngôn ngữ đánh dấu xác định một bộ quy tắc để mã hóa tài liệu theo định dạng có thể đọc được bằng con người và có thể đọc được bằng máy."

Định nghĩa này tập trung vào khả năng đọc và ngôn ngữ hơn là các cơ chế để quản lý dữ liệu.

So với RDBMS, XML không cung cấp phương tiện để chèn và xóa ngẫu nhiên các hàng trong tệp XML. Ví dụ: nếu bạn có 1000000 hàng và bạn muốn xóa các hàng một cách ngẫu nhiên ngay cả trong một môi trường người dùng, tệp dựa trên XML sẽ không phải là một lựa chọn tốt cho cơ sở dữ liệu. Ngoài ra, XML không cung cấp bất kỳ cơ chế riêng nào để khóa dữ liệu. Trên thực tế, vì XML không phải là một phần mềm, tất cả các thuộc tính ACID (tính nguyên tử, tính nhất quán, độ cô lập) đảm bảo rằng các giao dịch cơ sở dữ liệu được xử lý một cách đáng tin cậy trong một môi trường dùng chung được để cho nhà phát triển xây dựng (ngoại trừ Độ bền). XML không có một đặc tả kỹ thuật mạnh mẽ để xử lý tính toàn vẹn dữ liệu trên các tệp XML, chứ đừng nói đến các máy chủ khác nhau (ví dụ: tệp xml của khách hàng và đặt hàng tệp xml - Không có FK để thực thi tính toàn vẹn).

Trên đây không phải là một liệt kê về những gì XML thiếu, thay vào đó, nó có thể phục vụ như một lời biện minh nhanh chóng cho rằng XML không phải là một phần mềm cơ sở dữ liệu .

XML không bao giờ có nghĩa là một cơ sở dữ liệu hoặc thay thế nó.

XML chủ yếu được định nghĩa cho các tài liệu Web mà allows for the creation of customized tags for individual information fields.Tuy nhiên, bạn sẽ không bao giờ đạt được quản lý dữ liệu tập trung quan hệ với nó.

Tại sao bạn thực sự muốn sử dụng XML để lưu trữ dữ liệu ở nơi đầu tiên? Ý tôi là, đó là ngôn ngữ mà ...

Mặc dù người ta có thể lập luận rằng đó là một định dạng linh hoạt và dễ hiểu, chỉ áp dụng khi bạn phải chỉnh sửa thủ công các tệp. Khi bạn thực sự tương tác với cơ sở dữ liệu với giao diện chung (tìm nạp dữ liệu X đáp ứng các yêu cầu Y và Z, lưu trữ / cập nhật dữ liệu X, ...) những lợi thế đó trở nên vô hiệu.

Câu trả lời ngắn gọn: Nó phụ thuộc.

Câu trả lời dài: Theo quan điểm của tôi, điều này phụ thuộc mạnh mẽ vào lượng dữ liệu bạn muốn lưu trữ. Ví dụ: nếu bạn có một vài đối tượng trong ứng dụng của mình trong thời gian chạy và bạn muốn lưu trữ chúng sau khi chạy công cụ thì một tệp XML là hoàn toàn tốt. Tuy nhiên, nếu webshop của bạn có 5000 người quản lý và thậm chí nhiều đơn hàng hơn, cơ sở dữ liệu sẽ là nơi lưu trữ dữ liệu phù hợp hơn.

Ngoài ra, tôi nghĩ rằng việc lưu trữ cài đặt trong cơ sở dữ liệu chứ không phải trong tệp như app.config trong hầu hết các trường hợp không hữu ích lắm, nhưng tôi không nghĩ ví dụ này chứng minh trích dẫn sai.

XML là một lựa chọn tuyệt vời cho các cài đặt cấu hình. Các tệp XML không chỉ dễ phân tích / tô sáng trong IDE, chúng còn rất dễ dàng cho những người không lập trình chỉnh sửa. Tôi thấy chúng cực kỳ hữu ích trong các kịch bản phát triển web nơi các nhiệm vụ bảo trì đang được thực hiện bởi các nhà thiết kế và quản lý nội dung.

XML thường không nên được sử dụng làm nguồn dữ liệu chính cho bất kỳ ứng dụng không tầm thường nào. Chỉ riêng chi phí tuần tự hóa / giải tuần tự hóa đã cầu xin một giải pháp khác.

Thuật ngữ cơ sở dữ liệu có thể chỉ tham khảo dữ liệu thô hoặc hệ thống quản lý cơ sở dữ liệu. Định nghĩa này tạo ra sự khác biệt lớn trong toàn bộ đối số.

Nếu chúng ta sử dụng định nghĩa RDBMS, thì XML có rất ít theo nghĩa đó. Bạn nhận được rất ít về các đảm bảo ACID (bạn phải viết mã của riêng mình để thực hiện các mã đó). Nếu bạn cần những thứ đó (và hầu hết các hệ thống giao dịch làm), bạn đã gặp rắc rối lớn. Tôi có thể đưa ra một danh sách hàng trăm tính năng được cấp bằng RDBMS, mà bạn phải phát minh lại và thực hiện lại. Hãy suy nghĩ các mô hình bảo mật, nhân rộng, sao lưu, chỉ để đặt tên cho một vài cái cơ bản.

Theo nghĩa trên, không, XML không phải là cơ sở dữ liệu và bạn không nên cố gắng sử dụng nó làm cơ sở dữ liệu.

Nếu chúng ta sử dụng định nghĩa "dữ liệu thô", XML sẽ tốt hơn rất nhiều, nhưng vẫn không tuyệt lắm. Như những người khác đã chỉ ra, nói chung, nó rất dài dòng, thường thiếu mã hóa nhị phân và có các thẻ trùng lặp, v.v ... Đây là những sự đánh đổi được thực hiện để XML có thể đọc được - về cơ bản, hiệu quả là kẻ thù của yêu cầu này . XML cũng không phải là đặc biệt phù hợp cho cả những tình huống đơn giản nhất mà bạn đang chèn các bản ghi liên tục. Giả sử bạn muốn tệp XML của mình hợp lệ, bạn cần một thẻ đóng duy nhất, điều đó có nghĩa là việc nối thêm một bản ghi có nghĩa là bạn cần phải thay đổi các thẻ ở cuối. Cái này khá đắt (làm sao chúng ta biết thẻ đó bắt đầu từ đâu? Nếu có nhiều "bảng", chúng ta có di chuyển lên toàn bộ tệp không?) Và nếu bạn muốn làm việc xung quanh nó, bạn '

Có những tình huống mà XML phù hợp - các tệp cấu hình là một ví dụ tuyệt vời, vì chúng thường nhỏ và khả năng đọc của con người là một tính năng tuyệt vời cần có. Có một cơ sở dữ liệu chỉ cho một tập tin cấu hình có thể là quá mức cần thiết.

Mặt khác, cơ sở dữ liệu rất tuyệt vời khi bạn có hàng ngàn (hoặc hàng triệu / tỷ) hồ sơ và có nhiều người dùng đồng thời cập nhật chúng. Vì vậy, có, XML không phải là một cơ sở dữ liệu và bạn không nên sử dụng nó như một cơ sở dữ liệu. Ví dụ của bạn là một trong những tình huống mà bạn không cần DB ngay từ đầu và XML là phù hợp hơn.

Theo cách tôi thấy là thế này: nếu bạn sử dụng XML làm DB (giả sử, là cửa hàng sao lưu cho hệ thống giao dịch), bạn sẽ kết thúc việc phát minh lại và viết lại RDBMS . Đó là một cách thực sự nghèo để dành thời gian và năng lượng của bạn. Tôi nghĩ rằng đây là những gì mà trích dẫn đã nói là tốt.

Tôi đồng ý rằng nó không phải là một cơ sở dữ liệu quan hệ. Tôi nghĩ rằng tác giả chỉ đơn giản là nói trong trích dẫn không sử dụng nó như là một.

Đã nói rằng mặc dù bạn có thể hoặc không cần. Nếu bạn không thực sự cần thực hiện nhiều truy vấn trên dữ liệu và chỉ có ý định lưu trữ dữ liệu đó và sau đó tìm nạp nó dựa trên một số tiêu chí truy vấn hạn chế thì bạn cần lưu trữ và truy xuất XML DOCUMENT - không phải là cơ sở dữ liệu quan hệ.

Có rất nhiều ứng dụng chỉ cần lưu trữ một tài liệu với dữ liệu trong đó để lấy toàn bộ sau này. Nếu đây là trường hợp thì việc tạo một lược đồ dựa trên SQL là vô ích, phân tích cú pháp XML và sau đó tuần tự hóa nó vào cơ sở dữ liệu để thực hiện ngược lại sau này. Có rất nhiều mã trên có khả năng liên quan đến việc đó. Có ít hơn mặc dù nếu bạn làm đúng.

Bạn có thể sử dụng các công cụ ORM như Hibernate và các công cụ như Apache Trục để tự động tạo ra tất cả các mã bạn cần để xây dựng một dịch vụ chỉ xử lý các hoạt động CRU đơn giản. Tất nhiên, bạn phải bọc nó để xác thực và có thể muốn tách biệt dữ liệu dựa trên người dùng, mức độ truy cập, v.v. Thậm chí, bạn có thể muốn giới hạn những thao tác mà người dùng đã cho phép được thực hiện thông qua dịch vụ SOAP cho thí dụ.

Theo nghĩa này, bạn đang làm giống như quản lý nội dung hơn bất cứ điều gì khác.