05-Jul-2014 18:02, Wanderer пишет:
On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:
Yes they do. http://en.wikipedia.org/wiki/Database_index#Clustered
You can obviously only do that for one index.
Ugh, and what happens in such hypothetical database if you update its
first row so it becomes 1 byte longer than before?
Provision some extra space in each record. DBs do this all the time,
regardless of layout.
Total reordering of
the whole database just to maintain that index? That's very similar to
the issue I posted above - wasteful shuffling of big amounts of memory
only because D's structs don't support indirection by their nature, and
you can't swap two elements without copying their whole contents.
It's funny to see how an _ability_ to avoid indirection can be framed as
a problem. Nothing prevents having an array of pointers to structs or
just using classes if desired.
On the contrary sorting an array of pairs of integers in say Java is
shamefully inefficient. No wonder packed objects (=value types) are
coming to Java, to address these sorts of need.
http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
John Colvin said above that structs can be useful, even together with
sorting (and similar algorithms), if they are relatively small. This is
true, but this design is not scalable. As soon as your program evolves
and your struct grows with more and more fields, D's sort on it becomes
slower and slower, proportionally to the struct's size. That's not the
best behavior IMHO.
Ehm. One can always redesign struct layout to push stuff out through an
indirection. And it's not like structs grow organically on their own ;)
In the same vane design of ref-to-instance is not scalable with millions
of items scattered across the memory causing awful cache miss rate (as
the indirection got to be crossed to compare things), not to mention the
memory wasted per each object.
--
Dmitry Olshansky
