Mailing List Archive


Back to the month index Back to the list index
Carlos M. Gutierrez (carlos@gutierrez.com)
Sun, 8 Sep 1996 01:47:48 -0400 (AST) 

Date: Sun, 8 Sep 1996 01:47:48 -0400 (AST)
From: "Carlos M. Gutierrez" <carlos@gutierrez.com>
Subject: Re: [mSQL] A few miscellaneous questions...
Message-Id: <Pine.BSI.3.91.960908012218.4418B-100000@gaia.gutierrez.com>

On Sat, 7 Sep 1996, Jim Reynolds wrote:

> I'm not sure I completly agree with the way mSQL handles strings that
> are longer than the maximum defined length. Currently, an insert will
> fail if a string is too long. IMHO, the string should be truncated to
> fit. Or, at least, truncation should be an option. I'm thinking about

Umm, I guess this is meant to warn you about possible data loss. There is
nothing preventing you from taking a substring in Perl, C, or Java and
inserting or re-inserting that.

For example, in Perl:

$s = substr($s, 0, 200);

Would limit a string variable to 200 characters. You can then go on an
INSERT this into an msql table. That INSERT should always succeed for a
field of size 200 or larger.

> making a quick and dirty hack to the source-- am I opening the doors to
> all kinds of problems down the road?

It is easier to hack your client program, rather than the server source!

> This real number "bug" concerns me. If I insert a 2.5 into the
> database, sometimes it might print out as 2.50000000001. Not only does it

Umm, this isn't really a "bug" but a feature of many real number
implementations as binary values: they aren't exact beyond 'x' number of
significant figures.

For finance, the solution is to use Integer values. Yup, use Integers...
simply use the last two digits in any number as decimals. Therefore, one
dollar becomes 100. One cent becomes 1. You need not write special code
for multiplication or addition.

The 32 bit integers should have plenty of room.

> amounts as reals, and do comparasions with (>), (<), and (=). Maybe even
> some multiplication too. I can't do this with char-type or ints.

You can do comparisons with the real numbers; you just have to do TWO
comparisons for an 'exact match':

$e = 0.000001;

if (($x < 100 + $e) && ($x > 100 - $e)) {

  # We have a hundred!

}
 
> I won't be doing the traditional database joins and what-not that most
> people do. I have some giant tables (some < 1MB and some near 100MB) that
> I'd like to extract information from. Rearrange columns, multiply columns
> to get a new column, print out entries between a certain range of dates,
> etc... will this take forever on a 100MB file? I'll be running it on a
> 170Mhz. Ultra under Solaris 2.5.1.

I would use a mixture of mSQL and either text or gdbm files. Storing
intermediate results *might* be faster when dumped to text or gdbm files.
The main situation is that mSQL does not yet have "cursors", so
sequential access in some types of tables could get tricky. In those
cases I would use a SELECT * to dump the entire table to a text file, and
then open a loop on this file with Perl or C. The rest depends on your
application...
 
> So far, mSQL has looked very promising. Great import utility-- exactly
> what I was looking for! And an easy to use SQL interface. How will it
> stand up to the larger tables?
>
> Are there any other programs out there, shareware or commercial, that
> process large ASCII data files?

Perl, awk, grep!

cheers,

Carlos
carlos@gutierrez.com
--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to "unsubscribe" to msql-list-request@bunyip.com. Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!