ฉันกำลังพัฒนาโปรแกรมที่จะต้องมีการจัดเก็บแบบอินไลน์ , intextเมตาดาต้า สิ่งที่ฉันหมายถึงคือสิ่งต่อไปนี้สมมติว่าเรามีข้อความยาวและเราต้องการเก็บข้อมูลเมตาบางส่วนที่เชื่อมต่อกับคำเฉพาะหรือประโยคของข้อความ

อะไรจะเป็นวิธีที่ดีที่สุดในการจัดเก็บข้อมูลนี้

ความคิดแรกของฉันคือการรวมไว้ในข้อความMarkdownไวยากรณ์บางอย่างที่จะถูกแยกวิเคราะห์ในการดึง บางสิ่งที่มีลักษณะเช่นนี้:

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.

นี่จะแนะนำปัญหาสองประการที่ฉันสามารถนึกได้:

1. สิ่งหนึ่งที่ค่อนข้างเล็กคือถ้าไวยากรณ์ดังกล่าวเกิดขึ้นโดยบังเอิญในข้อความดังกล่าวมันสามารถยุ่งกับการแยกวิเคราะห์
2. สิ่งที่สำคัญที่สุดคือสิ่งนี้จะไม่เก็บข้อมูลเมตานี้แยกจากข้อความ

ฉันต้องการให้มีโครงสร้างข้อมูลแบบแยกเพื่อเก็บข้อมูลนี้เช่นตารางฐานข้อมูลที่แตกต่างกันซึ่งข้อมูลเมตาเหล่านี้ถูกเก็บไว้เพื่อให้ฉันสามารถใช้พวกเขาในรูปแบบที่ไม่ต่อเนื่อง: การสืบค้นสถิติการเรียงลำดับและอื่น ๆ

แก้ไข:เนื่องจากผู้ตอบลบคำตอบของเขาฉันคิดว่ามันอาจเป็นการดีที่จะเพิ่มข้อเสนอแนะของเขาที่นี่เนื่องจากเป็นข้อเสนอแนะที่ใช้การได้ซึ่งขยายได้ในแนวคิดแรกนี้ โปสเตอร์แนะนำให้ใช้ไวยากรณ์ที่คล้ายกัน แต่จะเชื่อมโยงข้อมูลเมตาไปPRIMARY KEYของmetadataตารางฐานข้อมูล

สิ่งที่มีลักษณะเช่นนี้:

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

โดยที่15432จะIDเป็นแถวของตารางที่มีข้อมูลที่จำเป็นและน่าสงสัยดังตัวอย่างด้านล่าง

ความคิดที่สองของฉันคือการจัดเก็บข้อมูลประเภทนี้ในตารางฐานข้อมูลที่มีลักษณะดังนี้:

TABLE: metadata

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

ด้วยวิธีนี้เมตาดาต้าจะมี ID ที่ไม่ซ้ำกันtext_idเป็นต่างประเทศที่สำคัญที่เชื่อมต่อกับตารางการจัดเก็บตำราและมันจะเชื่อมต่อข้อมูลกับข้อความของตัวเองโดยใช้ตัวอักษรที่เรียบง่ายช่วงชดเชย

นี้จะทำเคล็ดลับของการรักษาที่ข้อมูลที่แยกออกมาจากเมตาดาต้าแต่ปัญหาที่ผมได้ทันทีสามารถมองเห็นได้ด้วยวิธีนี้คือข้อความที่จะเป็นพื้นฐานที่ไม่สามารถแก้ไขได้ หรือถ้าผมต้องการที่จะดำเนินการแก้ไขข้อความหลังจากที่นัดของเมตาดาต้าที่ผมจะโดยทั่วไปมีการคำนวณการเพิ่มตัวอักษรหรือลบเมื่อเทียบกับรุ่นก่อนหน้านี้และตรวจสอบว่าแต่ละของการปรับเปลี่ยนนี้จะเพิ่มหรือตัวอักษรลบก่อนหรือหลังจากที่แต่ละของข้อมูลเมตาที่เกี่ยวข้อง

ซึ่งสำหรับฉันเสียงเหมือนวิธีที่ไม่สง่างามจริงๆ

คุณมีพอยน์เตอร์หรือคำแนะนำสำหรับวิธีที่ฉันสามารถแก้ไขปัญหาได้หรือไม่?

แก้ไข 2: ปัญหา XML บางอย่าง

การเพิ่มเคสอื่นซึ่งจะทำให้ค่อนข้างจำเป็นสำหรับการแยกข้อมูลและเมตาดาต้านี้ให้เกิดขึ้น

• สมมติว่าฉันต้องการให้ผู้ใช้ที่ต่างกันมีชุดข้อมูลเมตาที่แตกต่างกันของข้อความเดียวกันโดยมีหรือไม่มีความเป็นไปได้ของผู้ใช้แต่ละคนที่แสดงข้อมูลเมตาของผู้ใช้อื่น

วิธีการแก้ปัญหาใด ๆ ของประเภทมาร์คดาวน์ (หรือ HTML หรือ XML) จะเป็นเรื่องยากที่จะใช้ในจุดนี้ วิธีการแก้ปัญหาเฉพาะในกรณีนี้ที่ฉันสามารถคิดเกี่ยวกับจะมีอีก DB FOREIGN KEYตารางซึ่งจะมีผู้ใช้รุ่นเดียวของข้อความเดิมที่เชื่อมต่อไปยังตารางข้อความเดิมโดยการใช้ที่

ไม่แน่ใจว่านี่มันสง่ามากหรือไม่

• XML มีรูปแบบข้อมูลแบบลำดับชั้น:องค์ประกอบใด ๆ ที่เกิดขึ้นภายในขอบเขตขององค์ประกอบอื่นถือเป็นลูกของมันซึ่งส่วนใหญ่มักจะไม่ใช่กรณีในรูปแบบข้อมูลที่ฉันกำลังมองหา; ในรูปแบบ XML ใด ๆเด็กองค์ประกอบจะต้องปิดก่อนที่พ่อแม่แท็กสามารถปิดการอนุญาตให้ไม่ทับซ้อนกันขององค์ประกอบ

ตัวอย่าง:

<note content="the beginning of the famous placeholder"> Lorem Ipsum ได้บังคับนั่น <comment content="I like the sound of amet/elit"> Amet </note> , consectetuer adipiscing Elit </comment> , <note content="adversative?"> sed เส้นผ่าศูนย์กลาง nonummy อะแดปเตอร์euismod tincidunt UT ปั๊ม dolore นาแบ่งปัน Erat volutpat<note content="funny latin"> </note> </note>

ที่นี่เรามีสองปัญหาที่แตกต่าง:

1. องค์ประกอบที่แตกต่างกันทับกัน:ความคิดเห็นแรกเริ่มต้นภายในโน้ตตัวแรก แต่จบลงหลังจากโน้ตตัวแรกจบลงนั่นคือไม่ใช่ลูกของมัน

2. องค์ประกอบที่ทับซ้อนกัน:โน้ตตัวสุดท้ายและตัวหนาโน้ตซ้อนทับ; อย่างไรก็ตามเนื่องจากเป็นองค์ประกอบเดียวกัน parser จะปิดองค์ประกอบสุดท้ายที่เปิดในการปิดครั้งแรกและองค์ประกอบที่เปิดครั้งแรกที่การปิดครั้งสุดท้ายซึ่งในกรณีนี้ไม่ใช่สิ่งที่ตั้งใจไว้

ฉันจะไปผสมโซลูชั่นของคุณ แต่ฉันจะใช้มาตรฐาน: XML คุณมีรูปแบบเช่นนี้

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.

ทำไมต้อง XML

หากคุณคิดว่ามันเป็นโครงสร้างของเว็บทั้งหมด : เนื้อหา (ข้อความจริง) ที่มีความหมาย - สิ่งที่คุณเรียกเมตะดาต้า - ผ่านแท็ก html

ในแบบที่คุณมีโลกที่ยอดเยี่ยมที่เปิด:

• เครื่องมือแยกวิเคราะห์ฟรี
• ทดสอบวิธีการต่อสู้เพื่อเพิ่มข้อมูลเมตาให้กับเนื้อหา
• ใช้งานง่าย (ขึ้นอยู่กับผู้ใช้ที่คุณกำหนดเป้าหมาย)
• คุณสามารถแตกข้อความดิบโดยไม่ต้องมีเมทาดาทาเนื่องจากเป็นคุณสมบัติมาตรฐานของตัวแยกวิเคราะห์ XML สิ่งนี้มีประโยชน์มากที่จะมีเนื้อหาในเวอร์ชันที่สามารถจัดทำดัชนีของคุณได้ดังนั้นLorem <note>ipsum</note>จะถูกยกระดับเมื่อคุณกำลังค้นหาlorem ips*ตัวอย่าง

ทำไม XML มากกว่า Markdown

เว็บไซต์เช่น stackexchange ใช้ markdown เนื่องจากความหมายของเนื้อหานั้นค่อนข้างง่าย: เน้นลิงค์ / URL รูปภาพส่วนหัว ฯลฯ ดูเหมือนว่าความหมายที่คุณเพิ่มในเนื้อหาของคุณคือ

1. ซับซ้อนยิ่งขึ้น
2. อาจมีการเปลี่ยนแปลงหรือต้องขยาย

ดังนั้นฉันจึงรู้สึกว่า Markdown จะไม่เป็นความคิดที่ดีจริงๆ นอกจากนี้ยัง Markdown ไม่ได้มาตรฐานจริงๆและแยก / ทุ่มตลาดก็อาจจะมีอาการปวดในตูด, มากยิ่งขึ้นmarkdownish ไวยากรณ์ดูโพสต์ Jeff Atwood เกี่ยวกับ WTF ที่เขาได้พบกับการแยก Markdown

เมื่อแยกระหว่างข้อมูลและข้อมูลเมตา

การแยกดังกล่าวไม่ได้บังคับ ฉันคิดว่าคุณกำลังมองหาข้อได้เปรียบที่นำมา:

• ความเป็นไปได้ที่จะมีเนื้อหาดิบโดยไม่มีข้อมูลเมตา
• การแยกข้อกังวล: ฉันไม่ต้องการให้มีผลข้างเคียง / ความซับซ้อนในการจัดการเมทาดาทาเนื่องจากข้อมูลและอย่างอื่น

ข้อกังวลทั้งหมดเหล่านี้จะถูกล้างออกด้วยการใช้ XML จาก XML คุณสามารถดัมพ์เนื้อหาที่ถูกแท็กได้อย่างง่ายดายและข้อมูล / ข้อมูลเมตาจะถูกแยกออกเช่นเดียวกับแอตทริบิวต์และข้อความจริงจะถูกแยกใน XML

นอกจากนี้ผมไม่คิดว่าจริงๆคุณสามารถมีข้อมูลเมตาของคุณทั้งหมดไม่ผูกพันกับข้อมูลของคุณ จากสิ่งที่คุณอธิบายข้อมูลเมตาของคุณเป็นองค์ประกอบของข้อมูลของคุณเช่นการลบข้อมูลนำไปสู่การลบข้อมูลเมตา นี่คือที่ที่คุณเปลี่ยนข้อมูลเมตาจาก HTML / CSS ปกติ CSS ไม่หายไปเมื่อลบองค์ประกอบ html เนื่องจากสามารถนำไปใช้กับองค์ประกอบอื่นได้ ฉันไม่รู้สึกว่าเป็นเช่นนี้ในข้อมูลเมตาของคุณ

การมีเมทาดาทาใกล้เคียงกับข้อมูลเช่นเดียวกับใน XML หรือ Markdown ช่วยให้เข้าใจได้ง่าย (และอาจจะดีบั๊ก) ของข้อมูล นอกจากนี้ตัวอย่างที่คุณให้ในความคิดที่สองของคุณเพิ่มความซับซ้อนบางอย่างเนื่องจากสำหรับแต่ละข้อมูลที่ฉันกำลังอ่านฉันต้องค้นหาตารางข้อมูลเมตาเพื่อรับสิ่งเหล่านี้ หากความสัมพันธ์ระหว่างข้อมูลของคุณกับข้อมูลเมตาของคุณคือ 1: 1 หรือ 1: N แสดงว่า IMO นั้นไร้ประโยชน์อย่างชัดเจนและนำความซับซ้อนมาให้เท่านั้น (เป็นกรณีของ YAGNI)

โซลูชันใช้กรณีและปัญหา

ฉันไม่เห็นด้วยกับคำตอบอื่น ๆ เพียงเพราะในขณะที่การแก้ปัญหาที่ยอดเยี่ยมพวกเขาอาจไม่ใช่คำตอบของคุณ ใช่ XML มีมาร์กอัปคำในตัวย่อ แต่อาจไม่เหมาะกับสถานการณ์ของคุณ มันซับซ้อนเกินไปมีความช่วยเหลือเพียงเล็กน้อยในการรักษาข้อมูลเมตาแยกจากข้อความต้นฉบับ โดยพื้นฐานแล้วมันจะเปลี่ยนทุกอย่างให้อยู่ในรูปของข้อมูลเมตาสร้างชุดข้อมูลที่มีน้ำหนักเกินหนึ่งชุด

เนื่องจากไม่มีวิธีหรือแนวทางแก้ไขที่ถูกต้องวิธีแก้ปัญหาที่ดีที่สุดจะตอบคำถาม:

ระบบจะใช้ข้อมูลอย่างไร?

นอกจากนี้หากคุณลองและถามว่าการออกแบบโซลูชันสามารถเพิ่มคุณค่าให้กับระบบได้อย่างไรในแบบที่มันจะถูกใช้งานคุณจะเข้าใกล้เพื่อค้นหาคำตอบที่หรูหรา

ทำความเข้าใจกับปัญหา

ตกลงพออธิบายได้ลองขุดลงไปที่ปัญหา นี่คือปัญหาที่ฉันเข้าใจ (เห็นได้ชัดว่าการเพิ่มลงไปนี้จะเป็นประโยชน์):

• มีข้อความต้นฉบับอยู่
  • ข้อสันนิษฐานเกี่ยวกับข้อความต้นฉบับนี้:
  • ข้อความนี้อาจมีหรือไม่มีเอกสารอิสระหลายฉบับ
  • ข้อความนี้อาจมีหรือไม่มีการแก้ไขโดยผู้ใช้หนึ่งรายขึ้นไป
  • ข้อความนี้มีข้อมูลที่เกี่ยวข้อง โดยที่ฉันกำลังสมมติ (ถูกต้องฉันหากฉันผิด) ที่เมตาดาต้าที่เกี่ยวข้องและไม่ได้สื่อความหมาย ดังนั้นจึงเก็บข้อมูลที่เกี่ยวข้องกับข้อความต้นฉบับไม่ใช่ข้อมูลที่อธิบายถึงข้อความ ดังนั้นมันจะเก็บบันทึกเกี่ยวกับข้อความต้นฉบับและไม่ใช่ตัวอย่างอธิบายว่าข้อความนั้นเป็นหัวเรื่องที่เป็นตัวหนาและเป็นลิงก์ไปยังเว็บไซต์ ฯลฯ
  • ควรกรองข้อความที่แตกต่างจากข้อมูลเมตาอย่างง่ายดาย
  • ข้อความควรได้รับการป้องกันไม่ให้เสียหายโดยและทำให้ข้อมูลเมตาเสียหาย
• ควรมีวิธีการจัดเก็บข้อมูลที่เกี่ยวข้องกับข้อความต้นฉบับ (ข้อมูลเมตา)
  • ข้อมูลเมตานี้ยังต้องการข้อมูลเมตาของตัวเองซึ่งจะเก็บข้อมูลเช่นข้อมูลของผู้ใช้ (หรือกลุ่ม) ข้อมูลเมตาที่เกี่ยวข้องเช่นคำอธิบายข้อมูลเมตาบอกว่าสภาพอากาศเป็นโน้ตหรือความคิดเห็นหรือ คำอธิบายอื่น ๆ
  • ข้อมูลเมตานี้ (และเป็นข้อมูลเมตา) (ต้องเป็นเมตาดาต้า) ต้องทนต่อการเปลี่ยนแปลงในข้อความต้นฉบับการแก้ไขข้อมูลเมตาและการเปลี่ยนแปลงข้อมูลเมตา (เมตาดาต้า)
  • ข้อมูลเมตา (+ Meta-Metadata) จะต้องมีโครงสร้างที่ดีและง่ายต่อการสืบค้นและจัดทำดัชนีหรือแม้แต่เข้าร่วมในเชิงสัมพันธ์กับชุดข้อมูลอื่น ๆ ลักษณะเชิงสัมพันธ์ของข้อมูลเมตาไม่เพียง แต่ถูก จำกัด ไว้ที่แบบสอบถาม แต่ยังอำนวยความสะดวกในการอัปเดตหรือเขียนและแก้ไขข้อมูลเมตาอันเป็นผลมาจากกิจกรรมข้อมูลเชิงสัมพันธ์
  • ค่าของเมตาดาต้า (+ Meta-Metadata) ที่อยู่ในนั้นมากที่เกี่ยวข้องกับธรรมชาติ มันจะโต้ตอบได้ทันทีเมื่อมันหลุดออกมามันเกี่ยวข้องกับข้อความต้นฉบับ ดังนั้นความสมบูรณ์ของความสัมพันธ์กับข้อความต้นฉบับจึงเป็นสิ่งจำเป็นในการออกแบบ
• ข้อสันนิษฐานอื่น ๆ เกี่ยวกับลักษณะของปัญหาและวิธีการใช้คือ:
  • การเข้าถึงระบบที่ต่างกันพร้อมกัน กล่าวคือผู้ใช้อาจต้องการดูข้อความและแก้ไขข้อมูลเมตาในเวลาเดียวกันกับผู้ดูแลระบบ (หรือกระบวนการอื่น) กำลังดำเนินการค้นหาข้อมูลเชิงสัมพันธ์ในเมตาดาต้าที่มีโครงสร้าง
  • ระบบจะมีผู้ใช้หลายคน
  • ระบบมีความทันสมัย กล่าวคือมันไม่ได้ถูก จำกัด ด้วยพื้นที่เก็บข้อมูลหรือความเร็วในการประมวลผลหรือสิ่งจำเป็นตามเวลาจริง ฟังก์ชันการทำงานที่มุ่งเน้นความสมบูรณ์และวัตถุประสงค์นั้นมีความสำคัญสูงกว่าข้อ จำกัด ของทรัพยากรการคำนวณทางกายภาพ
  • มีโอกาส (แม้ว่าจะต่ำ) ที่การใช้งานและฟังก์ชันการทำงานของระบบอาจมีการเปลี่ยนแปลงหรือเปลี่ยนแปลงไปบ้างตามที่ใช้ในระบบ

การสร้างโซลูชันออกแบบ

การทำความเข้าใจปัญหาตามที่ได้อธิบายไว้ข้างต้นตอนนี้ฉันจะเริ่มแนะนำวิธีแก้ไขที่เป็นไปได้และแนวทางที่มุ่งหวังที่จะแก้ปัญหาข้างต้น

ส่วนประกอบ

ดังนั้นฉันจะเห็นว่าจะต้องมีระบบการเข้าถึงของผู้ใช้ที่สร้างขึ้นเอง มันจะกรองข้อมูลเมตาที่เกี่ยวข้องและไม่เกี่ยวข้องออกจากข้อความต้นฉบับ มันจะอำนวยความสะดวกในการแก้ไขและการดูข้อมูลเมตาลงในข้อความ มันจะรับรองความสมบูรณ์ของความสัมพันธ์ระหว่างข้อมูลเมตากับข้อความต้นฉบับ มันจะจัดโครงสร้างข้อมูลเมตาและนำเสนอแหล่งข้อมูลไปยังระบบข้อมูลเชิงสัมพันธ์ มันมักจะให้โฮสต์ของฟังก์ชั่นขับเคลื่อนวัตถุประสงค์อื่น ๆ

โครงสร้าง

ดังนั้นเนื่องจากเป็นสิ่งสำคัญที่จะต้องรักษาความสมบูรณ์ของข้อมูลเมตาให้เป็นข้อความดั้งเดิมวิธีที่ดีที่สุดในการรับรองความถูกต้องนี้คือการทำให้ข้อมูลเมตาสอดคล้องกับข้อความต้นฉบับ สิ่งนี้จะให้ประโยชน์ที่ข้อมูลต้นฉบับสามารถแก้ไขได้อย่างมั่นใจโดยไม่ทำลายความสมบูรณ์นี้

ข้อกังวลเกี่ยวกับวิธีการนี้คือความเสียหายของข้อมูลเมตาโดยข้อมูลดั้งเดิมและในทางกลับกัน การจัดทำดัชนีและโครงสร้างของเมตาดาต้าที่เพียงพอและเมทาดาทา (เมตาดาต้า) ในลักษณะที่ช่วยให้สามารถสืบค้นและอัปเดตและเข้าถึงได้อย่างมีประสิทธิภาพ การกรองข้อมูลเมตาได้ง่ายจากข้อความต้นฉบับ

ด้วยสิ่งนี้ในใจฉันขอแนะนำให้ส่วนหนึ่งของการแก้ปัญหาจะขึ้นอยู่กับวิธีการใช้ตัวอักษร ESCAPEภายในข้อความต้นฉบับ สิ่งนี้ไม่เหมือนกับการออกแบบภาษามาร์กอัปของคุณเองหรือใช้ภาษามาร์กอัปที่มีอยู่เช่น XML หรือ HTML มันง่ายต่อการออกแบบตัวอักษร ESCAPEที่มีค่าศูนย์หรือใกล้ศูนย์โอกาสที่มีอยู่ในข้อความต้นฉบับ

คำแนะนำของฉันสำหรับคุณในเรื่องนี้คือการพิจารณาข้อมูลต้นฉบับอย่างรอบคอบและพยายามกำหนดลักษณะของโค้ดเพจที่เก็บไว้ในนั้นจากนั้นมองหาตัวละครในอุดมคติหรือ ลำดับตัวอักษรที่ไม่น่าจะเกิดขึ้นหรือเป็นไปไม่ได้ ตัวอย่างเช่นใน ASCII มีอักขระควบคุมในตัวที่มีค่าไบต์ที่ไม่เคยใช้ในส่วนต่อประสานผู้ใช้มาตรฐาน เดียวกันสามารถพูดได้สำหรับระบบข้อมูลตามตัวอักษรหรือข้อมูลเชิงสัมพันธ์ เพียงระวังตัวแปลงสัญญาณข้อมูลไบนารี ขึ้นอยู่กับลักษณะของข้อมูลต้นฉบับอาจเป็นประโยชน์ในการสร้างตัวแยกวิเคราะห์ที่ยืนยันการค้นพบลำดับการควบคุมบางทีโดยดูที่ข้อมูลที่ถูกหลบหนีและตรวจสอบความถูกต้องสมบูรณ์ด้วยการตรวจสอบโครงสร้างของการหลบหนีอย่างง่าย data หรือแม้กระทั่งโดยรวมถึงอักขระควบคุมที่คำนวณสำหรับแต่ละลำดับข้อมูลที่หลบหนี

ตัวอย่างข้อมูลที่มี Escape Sequences

นี่คือเรื่องราวของผู้ชายคนหนึ่ง >>>> (#) ทำไมเรื่องราวนี้ถึงผู้ชายไม่ใช่ผู้หญิง? (#) ( ) ผู้ใช้ :: 77367 ( ) ความคิดเห็นของผู้จัดการ ( ) DataID :: 234234234 >>>> ชายคนหนึ่งที่ไปตัดหญ้า ไปตัดหญ้าทุ่งหญ้า ชายคนนั้นไปกับสุนัขของเขา >>>> (#) ถามลูกค้าว่าเรื่องราวจะดีกว่ากับแมวแทน (#) >>>> เพื่อตัดหญ้าในทุ่งหญ้า ดังนั้นตอนนี้นี่เป็นเรื่องราวของชายคนหนึ่งและสุนัขของเขาที่ไปตัดหญ้าในทุ่งหญ้า

ชายคนหนึ่งและสุนัขของเขาไปตัดหญ้าทุ่งหญ้าไปตัดหญ้าทุ่งหญ้าทุ่งหญ้ามาถึงภูเขา >>>> (#) ฟังดูดีกว่ามากเมื่อใช้ฟอเรสต์ (**) หมายเหตุข้อเสนอแนะ (#) >>>>

ชายและสุนัขของเขาและภารกิจของเขาเพื่อตัดหญ้าทุ่งหญ้าทุ่งหญ้าที่ไปถึงภูเขานั้นจะมาถึงเมื่อข้ามแม่น้ำเท่านั้น

ข้อมูลตัวอย่างที่ไม่มี Escape Sequences

นี่คือเรื่องราวของผู้ชายคนหนึ่ง ชายคนหนึ่งที่ไปตัดหญ้าทุ่งหญ้าไปตัดหญ้าที่ทุ่งหญ้า ชายผู้นั้นไปกับสุนัขเพื่อตัดหญ้าในทุ่งหญ้า ดังนั้นตอนนี้นี่เป็นเรื่องราวของชายคนหนึ่งและสุนัขของเขาที่ไปตัดหญ้าในทุ่งหญ้า

ชายคนหนึ่งและสุนัขของเขาไปตัดหญ้าทุ่งหญ้าไปตัดหญ้าทุ่งหญ้าทุ่งหญ้ามาถึงภูเขา

ชายและสุนัขของเขาและภารกิจของเขาเพื่อตัดหญ้าทุ่งหญ้าทุ่งหญ้าที่ไปถึงภูเขานั้นจะมาถึงเมื่อข้ามแม่น้ำเท่านั้น

เห็นได้ชัดว่านี่คือการแยกวิเคราะห์ได้ง่ายไม่ซับซ้อนเป็นภาษา Mark-up ทั้งหมดและปรับให้เข้ากับวัตถุประสงค์ของคุณได้อย่างง่ายดาย

แก้ไขหรือยัง ฉันจะบอกว่าไม่ วิธีการแก้ปัญหาของเรายังมีบางหลุม การเข้าถึงการจัดทำดัชนีและโครงสร้างของข้อมูลนี้ไม่ดี นอกจากนี้ยังไม่เหมาะสมที่จะสืบค้นไฟล์นี้ (หรือหลายไฟล์) ในเวลาเดียวกันกับการแก้ไข

เราจะแก้ปัญหานั้นอย่างไร

ฉันจะแนะนำDATA ALLOCATION TABLEเป็นส่วนหัวของเอกสาร ฉันยังอยากจะขอแนะนำให้ดำเนินการทำธุรกรรมตาราง UPDATE คิว ให้ฉันอธิบาย ผู้ออกแบบระบบไฟล์โดยเฉพาะอย่างยิ่งระบบไฟล์ดิสก์แบบหมุนได้เผชิญกับความท้าทายในการออกแบบที่คล้ายกับสิ่งที่คุณได้อธิบายไว้ข้างต้น พวกเขาจำเป็นต้องฝังข้อมูลเกี่ยวกับไฟล์บนดิสก์พร้อมกับข้อมูล ทางออกที่ดีสำหรับความสมบูรณ์ของความสัมพันธ์ของข้อมูลนี้คือการทำซ้ำมันในFile Allocation Table (FAT)

ซึ่งหมายความว่าสำหรับแต่ละรายการข้อมูลเมตาของแต่ละบุคคลมีรายการที่สอดคล้องกันในตารางการจัดสรรข้อมูล ดังนั้นรวดเร็วโครงสร้างและความสัมพันธ์และเป็นอิสระจากข้อมูลต้นฉบับ หากคำสั่งหรือร่วมหรือการปรับปรุงจะต้องมีการดำเนินการเกี่ยวกับเมตาแล้วมันจะกระทำได้ง่ายโดยเพียงแค่การเข้าถึงตารางการจัดสรรข้อมูล

ต้องมีการดูแลอย่างชัดเจนเพื่อให้แน่ใจว่าข้อมูลเมตาในบรรทัดเดิมเป็นภาพสะท้อนที่แท้จริงของข้อมูลตารางการจัดสรรข้อมูล นั่นคือที่มาของคิวธุรกรรมของตารางการปรับปรุงตารางเข้ามาทุก ๆ การเปลี่ยนแปลงการเพิ่มหรือการลบข้อมูลเมตาจะไม่ได้อยู่ในข้อมูลที่เป็นของตัวเอง คิวจะตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงทั้งหมดนั้นเกิดขึ้นกับทั้งข้อมูลในบรรทัดและตารางหรือไม่มีการเปลี่ยนแปลงเลย นอกจากนี้ยังอนุญาตให้ทำการอัพเดตแบบอะซิงโครนัสตัวอย่างเช่นข้อมูลเมตาทั้งหมดของผู้ใช้บางรายสามารถลบได้โดยการเรียกใช้คำสั่งลบในคิว หากข้อมูลเมตาแบบอินไลน์ถูกล็อคและใช้งานอยู่คิวจะไม่ทำการเปลี่ยนแปลงใด ๆ จนกว่าจะสามารถทำได้ทั้งกับข้อมูลตารางและข้อมูลแบบอินไลน์

นี่เป็นคำถามทางวิศวกรรมทั่วไปที่ตัวเลือกทั้งหมดของคุณมีการแลกเปลี่ยนที่แตกต่างกันและที่ดีที่สุดขึ้นอยู่กับสิ่งที่สำคัญสำหรับคุณ น่าเสียดายที่คุณยังไม่ได้รับข้อมูลเพียงพอที่จะทำการตัดสินใจ

คุณยังไม่ได้พิจารณาถึงปัญหาความหมายที่สำคัญ ให้บอกว่าข้อความต้นฉบับคือ

บ๊อบเพื่อนของฉันให้ฉันห้าดอลลาร์

มีคนเพิ่มความคิดเห็นเกี่ยวกับคำว่า "Bob"

บ๊อบเป็นคนงี่เง่าที่สมบูรณ์

จากนั้นข้อความต้นฉบับจะได้รับการแก้ไข

เจนยืมบ๊อบห้าดอลลาร์ซึ่งต่อมาเขาให้ฉันยืม

คุณอาจจะรู้สึกว่ากรณีนี้โดยใช้อัลกอริทึมการจับคู่ข้อความเช่นสิ่งที่ใช้ในการแสดงไฟล์ diff แต่ตัวอักษร offsets จะทำให้ข้อมูลเมตาแนบกับ "แจน" ใน "เจน"

ที่แย่กว่านั้นคือถ้าข้อความถูกแก้ไข

เพื่อนของฉันสตีฟให้ฉันห้าดอลลาร์

คุณสามารถหาวิธีแนบ metadata ไปยัง "Steve" ได้ แต่คุณจะรู้ได้อย่างไรว่ามันนำไปใช้?

คุณได้ตัดสินใจด้วยหรือไม่ว่าตัวเมทาดาทานั้นสามารถมีเมทาดาทาได้หรือไม่ ที่อาจเปลี่ยนการใช้งานของคุณ

นอกเหนือจากปัญหาความหมายมันไม่ชัดเจนว่าคุณกำลังทำอะไรกับข้อมูล ฉันคิดว่าอาจไม่สะดวกที่จะมีข้อความต้นฉบับ "ปนเปื้อน" ด้วยมาร์กอัปใด ๆ แต่แล้วคุณก็โอเคกับการมีค่า ID ในนั้น ซึ่งไม่สมเหตุสมผลถ้าข้อมูลเมตาใช้กับส่วนของข้อความแทนที่จะถูกแทรกลงในจุดในข้อความ

ฉันเดาว่าเพื่อวัตถุประสงค์ในการจัดเก็บข้อความที่ทำเครื่องหมายไว้นั้นง่ายกว่าหรือตัวเลือกที่สองจะใช้ SQL ทั้งหมดและการมีข้อความและมาร์กอัปแสดงโดยลำดับชั้นโหนด - โดยทั่วไปคือ DOM ในรูปแบบตาราง หากข้อมูลของคุณเป็นแบบลำดับชั้นอาจง่ายกว่าการใช้ XML และรับตัวแยกวิเคราะห์ที่มีอยู่ฟรีเทียบกับการเขียนของคุณเอง

มีความเป็นไปได้ค่อนข้างมากที่จะมีวิธีแก้ปัญหาที่ค่อนข้างง่ายพอสำหรับสถานการณ์ที่แน่นอนของคุณ แต่ฉันไม่สามารถบอกคุณได้ว่าอะไรเป็นเพราะมันขึ้นอยู่กับสิ่งที่คุณพยายามทำโดยละเอียด

ฉันขอแนะนำให้คุณแค็ปซูลกลยุทธ์ใด ๆ ที่คุณเลือกให้มากที่สุดเท่าที่จะทำได้แม้ว่าจะเป็นการยากที่จะทำหากการใช้งานจำนวนมากของคุณต้องปรากฏในคิวรี SQL จำนวนมาก

ขออภัยที่คำตอบนั้นกระจัดกระจายและเต็มไปด้วย "มันขึ้นอยู่กับ" แต่คำถามการออกแบบโลกแห่งความจริงเป็นเช่นนั้น

ฉันคิดว่าคำแนะนำจากผู้ตอบก่อนหน้าคนที่คุณพูดถึงคำถามของคุณ) เป็นคนดีมาก

มันจะทำงานในลักษณะเดียวกับที่เราโพสต์ลิงก์ในเว็บไซต์ StackExchange แต่ข้อมูลจะอยู่ในตารางอื่น ประโยชน์ที่ได้รับคือคุณมีข้อมูลที่แยกจากกันดังนั้นจึงสามารถสืบค้นและทำดัชนีได้ ในการแก้ไขข้อความคุณสามารถตรวจสอบ ID เมทาดาทาที่ถูกลบและล้างตารางเมทาดาทา

ปัญหาเล็ก ๆ อย่างเดียวที่คุณพูดคือการแยกวิเคราะห์ แต่คุณสามารถจัดการกับมันได้อย่างง่ายดาย

ให้บอกว่าฉันมีข้อความ:

Loren ipsum dolor amet amet, consetetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

ฉันเพิ่มบันทึกเช่นนี้:

Lorem ipsum dolor sit amet, consetetuer adipiscing elit, sed diam [@ 123, # 456,2w] ไม่ได้เป็นเช่นนั้นเลย

[@123,#456,2w]หมายถึง: user_id = 123, note_id = 456 และข้อความที่ทำเครื่องหมายโดยหมายเหตุนี้ครอบคลุม 2 คำถัดไป (อาจเป็นตัวอักษร ( c), ประโยค ( s), ประโยค ( ), paragraps ( p) หรืออะไรก็ตาม) ไวยากรณ์ที่แน่นอนอาจแตกต่างกันแน่นอน

ในข้อความตัวแก้ไขข้อความธรรมดาบรรณาธิการข้อความสามารถจัดเก็บได้อย่างง่ายดายที่ส่วนท้ายของเอกสารเช่นเดียวกับเชิงอรรถ Markdown

ในเครื่องมือแก้ไขข้อความที่มีการจัดรูปแบบหมายเหตุนี้สามารถแสดงในข้อความเป็นไอคอนและข้อความที่ทำเครื่องหมายไว้สามารถเน้นในบางวิธี จากนั้นผู้ใช้สามารถลบบันทึกเช่นเดียวกับตัวอักษรปกติด้วยDelหรือBackspaceและแก้ไขด้วยโหมดการแก้ไขพิเศษบางประเภท ฉันจินตนาการว่าการปรับขนาดพื้นที่ที่บันทึกไว้ด้วยเมาส์และแก้ไขข้อความบันทึกย่อด้วยหน้าต่างป๊อปอัป

ข้อดี:

• ไปเป็นอย่างดีด้วย "ทางแยก" เนื่องจากคุณทำเครื่องหมายออฟเซ็ต (โดยปริยายโดยตำแหน่งของโน้ตในข้อความ) และความยาวสำหรับแต่ละโน้ต
• รองรับสภาพแวดล้อมที่มีผู้ใช้หลายคน (อันที่จริงแล้วสิ่งนี้ต้องการการวิจัยที่ลึกกว่าและคุณอาจต้องจัดการกับบางอย่างเช่นการเปลี่ยนแปลงการดำเนินงานของ Google Waveซึ่งสมองของฉันไม่สามารถรับมือได้)
• สามารถแก้ไขได้ด้วยโปรแกรมแก้ไขข้อความทั้งแบบธรรมดาและแบบธรรมดา
• คุณสามารถจัดการการแก้ไขได้อย่างง่ายดายเนื่องจากเครื่องหมายทั้งหมดอยู่ในตำแหน่ง - เมื่อคุณแก้ไขข้อความก่อนที่เครื่องหมายระบุตำแหน่งเครื่องหมายเพียงเลื่อนไปพร้อมกับข้อความอื่น ๆ
• แยกวิเคราะห์ได้ง่าย
• ไม่ต้องการฐานข้อมูลภายนอก แต่คุณยังสามารถใช้ฐานข้อมูลได้หากคุณต้องการ
• สามารถผสมกับ Markdown หรือ XML หากคุณเลือกไวยากรณ์ที่ไม่เป็นการรบกวน

ข้อเสียสำหรับการแก้ไขข้อความธรรมดา:

• คุณไม่สามารถดูพื้นที่ในข้อความที่ทำเครื่องหมายด้วยบันทึกย่อ (เว้นแต่คุณจะเน้นข้อความธรรมดาซึ่งเป็นตัวเลือกด้วย) แต่เพียงแค่สถานที่ที่โน้ตเริ่มต้น นี่คือการชดเชยโดยความสามารถในการเลือกหน่วยความยาวโดยพลการ: ตัวอักษร, คำ, ประโยค, ย่อหน้า
• คุณสามารถแก้ไขข้อความภายใต้บันทึกย่อโดยไม่สังเกตเห็นโดยเฉพาะอย่างยิ่งถ้าบันทึกมีขนาดค่อนข้างยาว (เช่น 2+ ย่อหน้า) สามารถชดเชยโดยกลไกการควบคุม revison ซึ่งเปรียบเทียบข้อความภายใต้บันทึกย่อแต่ละรายการกับรุ่นก่อนหน้าและแจ้งให้ผู้ใช้ทราบว่ามีการเปลี่ยนแปลงหรือไม่

ข้อเสียทั่วไป:

• มีปัญหากับผู้ใช้หลายคนที่แก้ไขข้อความเดียวกัน แต่ฉันคิดว่ามันหลีกเลี่ยงไม่ได้อยู่ดี ฉันไม่ใช่ผู้เชี่ยวชาญในสาขานี้