[
Lists Home |
Date Index |
Thread Index
]
elliotte (in support)
i just want to add here that we have been using ascii storage in our
database for everything including numbers for over 20 years and we still
run as fast, faster in fact, than databases that use binary formats
(integers, doubles, etc). i pointed this out in my paper on the subject.
the problem was, and remains, that conversion to and from readable
formats is very "time expensive" (slow) and very often the data is not
manipulated at all, so you're always copping conversion charges. but not
always manipulation charges.
the only possible saving can come from transfer speeds and that is
domain dependent - how many significant places are you swapping for
always having to send 16 bytes (or whatever precision you're using).
and the binary is only useful for the numbers.
i remain committed to text only formats, particularly for data
interchange
rick
On Sat, 2004-04-17 at 01:13, Elliotte Rusty Harold wrote:
> At 9:00 AM -0400 4/16/04, Stephen D. Williams wrote:
>
> >Binary doesn't imply there isn't any well-formedness checking, obviously.
>
> For once I agree. Obviously, binary doesn't imply that. However, in
> practice, the binary formats I do see rarely do as much
> well-formedness checking as a parser does, either in the XML domain
> or elsewhere. Speed gains that come from eliminating well-formedness
> checking should not be attributed to a binary format. Similar gains
> can be had by eliminating well-formedness checking when processing
> real XML (Not that I recommend doing that of course).
>
> >Incremental, or lazy evaluation, well-formedness is useful and
> >potentially protects applications just as well as full
> >well-formedness with better efficiency.
>
> Simply not true. It doesn't come close to protecting applications as
> well as full checking.
>
> >Allowing the application the option of avoiding repetitive or
> >unncessary well-formedness checking is a valid strategy. Your
> >argument that data that a 'program' receives must always be fully
> >validated in any situation could just as easily be extended to
> >libraries and modules receiving DOM references or similar. What one
> >system may do with libraries or software modules, another may do
> >with plugins and another may do with n-tier processing steps. Does
> >the granularity of the implementation somehow necessarily change the
> >fundamental likelihood of corruption?
>
> All published interfaces should verify their preconditions. Libraries
> should (and indeed the ones I write do) verify that input passed to
> them from outside the library is correct. For instance, if I publish
> an interface that expects a DOM object that can be serialized as
> namespace well-formed XML, and you pass me a DOM object that can't
> be, then the precondition is violated. The method should detect this
> and throw an exception. And indeed this is exactly what I do:
>
> http://www.cafeconleche.org/XOM/apidocs/nu/xom/converters/DOMConverter.html#convert(org.w3c.dom.Document)
>
> Cowboy coding like you suggest scares me. I certainly wouldn't want
> to have to trust any software written to such standards. Regrettably
> I know there's a lot of such software out there, which is more reason
> than ever for my software to be very careful about what it receives
> from your software.
|
