db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ян Программист <webautoma...@gmail.com>
Subject Data type compatibility
Date Sat, 27 Mar 2010 11:25:39 GMT
Have some vision about data centric compatibility between databases:

   1. Numeric type precision
      1. If a lot of entries with large numbers should be collected,
      precision for float, decimal are represented threw last digits
      2. As a result of (1) most parts of data is duplicated (in binary
      format duplication is lower, unlike human readable format)
      3. (2) gives a chance to make table space on disk much lower, storage
      I/O more effective after resolving that disadvantage
      4. Most parts of float & decimal based types should be rad from end,
      unlike normal cell entries. This will help in providing a way of making
      SELECT with a lower precision in entries, unlike waiting for a
      results, if needed. Extra usable stuff for number comparison tasks; when
      rather lower <-> grater plotting is used for data representation & full
      precision is not critical. Client would later initiate individual entry
      SELECT for detailed, precision critical analyzes
      5. (1)-(4) is good for embedding JavaDB in a microprocessor runtime
      (J2ME), for sing it as an embed database for storing data in measurement
      devices (e..g. factory devices, collecting large data with high precision
      for production quality control)
   2. XML type compatibility
      1. Some kind of XML to SQL, client to server translation, when client
      is doing XML request, and server accepts SQL equivalent. Good for XML
      compatibility with XML type of Oracle, DB2, etc. I arranged that in
      following rules:
         1. Returned data is taken from indexes ONLY
         2. If nested XML tokens are related to entries under transaction at
         request moment - only parent XML structure is returned; transaction
         isolation would isolate tokens from response
         3. Used ONLY in XML based/driven architectures, populated via
         JavaDB entries in a XML ruled way


View raw message