home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6720 < prev    next >
Encoding:
Text File  |  1992-09-14  |  4.3 KB  |  88 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!usc!rpi!psinntp!psinntp!spunky!glitter.RedBrick.COM!jfr
  3. From: jfr@glitter.RedBrick.COM ()
  4. Subject: Re: WATCOM SQL  (Opinions sought)
  5. Message-ID: <1992Sep13.190238.3381@RedBrick.COM>
  6. Sender: usenet@RedBrick.COM
  7. Nntp-Posting-Host: glitter.redbrick.com
  8. Organization: Red Brick Systems, Los Gatos, CA
  9. References: <THOMASG.915.715985512@epx.cis.umn.edu> <BuE700.9oA@watserv1.uwaterloo.ca>
  10. Date: Sun, 13 Sep 1992 19:02:38 GMT
  11. Lines: 75
  12.  
  13. In article <BuE700.9oA@watserv1.uwaterloo.ca> rpeterse@watserv1.uwaterloo.ca (Raymond Petersen) writes:
  14. >In article <THOMASG.915.715985512@epx.cis.umn.edu> THOMASG@epx.cis.umn.edu (ThomasD.Gasser) writes:
  15. >[munch]
  16. >4) The part that I use most is Embedded SQL (in my C code).  I then use a
  17. >   pre-processor which converts the SQL in my C code to C function calls that
  18. >   are resolved at link time by library that comes in the developer's edition.
  19. >   (It comes with Borland,Microsoft,and WATCOM C compilers.  If you need it for
  20. >   another compiler - ask.)  The one thing that some people may find unusual is
  21. >   that in WATCOM SQL all Embedded Sql is dynamic.  None of it is precompiled,
  22. >   it is only pre-processed.  There are a LOT of advantages to doing it this
  23. >   way.  The reason most products precompile SQL into a PLAN table, is
  24. >   execution speed, but lack of speed isn't one of WATCOM SQLs shortcomings.
  25.  
  26.    This is NOT unusual.  In fact, with the exception of IBM's and DEC's
  27.    precompilers for DB2, SQL/DS and RDB, most of the SQL engines that 
  28.    have precompilers use dynamic SQL for execution (i.e., they pass
  29.    the SQL statement as a string from the program at execution time).
  30.    Sybase supports stored procedures but no precompiler (that may have
  31.    changed recently but I am not sure whether the precompiler uses
  32.    the stored procedures).  For most SQL engines, "static" SQL is
  33.    just a precompiled cover on dynamic SQL.  
  34.  
  35.    The reason that *some* products (like DB2 and RDB) precompile SQL
  36.    is because the cost of optimizing large queries (particularly
  37.    multi-way joins) at execution time can be very high.  Doing it
  38.    once at precompile (or bind) time is much cheaper in machine
  39.    resources and also permits the optimizer to investigate far more
  40.    potential choices than a run-time optimizer can if you expect it
  41.    to be responsive.  All of this depends on how complex your queries
  42.    are and how big your databases are.  Any PC-based database is
  43.    going to be relatively small (maybe tens of megabytes or so)
  44.    compared to mainframe and large server databases of gigabytes
  45.    and upwards.  What you consider good speed on a "large" (your
  46.    view) database of 50,000 rows will degenerate rapidly on a
  47.    truly large database of 50,000,000 rows.  At that point, the  
  48.    more time an optimizer has, the more likely it is to find the
  49.    best and fastest path through the query. 
  50.  
  51. >[munch]
  52. >   - ANSI standard SQL transaction logs
  53.  
  54.    Huh?  ANSI provides no standard for SQL transaction logs that I
  55.    know of.  Is this a claim of the software vendor or your editorial
  56.    commentary?  Inquiring minds wish to know :-)
  57.  
  58. >   - Transaction processing with a checkpoint log and a forward transaction log
  59. >   - Comprehensive security capabilities
  60. >   - Updatable views
  61. >   - Easily imports data files from other popular data formats.
  62. >   - Automatically uses expanded and extended memory to improve performance
  63. >   - Will run on 640K PCs (I do)
  64. >   - Royalty free run-time - $99.
  65. >
  66. >6) Other interesting facts.
  67. >   a) All strings are variable length.
  68.  
  69.    This is not a feature I consider good.  Specifically, it must impact
  70.    performance in SOME way to not have fixed length strings when varchars 
  71.    are unnecessary.  Why is it that practically no one gets this right?
  72.    
  73. >   b) NULL values in a row only use 1 bit to store.
  74.  
  75.    I assume you mean 1 bit per field.  This is common but limiting if
  76.    you ever want to support multi-valued NULLs (ala SQL2) or have other
  77.    uses for a column-oriented flag.  I prefer at least 2 bits per column.
  78.  
  79. >   c) The developers spent a lot of time comparing the speed of WATCOM SQL
  80. >      (the 386 database engine) and Microsoft SQL Server, so that their product
  81. >      would outperform Microsoft's on the most common operations.
  82.  
  83.    Not very difficult, IMHO :-)  I would be more interested in how they
  84.    compare to Oracle System 7.
  85.  
  86.    Jon Rosen
  87.  
  88.