Tôi đang phát triển một ứng dụng sẽ cần lưu trữ nội tuyến , intext siêu dữ liệu. Ý tôi là như sau: giả sử chúng ta có một văn bản dài và chúng ta muốn lưu trữ một số siêu dữ liệu được kết nối với một từ hoặc câu cụ thể của văn bản.

Điều gì sẽ là cách tốt nhất để lưu trữ thông tin này?

Suy nghĩ đầu tiên của tôi là đưa vào văn bản một số loại Markdowncú pháp mà sau đó sẽ được phân tích cú pháp khi truy xuất. Một cái gì đó trông như thế này:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[@note this sounds really funny latin]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Điều này sẽ giới thiệu hai vấn đề tôi có thể nghĩ đến:

1. Một điều tương đối nhỏ, là nếu cú ​​pháp nói xảy ra tình cờ trên văn bản đã nói, nó có thể gây rối với phân tích cú pháp.
2. Điều quan trọng nhất là điều này không duy trì siêu dữ liệu này tách biệt với chính văn bản.

Tôi muốn có một cấu trúc dữ liệu riêng biệt để chứa dữ liệu này, như một Bảng DB khác nhau trong đó các metadatas này được lưu trữ, để tôi có thể sử dụng chúng theo các cách riêng biệt: truy vấn, thống kê, sắp xếp, v.v.

EDIT: Vì người trả lời đã xóa câu trả lời của anh ấy, tôi nghĩ có thể tốt hơn khi thêm đề xuất của anh ấy vào đây, vì đó là một gợi ý khả thi được mở rộng trên khái niệm đầu tiên này. Các poster gợi ý để sử dụng một cú pháp tương tự, nhưng để liên kết các siêu dữ liệu cho PRIMARY KEYcác metadatabảng cơ sở dữ liệu.

Một cái gì đó sẽ trông như thế này:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[15432]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Trường hợp 15432sẽ là IDmột hàng của bảng chứa thông tin cần thiết, có thể truy vấn, như ví dụ dưới đây.

Suy nghĩ thứ hai của tôi là lưu trữ thông tin loại này trong Bảng DB trông như thế này:

TABLE: metadata

ID    TEXT_ID    TYPE    OFFSET_START    OFFSET_END    CONTENT
1     lipsum     note    68              79            this sounds really funny latin

Theo cách này, siêu dữ liệu sẽ có một id duy nhất, text_idnhư một khóa ngoại được kết nối với bảng lưu trữ văn bản và nó sẽ kết nối dữ liệu với chính văn bản bằng cách sử dụng phạm vi bù ký tự đơn giản .

Điều này sẽ thực hiện thủ thuật giữ dữ liệu tách biệt với siêu dữ liệu , nhưng một vấn đề mà tôi có thể thấy ngay với cách tiếp cận này là văn bản về cơ bản sẽ không thể chỉnh sửa được . Hoặc, nếu tôi muốn thực hiện chỉnh sửa văn bản sau khi gán siêu dữ liệu, về cơ bản tôi sẽ phải tính toán thêm các ký tự hoặc xóa so với phiên bản trước và kiểm tra xem mỗi sửa đổi này có thêm hoặc xóa các ký tự trước hay sau mỗi ký tự của siêu dữ liệu liên quan.

Mà, đối với tôi, nghe có vẻ như là một cách tiếp cận thực sự không phù hợp.

Bạn có bất kỳ gợi ý hoặc gợi ý cho cách tôi có thể tiếp cận vấn đề?

Chỉnh sửa 2: một số vấn đề về XML

Thêm một trường hợp khác sẽ khiến việc phân tách dữ liệu và siêu dữ liệu này xảy ra khá cần thiết.

• Giả sử tôi muốn làm cho những người dùng khác nhau có thể có các bộ siêu dữ liệu khác nhau của cùng một văn bản , có hoặc không có khả năng mỗi người dùng thực sự hiển thị siêu dữ liệu người dùng khác.

Bất kỳ giải pháp của markdown loại (hoặc HTML, hoặc XML) sẽ rất khó để thực hiện vào thời điểm này. Giải pháp duy nhất trong trường hợp này mà tôi có thể nghĩ đến là có một Bảng DB khác chứa phiên bản người dùng duy nhất của văn bản gốc, kết nối với bảng văn bản gốc bằng cách sử dụng a FOREIGN KEY.

Không chắc chắn nếu điều này là rất thanh lịch.

• XML có một mô hình dữ liệu phân cấp: bất kỳ yếu tố nào nằm trong biên giới của một yếu tố khác đều được coi là con của nó , thường không phải là trường hợp trong mô hình dữ liệu mà tôi đang tìm kiếm; trong XML, bất kỳ phần tử con nào cũng phải được đóng trước khi có thể đóng thẻ cha , cho phép không có phần tử chồng lấp.

Thí dụ:

<note content="the beginning of the famous placeholder"> Lorem ipsum dolor ngồi <comment content="I like the sound of amet/elit"> amet </note> , consectetuer adipiscing elit </comment> , <note content="adversative?"> sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<note content="funny latin"> </note> </note>

Ở đây chúng tôi có hai vấn đề khác nhau:

1. Các yếu tố khác nhau chồng chéo: Nhận xét đầu tiên bắt đầu trong ghi chú đầu tiên, nhưng kết thúc sau khi kết thúc ghi chú đầu tiên, tức là nó không phải là con của nó.

2. Các yếu tố giống nhau chồng chéo: Ghi chú cuối cùng và ghi chú in đậm; tuy nhiên, vì chúng là cùng một loại phần tử, trình phân tích cú pháp sẽ đóng phần tử được mở cuối cùng ở lần đóng đầu tiên và phần tử được mở đầu tiên ở lần đóng cuối cùng, trong trường hợp này, không phải là mục đích.

Tôi muốn kết hợp các giải pháp của bạn, nhưng thay vào đó, tôi sẽ sử dụng một tiêu chuẩn: XML. Bạn sẽ có một cú pháp như thế này

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam <note content="It sound really funny in latin">nonummy nibh</note>
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Tại sao XML

Nếu bạn nghĩ về nó, đó chính xác là cách toàn bộ web được cấu trúc : nội dung (văn bản thực tế) mang ngữ nghĩa - thứ mà bạn đang gọi siêu dữ liệu - thông qua các thẻ html.

Bằng cách này, bạn có một thế giới thực sự tuyệt vời mở ra:

• Trình phân tích cú pháp miễn phí
• Cách thử nghiệm để thêm siêu dữ liệu vào nội dung
• Dễ sử dụng (tùy thuộc vào người dùng bạn đang nhắm mục tiêu)
• Bạn có thể dễ dàng trích xuất văn bản thô mà không cần siêu dữ liệu vì đây là một tính năng tiêu chuẩn trên các trình phân tích cú pháp XML. Điều đó rất hữu ích để có một phiên bản có thể lập chỉ mục của nội dung của bạn, vì vậy Lorem <note>ipsum</note>được nêu ra khi bạn đang tìm kiếm lorem ips*chẳng hạn.

Tại sao XML hơn Markdown

Một trang web như stackexchange sử dụng markdown vì ngữ nghĩa mà nội dung của nó truyền tải khá cơ bản: nhấn mạnh, liên kết / url, hình ảnh, tiêu đề, v.v ... Có vẻ như ngữ nghĩa bạn thêm vào nội dung của bạn là

1. Phức tạp hơn
2. Có thể thay đổi hoặc phải mở rộng

Vì vậy, tôi cảm thấy Markdown sẽ không phải là một ý tưởng thực sự tốt. Ngoài ra Markdown không thực sự được tiêu chuẩn hóa, và phân tích cú pháp / đổ nó có thể là một nỗi đau ở mông, thậm chí nhiều cú pháp đánh dấu hơn xem bài đăng của Jeff Atwood về WTF mà anh ấy đã gặp khi phân tích Markdown .

Về sự tách biệt giữa dữ liệu và siêu dữ liệu

Per se, sự tách biệt như vậy không bắt buộc. Tôi cho rằng bạn đang tìm kiếm lợi thế mà nó mang lại:

• Khả năng có nội dung thô mà không cần siêu dữ liệu
• Tách biệt mối quan tâm: Tôi không muốn có chi phí hiệu ứng phụ / độ phức tạp khi thao tác siêu dữ liệu vì dữ liệu và mặt khác.

Tất cả những mối quan tâm này được xóa bằng cách sử dụng XML. Từ XML, bạn có thể dễ dàng kết xuất bất kỳ nội dung bị tước thẻ nào và dữ liệu / siêu dữ liệu được phân tách, giống như thuộc tính và văn bản thực tế được phân tách trong XML.

Ngoài ra tôi không nghĩ rằng bạn thực sự có thể có siêu dữ liệu của bạn hoàn toàn không bị ràng buộc với dữ liệu của bạn . Từ những gì bạn mô tả, siêu dữ liệu của bạn là một thành phần của dữ liệu của bạn, tức là xóa dữ liệu dẫn đến xóa siêu dữ liệu. Đây là nơi bạn chuyển hướng siêu dữ liệu từ HTML / CSS thông thường. CSS không biến mất khi một phần tử html bị xóa, bởi vì nó có thể được áp dụng cho các phần tử khác. Tôi không cảm thấy đây là trường hợp trong siêu dữ liệu của bạn.

Có siêu dữ liệu gần với dữ liệu, như trong XML hoặc Markdown, cho phép dễ hiểu (và có thể gỡ lỗi) các dữ liệu. Ngoài ra, ví dụ bạn đưa ra cho ý nghĩ thứ hai của bạn thêm một số phức tạp, bởi vì với mỗi dữ liệu tôi đang đọc, tôi cần truy vấn bảng siêu dữ liệu để có được những dữ liệu này. Nếu mối quan hệ giữa dữ liệu của bạn và siêu dữ liệu của bạn là 1: 1 hoặc 1: N, thì IMO rõ ràng là vô dụng và chỉ mang lại sự phức tạp (một trường hợp tốt của YAGNI).

Ca sử dụng giải pháp

Tôi không đồng ý với một số câu trả lời khác, đơn giản bởi vì, trong khi các giải pháp tuyệt vời, có lẽ chúng không phải là giải pháp của bạn . Có XML có từ đánh dấu trong từ viết tắt của nó, nhưng nó có thể không lý tưởng cho tình huống của bạn. Nó quá phức tạp, nó cung cấp rất ít sự trợ giúp trong việc tách biệt dữ liệu meta khỏi văn bản gốc. Về cơ bản, nó sẽ biến mọi thứ thành một dạng siêu dữ liệu, tạo ra một tập dữ liệu thừa cân.

Vì có khả năng không có giải pháp hoặc cách tiếp cận hoàn toàn chính xác, giải pháp tốt nhất trả lời câu hỏi:

Dữ liệu sẽ được hệ thống sử dụng như thế nào?

Ngoài ra, nếu bạn thử và hỏi, làm thế nào một thiết kế giải pháp vốn có thể thêm vào giá trị của hệ thống, theo cách nó sẽ được sử dụng, thì bạn sẽ tiến gần hơn đến việc tìm ra câu trả lời tao nhã của mình .

Hiểu vấn đề

Ok đủ bình luận, hãy đi sâu vào vấn đề. Đây là vấn đề như tôi hiểu nó (rõ ràng thêm vào điều này sẽ có lợi):

• Có một văn bản gốc
  • Giả định về văn bản gốc này:
  • Văn bản này, có thể hoặc không thể được tạo thành từ một số tài liệu độc lập
  • Văn bản này, có thể hoặc không thể được chỉnh sửa bởi một hoặc nhiều người dùng
  • Văn bản này, chứa thông tin liên quan . Bằng cách đó, tôi giả sử (sửa tôi nếu tôi sai) rằng siêu dữ liệu có liên quan và không mô tả . Vì vậy, nó lưu trữ thông tin liên quan đến văn bản gốc, và không phải thông tin mô tả văn bản. Vì vậy, nó sẽ lưu trữ các ghi chú về văn bản gốc, và không bằng ví dụ mô tả rằng các văn bản là một tiêu đề đó là táo bạo và là một liên kết đến một trang web, vv
  • Văn bản phải dễ dàng được lọc khác biệt với siêu dữ liệu
  • Văn bản phải được bảo vệ khỏi bị hỏng bởi và làm hỏng siêu dữ liệu
• Cần có một phương tiện lưu trữ thông tin liên quan đến văn bản gốc (siêu dữ liệu)
  • Siêu dữ liệu này cũng cần siêu dữ liệu (meta) của riêng nó, nó sẽ chứa thông tin như dữ liệu meta của người dùng (hoặc nhóm nào?), Chẳng hạn như mô tả siêu dữ liệu, cho biết thời tiết là ghi chú hoặc nhận xét hoặc mô tả, vv
  • Siêu dữ liệu này (và đó là siêu dữ liệu (meta)) cần chịu được các thay đổi trong văn bản gốc, các thay đổi của siêu dữ liệu và các thay đổi của dữ liệu meta (meta)
  • Siêu dữ liệu (+ Siêu dữ liệu) cần phải được cấu trúc tốt và dễ dàng truy vấn, và được lập chỉ mục hoặc thậm chí tham gia theo cách liên quan đến các bộ dữ liệu khác. Bản chất quan hệ của siêu dữ liệu không chỉ giới hạn trong Truy vấn mà còn tạo điều kiện cập nhật hoặc ghi lại và thay đổi siêu dữ liệu do các hoạt động dữ liệu quan hệ.
  • Giá trị của siêu dữ liệu (+ Siêu dữ liệu) nằm trong bản chất rất liên quan của nó. Nó ngay lập tức phản tác dụng ngay khi nó mất đi mối quan hệ với văn bản gốc. Do đó, tính toàn vẹn của nó liên quan đến văn bản gốc là một mệnh lệnh thiết kế bắt buộc.
• Các giả định khác về bản chất của vấn đề và cách sử dụng nó là:
  • Truy cập hệ thống không đồng nhất. Điều đó có nghĩa là người dùng có thể muốn xem văn bản và chỉnh sửa siêu dữ liệu, cùng lúc với quản trị viên (hoặc một quy trình khác) đang thực hiện các truy vấn dữ liệu quan hệ trên siêu dữ liệu có cấu trúc.
  • Hệ thống sẽ có nhiều người dùng
  • Hệ thống hiện đại. Điều đó có nghĩa là nó không bị hạn chế bởi không gian lưu trữ, hoặc tốc độ xử lý hoặc các mệnh lệnh thời gian thực. Tính toàn vẹn và chức năng tập trung vào mục đích là ưu tiên cao hơn các giới hạn tài nguyên máy tính vật lý.
  • Có khả năng (mặc dù thấp) rằng việc sử dụng và chức năng của hệ thống có thể phát triển hoặc thay đổi phần nào, khi hệ thống được sử dụng.

Xây dựng thiết kế giải pháp

Hiểu vấn đề như tôi đã nêu ở trên, bây giờ tôi sẽ bắt đầu đề xuất các giải pháp và phương pháp khả thi nhằm giải quyết vấn đề trên.

Các thành phần

Vì vậy, tôi sẽ thấy rằng cần phải có một hệ thống truy cập người dùng được xây dựng tùy chỉnh. Nó sẽ lọc siêu dữ liệu liên quan và không liên quan từ văn bản gốc. Nó sẽ tạo điều kiện cho việc chỉnh sửa và xem siêu dữ liệu vào văn bản. Nó sẽ đảm bảo tính toàn vẹn của mối quan hệ giữa siêu dữ liệu và văn bản gốc của nó. Nó sẽ cấu trúc siêu dữ liệu và cung cấp nguồn dữ liệu cho hệ thống dữ liệu quan hệ. Nó rất có thể sẽ cung cấp một loạt các chức năng điều khiển mục đích khác.

Kết cấu

Vì vậy, điều quan trọng là giữ tính toàn vẹn của siêu dữ liệu đối với văn bản gốc, cách tốt nhất để đảm bảo điều này, là giữ siêu dữ liệu nội tuyến với văn bản gốc. Điều này sẽ mang lại lợi ích là dữ liệu gốc có thể được tự tin chỉnh sửa mà không phá vỡ tính toàn vẹn này.

Mối quan tâm với phương pháp này là sự hỏng của siêu dữ liệu bởi dữ liệu gốc và ngược lại. Việc lập chỉ mục và cấu trúc đầy đủ của siêu dữ liệu và siêu dữ liệu (meta) theo cách cho phép truy vấn và cập nhật và truy cập hiệu quả. Việc dễ dàng lọc siêu dữ liệu từ văn bản gốc.

Với suy nghĩ này, tôi sẽ đề xuất rằng một phần của giải pháp dựa trên cách tiếp cận sử dụng các đặc điểm ESCAPE trong văn bản gốc. Điều này không giống như thiết kế Ngôn ngữ đánh dấu của riêng bạn hoặc sử dụng Ngôn ngữ đánh dấu hiện có như XML hoặc HTML. Thật dễ dàng để thiết kế một TÍNH NĂNG ESCAPE có cơ hội tồn tại bằng 0 hoặc gần như bằng không trong văn bản gốc.

Lời khuyên của tôi cho bạn về vấn đề này sẽ là xem xét cẩn thận dữ liệu gốc và thử và xác định bản chất của trang mã được lưu trữ và sau đó tìm kiếm một CHARACTER lý tưởng hoặc CHARACTER SEQUENCEđiều đó là không thể hoặc không thể xảy ra Ví dụ, trong ASCII, có các ký tự điều khiển tích hợp theo nghĩa đen với các giá trị byte không bao giờ được sử dụng trong các giao diện người dùng chuẩn. Điều tương tự có thể được nói cho một hệ thống thông tin dựa trên dữ liệu dựa trên phông chữ hoặc quan hệ. Chỉ cần cẩn thận với codec dữ liệu nhị phân. Tùy thuộc vào bản chất của dữ liệu gốc, có thể có giá trị để xây dựng trình phân tích cú pháp xác nhận việc phát hiện chuỗi điều khiển, có thể bằng cách xem dữ liệu được thoát và xác minh tính toàn vẹn của nó, bằng cách kiểm tra đơn giản cấu trúc của thoát dữ liệu hoặc thậm chí bằng cách bao gồm một ký tự điều khiển được tính cho từng chuỗi dữ liệu đã thoát.

Dữ liệu mẫu với các chuỗi thoát

Đây là một câu chuyện của một người đàn ông. >>>> (#) Tại sao là câu chuyện về một người đàn ông không phải là một người phụ nữ? (#) ( ) Userid :: 77.367 ( ) Bình luận (Manager ) DataID :: 234.234.234 >>>> Một người đàn ông đã đi để cắt một đồng cỏ, đã đi đến một đồng cỏ. Người đàn ông đã đi với con chó của mình >>>> (#) Hỏi khách hàng xem câu chuyện sẽ tốt hơn với một con mèo thay vào đó (#) >>>> để cắt cỏ. Vì vậy, bây giờ đây là câu chuyện về một người đàn ông và con chó của anh ta đã đi cắt cỏ.

Một người đàn ông và con chó của anh ta, đi cắt cỏ, đi cắt cỏ, một đồng cỏ vươn qua núi. >>>> (#) Điều này nghe có vẻ tốt hơn với một khu rừng (**) Ghi chú đề xuất (#) >>>>

Người đàn ông và con chó của anh ta và nhiệm vụ của anh ta, để cắt một đồng cỏ, một đồng cỏ vươn qua núi chỉ đạt được khi qua sông.

Dữ liệu mẫu không có chuỗi thoát

Đây là một câu chuyện của một người đàn ông. Một người đàn ông đi cắt cỏ, đi cắt cỏ. Người đàn ông đã đi với con chó của mình để cắt cỏ. Vì vậy, bây giờ đây là câu chuyện về một người đàn ông và con chó của anh ta đã đi cắt cỏ.

Một người đàn ông và con chó của anh ta, đi cắt cỏ, đi cắt cỏ, một đồng cỏ vươn qua núi.

Người đàn ông và con chó của anh ta và nhiệm vụ của anh ta, để cắt một đồng cỏ, một đồng cỏ vươn qua núi chỉ đạt được khi qua sông.

Rõ ràng điều này dễ dàng được phân tích cú pháp, không phức tạp như toàn bộ ngôn ngữ Đánh dấu và dễ dàng thích ứng với mục đích của bạn.

Đã giải quyết chưa? Vâng, tôi sẽ nói không. Giải pháp của chúng tôi vẫn còn một số lỗ hổng. Việc lập chỉ mục và truy cập có cấu trúc của dữ liệu này là kém. Ngoài ra, sẽ không hợp lý khi truy vấn tệp này (hoặc một số tệp) cùng lúc với chỉnh sửa tệp.

Làm thế nào chúng ta có thể giải quyết vấn đề đó?

Tôi muốn đề xuất BẢNG DỮ LIỆU DỮ LIỆU làm tiêu đề tài liệu. Tôi cũng sẽ đề nghị thực hiện một CÂU HỎI CẬP NHẬT BẢNG GIAO DỊCH . Hãy để tôi giải thích. Các nhà thiết kế của một hệ thống tệp, đặc biệt là hệ thống tệp đĩa quay, phải đối mặt với những thách thức thiết kế tương tự như những gì bạn đã mô tả ở trên. Họ cần phải nhúng thông tin về các tệp trên đĩa cùng với dữ liệu. Một giải pháp tuyệt vời cho tính toàn vẹn của mối quan hệ của dữ liệu này, đó là KHAI THÁC nó trong Bảng phân bổ tệp (FAT).

Điều này có nghĩa là đối với mỗi Mục siêu dữ liệu riêng lẻ, có một mục tương ứng trong Bảng phân bổ dữ liệu . Vì vậy, nó là nhanh chóng, có cấu trúc và quan hệ, và độc lập với dữ liệu gốc. Nếu các truy vấn hoặc tham gia hoặc cập nhật cần được thực hiện trên siêu dữ liệu, thì việc này dễ dàng được thực hiện bằng cách truy cập Bảng phân bổ dữ liệu .

Rõ ràng phải cẩn thận để đảm bảo rằng siêu dữ liệu nội tuyến gốc là sự phản ánh đúng sự thật của dữ liệu Bảng phân bổ dữ liệu. Đó là nơi hàng đợi cập nhật bảng giao dịch xuất hiện. Mọi thay đổi, thêm hoặc xóa siêu dữ liệu, không được thực hiện trên chính dữ liệu, mà là trên hàng đợi. hàng đợi sau đó sẽ đảm bảo rằng tất cả các thay đổi được thực hiện cho cả dữ liệu nội tuyến và dữ liệu bảng hoặc không có thay đổi nào được thực hiện. Nó cũng cho phép thực hiện các cập nhật không đồng bộ, ví dụ, tất cả siêu dữ liệu của một người dùng nhất định có thể bị xóa bằng cách chạy lệnh xóa trên hàng đợi. Nếu siêu dữ liệu nội tuyến bị khóa và đang sử dụng, hàng đợi sẽ không thực hiện bất kỳ thay đổi nào cho đến khi nó có thể thực hiện được cả dữ liệu Bảng và dữ liệu nội tuyến.

Đây là một loại câu hỏi kỹ thuật điển hình trong đó tất cả các lựa chọn của bạn có sự đánh đổi khác nhau, và điều này tốt nhất phụ thuộc vào những gì quan trọng đối với bạn. Thật không may, bạn đã không cung cấp đủ thông tin để đưa ra quyết định.

Bạn cũng chưa xuất hiện để xem xét một vấn đề ngữ nghĩa quan trọng. Hãy nói rằng văn bản gốc là

Bob bạn tôi cho tôi mượn năm đô la

Ai đó thêm một nhận xét xung quanh câu nói "Bob"

Bob là một thằng ngốc hoàn toàn

Sau đó, văn bản gốc được chỉnh sửa thành

Jane cho Bob mượn năm đô la mà sau này anh ấy cho tôi mượn

Bạn có thể hiểu ý nghĩa của trường hợp cụ thể này bằng thuật toán so khớp văn bản, chẳng hạn như những gì được sử dụng để hiển thị một tệp khác, nhưng phần bù ký tự sẽ làm cho siêu dữ liệu được gắn vào "Jan" trong "Jane".

Tệ hơn là nếu văn bản được chỉnh sửa thành

Steve bạn tôi cho tôi mượn năm đô la

Bạn có thể quản lý để tìm ra cách đính kèm siêu dữ liệu vào "Steve", nhưng làm thế nào để bạn biết nếu nó được áp dụng?

Ngoài ra, bạn đã quyết định nếu chính siêu dữ liệu có thể có siêu dữ liệu? Điều đó có thể thay đổi việc thực hiện của bạn.

Ngoài các vấn đề ngữ nghĩa, không rõ bạn đang làm gì với dữ liệu. Tôi nghĩ có lẽ rất bất tiện khi văn bản gốc bị "ô nhiễm" với bất kỳ đánh dấu nào, nhưng sau đó bạn đã ổn với việc có các giá trị ID trong đó. Điều này sẽ không có ý nghĩa gì nếu siêu dữ liệu áp dụng cho một phần văn bản thay vì được chèn vào một điểm trong văn bản.

Tôi đoán là đối với hầu hết các mục đích, việc lưu trữ văn bản được đánh dấu là dễ dàng hơn, hoặc, lựa chọn thứ hai, đi tất cả SQL và có văn bản và đánh dấu được biểu thị bằng hệ thống phân cấp nút - về cơ bản là DOM ở dạng bảng. Nếu dữ liệu của bạn được phân cấp hơn thì có thể dễ dàng sử dụng XML hơn và nhận các trình phân tích cú pháp hiện có miễn phí, so với việc viết riêng của bạn.

Hoàn toàn có thể có một giải pháp khá đơn giản, đủ tốt cho tình huống chính xác của bạn, nhưng tôi không thể nói cho bạn biết đó là gì vì nó thực sự phụ thuộc vào chính những gì bạn đang cố gắng làm, chi tiết.

Tôi thực sự khuyên bạn nên gói gọn bất kỳ chiến lược nào bạn chọn càng nhiều càng tốt, mặc dù điều này khá khó thực hiện nếu phần lớn việc triển khai của bạn cần hiển thị đối với nhiều truy vấn SQL.

Xin lỗi rằng câu trả lời rất phân tán và đầy "tùy thuộc", nhưng câu hỏi thiết kế trong thế giới thực là như thế.

Tôi nghĩ rằng gợi ý từ người trả lời trước, người bạn đề cập đến câu hỏi của bạn) là một câu hỏi rất hay.

Nó sẽ hoạt động giống như cách chúng tôi đăng liên kết trên các trang web StackExchange, nhưng dữ liệu thông tin sẽ nằm trên một bảng khác. Những lợi ích là, bạn có dữ liệu được phân tách, do đó có thể truy vấn và lập chỉ mục. Khi chỉnh sửa văn bản, bạn có thể kiểm tra ID siêu dữ liệu đã xóa và xóa bảng siêu dữ liệu.

Vấn đề nhỏ duy nhất như bạn nói là phân tích cú pháp, nhưng bạn có thể giải quyết nó khá dễ dàng.

Hãy nói rằng tôi có một văn bản:

Lorem ipsum dolor ngồi amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Tôi thêm ghi chú như thế này:

Lorem ipsum dolor ngồi amet, consectetuer adipiscing elit, sed diam [@ 123, # 456,2w] nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

[@123,#456,2w]có nghĩa là: user_id = 123, note_id = 456 và văn bản được đánh dấu bởi ghi chú này kéo dài cho 2 từ tiếp theo (có thể là chars ( c), câu ( s), paragraps ( p) hoặc bất cứ điều gì). Cú pháp chính xác có thể khác nhau, tất nhiên.

Trong trình soạn thảo văn bản đơn giản, văn bản của ghi chú có thể dễ dàng được lưu trữ ở cuối tài liệu, giống như với chú thích Markdown.

Trong các trình soạn thảo văn bản phong phú, loại ghi chú này có thể được hiển thị trong văn bản dưới dạng biểu tượng và văn bản được đánh dấu có thể được làm nổi bật theo một cách nào đó. Sau đó, người dùng có thể xóa các ghi chú như các ký tự bình thường với Delhoặc Backspacechỉnh sửa chúng bằng một số chế độ chỉnh sửa đặc biệt. Tôi tưởng tượng thay đổi kích thước các khu vực được ghi chú bằng chuột và chỉnh sửa văn bản ghi chú với cửa sổ bật lên.

Ưu điểm:

• Đi độc đáo với "giao điểm" vì bạn đánh dấu một phần bù (hoàn toàn theo vị trí của ghi chú trong văn bản) và độ dài cho mỗi ghi chú.
• Hỗ trợ môi trường nhiều người dùng. (Trên thực tế, điều này cần một số nghiên cứu sâu hơn và có lẽ bạn sẽ phải đối phó với những thứ như chuyển đổi hoạt động của Google Wave mà não tôi không thể xử lý được.)
• Có thể được chỉnh sửa với cả trình soạn thảo văn bản phong phú và đơn giản.
• Bạn có thể dễ dàng xử lý các sửa đổi, vì tất cả các điểm đánh dấu đều được đặt đúng chỗ - khi bạn chỉnh sửa văn bản trước một điểm đánh dấu, điểm đánh dấu chỉ thay đổi cùng với văn bản khác.
• Dễ phân tích cú pháp.
• Không cần DB bên ngoài, nhưng bạn vẫn có thể sử dụng một cái nếu muốn.
• Có thể được trộn lẫn với Markdown hoặc XML nếu bạn chọn một số cú pháp không phô trương.

Nhược điểm cho chỉnh sửa văn bản đơn giản:

• Bạn không thể thấy các khu vực trong văn bản được đánh dấu bằng ghi chú (trừ khi bạn làm nổi bật văn bản gốc, đây cũng là một tùy chọn), nhưng chỉ là những nơi bắt đầu ghi chú. Điều này được bù đắp bởi khả năng chọn các đơn vị độ dài tùy ý: ký tự, từ, câu, đoạn văn.
• Bạn có thể chỉnh sửa văn bản dưới một ghi chú mà không cần chú ý, đặc biệt nếu một ghi chú kéo dài khá lâu (ví dụ 2+ đoạn). Có thể được bù bằng cơ chế kiểm soát revison so sánh một văn bản dưới mỗi ghi chú với phiên bản trước đó và thông báo cho người dùng nếu nó bị thay đổi.

Nhược điểm chung:

• Rắc rối với nhiều người dùng chỉnh sửa cùng một văn bản, nhưng tôi nghĩ dù sao nó cũng không thể tránh khỏi. Tôi không phải là một chuyên gia trong lĩnh vực này.