There are few things about speed<div><ul><li>simplicity<br>default setup shall satisfy initial use of the database</li><li>need for production optimization<br>if is the query serving every day, then there is the rule, optimization step will come later or sooner.</li>
<li>required additional index resouces<br>like time and CPU to generate or update them, space requirements...</li></ul><div>I like BaseX for the simplicity to start and use it.</div><div>Optimization is often not so much difficult or needed, but wiki entry about optimization would be good tool. Extra indexing options too.</div>
<div><br></div><div>Jan</div><div><br><div class="gmail_quote">2011/3/1 Christian Grün <span dir="ltr">&lt;<a href="mailto:christian.gruen@gmail.com">christian.gruen@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
...this is what I can confirm. An optional inclusion of direct element<br>
nodes references might indeed be the best choice to keep BaseX<br>
database instances light-weight (exactly for this reason, the<br>
full-text index is optional as well). But we&#39;ll at least have another<br>
look at the addition of pos. preds in short term.<br>
<br>
Christian<br>
__________________________<br>
<div><div></div><div class="h5"><br>
On Tue, Mar 1, 2011 at 7:11 AM, Jan Vlčinský (CAD)<br>
&lt;<a href="mailto:jan.vlcinsky@cad-programs.com">jan.vlcinsky@cad-programs.com</a>&gt; wrote:<br>
&gt; Hi<br>
&gt; I also agree, that speed is always strongly demanded commodity.<br>
&gt; However, learning from XML database implementations, I would be careful with<br>
&gt; taking enough space as granted.<br>
&gt; My original preferred XML database implementation was Sedna XML database,<br>
&gt; but space requirements were sometime too high like 100 times the space of<br>
&gt; original docs. They were giving some hints, how to make it smaller by<br>
&gt; restructuring used XML structures, but this completely destroys the beauty<br>
&gt; of XML databases offering solution for just existing documents one has at<br>
&gt; the moment without any additional constrains.<br>
&gt; Jan<br>
&gt;<br>
&gt; 2011/3/1 NewIntellectual &lt;<a href="mailto:newintellectual@gmail.com">newintellectual@gmail.com</a>&gt;<br>
&gt;&gt;<br>
&gt;&gt; One more thought on the whole issue of database size, particularly<br>
&gt;&gt; indices: I would say that time is a far greater consideration than disk<br>
&gt;&gt; space now. A terabyte is cheap; but there is no way to add more seconds per<br>
&gt;&gt; second.<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; BaseX-Talk mailing list<br>
&gt;&gt; <a href="mailto:BaseX-Talk@mailman.uni-konstanz.de">BaseX-Talk@mailman.uni-konstanz.de</a><br>
&gt;&gt; <a href="https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk" target="_blank">https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ing. Jan Vlčinský<br>
&gt; CAD programy<br>
&gt; Slunečnicová 338/3, 734 01 Karviná Ráj, Czech Republic<br>
&gt; tel: +420-597 602 024; mob: +420-608 979 040<br>
&gt; skype: janvlcinsky; GoogleTalk: <a href="mailto:jan.vlcinsky@gmail.com">jan.vlcinsky@gmail.com</a><br>
&gt; <a href="http://cz.linkedin.com/in/vlcinsky" target="_blank">http://cz.linkedin.com/in/vlcinsky</a><br>
&gt;<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div name="sig_b0a60a250d" style="margin-top:2em;margin-right:0pt;margin-bottom:2em;margin-left:0pt"><b>Ing. Jan Vlčinský</b><br><small>
CAD programy<br>
Slunečnicová 338/3,  734 01 Karviná Ráj, Czech Republic<br>
tel: +420-597 602 024;
mob: +420-608 979 040<br>
skype: janvlcinsky;
GoogleTalk: <a href="mailto:jan.vlcinsky@gmail.com" target="_blank">jan.vlcinsky@gmail.com</a><br>
<a href="http://cz.linkedin.com/in/vlcinsky" target="_blank">http://cz.linkedin.com/in/vlcinsky</a>
</small></div><br>
</div></div>