←back to thread

275 points whatisabcdefgh | 10 comments | | HN request time: 0.216s | source | bottom
1. librasteve ◴[] No.45133139[source]
wouldn’t an XML database be easier?
replies(7): >>45133167 #>>45133236 #>>45133299 #>>45133364 #>>45134339 #>>45134462 #>>45136358 #
2. floating-io ◴[] No.45133167[source]
Does an embeddable XML database engine exist at a similar level of reliability?
3. supportengineer ◴[] No.45133236[source]
No.
4. renecito ◴[] No.45133299[source]
LOL!
5. duskwuff ◴[] No.45133364[source]
You can't* index into XML. You have to read through the whole document until you get to the part you want.

*: without adding an index of your own, at which point it isn't really XML anymore, it's some kind of homebrew XML-based archive format.

replies(1): >>45138248 #
6. jsight ◴[] No.45134339[source]
They could resurrect xindice!
7. Zambyte ◴[] No.45134462[source]
Why?
8. HelloNurse ◴[] No.45136358[source]
You can store the content of a XML document in a database faithfully enough to reconstruct it exactly. Any system that can produce XML documents is a "XML database".
9. Mikhail_Edoshin ◴[] No.45138248[source]
This applies to any secondary index. The data themselves can only be ordered by a single criteria. It may be a meaningful one, but I guess in most cases it is merely the internal ID, which means you will have to scan the whole table too.

XML was meant for documents so in most cases the sequence of elements is given. But technically if I compose XML myself I can lay it out the way I want and thus can have it sorted too. This means it will be directly searchable without an index: read a bit at the middle, find an element name, see where we are, choose head or tail, repeat.

replies(1): >>45143694 #
10. duskwuff ◴[] No.45143694{3}[source]
Blindly seeking into XML data is a risky, error-prone approach. It's not impossible to do, but doing it correctly is difficult - even if the tags you're looking for are unique, there are a lot of messy edge cases involving comments and <!CDATA> blocks.