มีตัวเลือกใดให้เลือก: แอตทริบิวต์ XML หรือโหนดย่อย

15

เราต้องการส่งออกข้อมูลบางส่วนจากฐานข้อมูลของเราเป็น XML ยกตัวอย่างเช่นPersonสามารถมีage,nameและบางส่วนคุณสมบัติอื่น ๆ

เรามีสองตัวเลือกในการกำหนดรูปแบบ XML

ตัวเลือก # 1:

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

ตัวเลือก # 2:

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

ดังนั้นความแตกต่างระหว่างคำจำกัดความของโหนดย่อยหรือคุณลักษณะคืออะไร? และประโยชน์ของแต่ละตัวเลือกคืออะไร

xml

— ZijingWu
แหล่งที่มา

2

นี่เป็นสำเนาซ้ำซ้อนของstackoverflow.com/questions/152313/xml-attributes-vs-elements

— Pierre Arlaud

2

แม้ว่าจะมีการถามเกี่ยวกับ Stack Overflow ในปี 2008แต่สิ่งนี้ดูเหมือนจะเป็นการตัดสินใจออกแบบและอยู่ในหัวข้อที่นี่

— โธมัสโอเวนส์

9

ไม่มีเอกสาร / แนวปฏิบัติที่ดีที่สุดสำหรับเรื่องนี้อย่างชัดเจน แต่ให้พิจารณาทางเลือกอื่น ๆ ตามที่คุณมี:

เป็นข้อความองค์ประกอบ:

มันจะง่ายกว่าที่จะแสดงข้อมูลเป็น xhtml ฯลฯ ที่เนื้อหาข้อความถือว่าเป็นข้อความแทนที่จะเป็นมาร์กอัปหรือเมตาดาต้า
อาจมีมากกว่าหนึ่ง หากคุณต้องการเนื้อหาลูกที่มีหลายยุคหรือแถวชื่อแอตทริบิวต์จะไม่อนุญาต
หากคุณต้องการข้อมูลเมตาระดับแถวคุณมีตัวเลือกในการใช้คุณสมบัติของ<name>หรือ<age>เพื่อจุดประสงค์นี้

เป็นคุณสมบัติ:

XML มีขนาดเล็กลง
XSLT และ DocTypes นั้นง่ายต่อการระบุ
คุณไม่ต้องกังวลเกี่ยวกับช่องว่าง (ช่องว่างภายใน, การเยื้อง, การขึ้นบรรทัดใหม่) หรือรายการอื่น ๆ ที่สามารถนำมาใช้ (ความเห็น, PI) ในพื้นที่ PCDATA (ข้อความองค์ประกอบ)
มีได้เพียงอันเดียวเท่านั้น! คุณไม่ต้องกังวลกับเนื้อหาย่อยที่มีหลายแอageททริบิวต์

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

— rolfl
แหล่งที่มา

2

ไม่มีค่าอะไรเลย: ถ้าคุณจะใช้ XSLT ไม่มีเหตุผลที่จะไม่ใช้แอตทริบิวต์ บางทีถ้าคุณกำลังจะทำอะไรบางอย่างของ XML + CSS หรือคุณกำลังจะใช้ XSLT ของคนอื่น ...

— DougM

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

— Doc Brown

9

หลักการออกแบบ XML: เมื่อใดที่จะใช้องค์ประกอบกับแอตทริบิวต์โดย Uche Ogbuji จาก IBM อาจเป็นหนึ่งในแหล่งข้อมูลที่ดีที่สุดในเรื่องนี้

หัวใจสำคัญของการตัดสินใจก็คือคุณลักษณะต่าง ๆ นั้น 'เสร็จสิ้น' คุณไม่สามารถเปลี่ยนแปลงหรือแก้ไขพวกเขาหรือซ้อนพวกเขา คำสั่งเหล่านี้มีความเป็นอิสระและชัดเจนภายในองค์ประกอบ (คุณไม่สามารถมีสองสิ่งเดียวกัน)

หากข้อ จำกัด ใด ๆ เหล่านี้เป็นสิ่งที่อาจมีการเปลี่ยนแปลงให้จัดทำข้อมูลเป็นโหนดลูกของ XML

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

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

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

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

Uche Ogbuji ระบุหลักการสำคัญสามข้อในการออกแบบรูปแบบ xml อย่างเหมาะสม ต่อไปนี้เป็นคำพูดสั้น ๆ จากเอกสารที่เชื่อมโยงด้านบน

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

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

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

2

สิ่งที่ควรพิจารณาอีกประการหนึ่งของ beyong rolfl คือจำนวนของฟิลด์
คุณลักษณะจำนวนน้อยกลายเป็นความยุ่งเหยิงและอ่านยาก (ซึ่งสมมติว่าคุณต้องการให้ xml ของคุณเป็นมนุษย์ที่อ่านได้ แต่ในฐานะโปรแกรมเมอร์คุณจะต้องทำการทดสอบอย่างน้อย)

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

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

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

— jwenting
แหล่งที่มา

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

— ZijingWu

2

สำหรับแท็ก Persons เป็นเรื่องปกติที่จะมีแท็กของ Person มากขึ้นมันสมเหตุสมผลแล้วรายการของ Persons มีเอนทิตี้บางอย่างไม่ใช่แอ็ตทริบิวต์

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

หากเราคิดในบริบท HTML คุณไม่มีอินพุตที่มีแท็กชื่อที่มีค่าใช่ไหม

— Silviu Burcea
แหล่งที่มา