|
We chose MySQL as our database management system.
Furthermore, we all have accounts on a Sun,
and have set up the database system there.
The idea is to make and test the database on the Sun, then port it
over to wherever the user would like us to, provided it is somewhere on the research Suns.
For database management software, we use MySQL, a free
SQL (Structured Query Language) server/database program.
This program has several advantages.
One is that it is extraordinarily portable. There are versions that
run on NT, Linux, Solaris, *BSD, and others. This is a good thing,
as our client uses a Sun as their primary platform, and it would be
desired to have the database on the same platform as the program it
is designed to run with.
MySQL is also a familiar interface. There is an API for every platform mentioned
elsewhere, it is primarily programmable in C/C++, and is not hard to understand.
The database software created as part of this project will run on any
platform supports MySQL.
MySQL satisfies all our requirements for a database program save one --
it cannot use arrays as data structures in the tables, so far as we have seen.
However, it can create tables on the fly, can store arbitrary-sized strings,
can be accessed remotely easily, and has reasonably decent data storage size.
Finally, several people in the department have knowledge of MySQL,
including our esteemed TA, Ryan Satogata.
Thus support for the DBMS is available.
There are other requirements for software on the front end of the system.
One module that must be constructed is the script that takes the text output of
the invariant program and transforms it into something our database can understand.
We use the scripting language Perl.
Hardware specifications are as follows: A Sun machine, running OS
5.0 or greater.
Both the development machine and the
target machine both have these traits.
A number of database packages were considered in addition to
MySQL.
Here is information on MySQL and the alternatives.
These are three open source DB packages we have heard
the most about.
All of them have C API's (and probably Perl too), and
are free for us on UNIX platforms (probably under Windows too).
Most likely all would have the capabilities we'd need.
We couldn't
find info on the max size of a table in PostgreSQL, probably not less than 4GB.
(Note that for MySQL and MiniSQL
4GB is the max size for each table, not the entire database.)
MySQL
http://www.tcx.se/
platforms:
AIX 4.x with native threads
BSDI 2.x with the included MIT-pthreads package
BSDI 3.0, 3.1 and 4.x with native threads
DEC UNIX 4.x with native threads
FreeBSD 2.x with the included MIT-pthreads package
FreeBSD 3.x with native threads
HP-UX 10.20 with the included MIT-pthreads package
HP-UX 11.x with the native threads.
Linux 2.0+ with LinuxThreads 0.7.1 or glibc 2.0.7
NetBSD 1.3 Intel and NetBSD 1.3 Alpha
OpenBSD 2.x with the included MIT-pthreads package
OS/2 Warp 3, FixPack 29 and OS/2 Warp 4, FixPack 4
SGI Irix 6.x with native threads
Solaris 2.5, 2.6 and 2.7 with native threads on SPARC and x86
SunOS 4.x with the included MIT-pthreads package
SCO OpenServer with a recent port of the FSU Pthreads package
SCO UnixWare 7.0.1
Tru64 Unix
Win95, Win98 and NT
How big MySQL tables can be
MySQL itself has a 4G limit on table size, and operating systems have
their own file size limits.
MiniSQL
http://www.hughes.com.au/
platforms:
SQL has been developed under Sun OS 4.1.1 but has been tested under
Solaris 2.x (release 2.3, 2.4 and 2.5), Ultrix 4.3, Linux, and OSF/1
(cc not gcc). That said, it should "autoconf" and build on
most BSD derived systems, SVR4 based systems or POSIX O/S`s (that
should cover most of them). It has been reported that it works
out-of-the-box on HP-UX, NeXT, SCO, Sequent, Cray, Tandem, *BSD and a
few others.
Both mSQL version 1.x and 2.x have been ported to a few other
operating systems - namely MS Windows, MS Windows 95, MS Windows NT
and OS/2. For more details on these ports and any other ports, please
see the "Contributed Code and Third Party Applications" section of
this FAQ.
How much data can mSQL address?
mSQL can theoretically address tables with a maximum size of 4
gigabytes. In practice you`ll probably run up against operating system
limitations well before this theoretical limit
PostgreSQL
http://postgresql.nextpath.com/
platforms:
OS Processor Version Reported Remarks
AIX 4.2.1 RS6000 v6.4.2 1998-10-27 (Andreas Zeugswetter)
BSDI x86 v6.4.2 1998-10-25 (Bruce Momjian
FreeBSD x86 v6.4.2 1998-10-26 (Tatsuo Ishii, Marc
2.2.x-3.x Fournier)
DGUX 5.4R4.11 m88k v6.3 1998-03-01 v6.4.2 probably OK. Needs
new maintainer. (Brian E
Gallew)
Digital Unix Alpha v6.4.2 1998-10-29 Minor patchable problems
4.0 (Pedro J. Lobo)
HPUX PA-RISC v6.4.2 1998-10-25 Both 9.0x and 10.20
(Tom Lane, Stan Brown)
IRIX 6.x MIPS v6.3 1998-03-01 5.x is different (Andrew
Martin)
linux 2.0.x Alpha v6.3.2 1998-04-16 Mostly successful. Needs
work for v6.4.2. (Ryan
Kirkpatrick)
linux 2.0.x x86 v6.4.2 1998-10-27 (Thomas Lockhart)
linux x86 v6.4.2 1998-10-25 (Oliver Elphick, Taral)
2.0.x/glibc2
linux 2.0.x Sparc v6.4.2 1998-10-25 (Tom Szybist)
linuxPPC PPC603e v6.4.2 1998-10-26 Powerbook 2400c (Tatsuo
2.1.24 Ishii)
mklinux DR3 PPC750 v6.4.2 1998-09-16 PowerMac 7600 (Tatsuo
Ishii)
NetBSD/i386 x86 v6.4.2 1998-10-25 (Brook Milligan)
1.3.2
NetBSD- NS32532 v6.4.2 1998-10-27 (small problems in
current date/time math
(Jon Buller)
NetBSD/sparc Sparc v6.4.2 1998-10-27 (Tom I Helbekkmo)
1.3H
NetBSD 1.3 VAX v6.3 1998-03-01 (Tom I Helbekkmo)
SCO UnixWare x86 v6.3 1998-03-01 aka UNIVEL (Billy G.
2.x Allie)
SCO UnixWare x86 v6.4.2 1998-10-04 (Billy G. Allie)
7
Solaris x86 v6.4.2 1998-10-28 (Marc Fournier)
Solaris Sparc v6.4.2 1998-10-28 (Tom Szybist, Frank
2.6-2.7 Ridderbusch)
SunOS 4.1.4 Sparc v6.3 1998-03-01 patches submitted (Tatsuo
Ishii)
SVR4 MIPS v6.4.2 1998-10-28 no 64-bit int support
(Frank Ridderbusch)
SVR4 4.4 m88k v6.2.1 1998-03-01 confirmed with patching
(Doug Winterburn)
Windows NT x86 v6.4.2 1998-10-08 Mostly working with the
Cygwin library. No DLLs
yet. (Horak Daniel)
MySQL was pretty
simple to install, configure, and use.
A sample C program was written to test some of the basic features.
MySQL doesn't support arrays of numbers as a datatype that a field
can store, it does support arbitrarily large character strings so we
could probably easily convert a string to an array of integers by
treating it as a bit stream.
Although -- we think in the past we've run
into problems with the high-order bit being lost in the conversion to
char, so it may not be that simple.
On the other hand, we can create tables on the fly (we little test
program does that) and we think that would be a fairly decent solution
to the problem.
MySQL on UNIX was chosen for the following reasons:
-
The Daikon research uses UNIX.
-
MySQL is very portable.
-
MySQL can handle large amounts of data efficiently.
-
MySQL has API's for C, Perl, Java, and... Python!
Additionally, it is easy for us to access and
coordinate under UNIX since it is available anywhere we have access
to the Internet, and we have tools like RCS to keep track of revisions
and who is modifying what.
Date: Tue, 20 Apr 1999 19:33:23 -0700
From: Gabriel Deal
Subject: Re: MySQL
I ended up installing MySQL on my C&C account -- and I didn't need
supervisor permissions. I'm pretty sure I would be able to install
it on any UNIX machine with gcc 2.8.x and also on a lot of standard
platforms like Solaris 2.5.1+ and Linux (MySQL has binary
distributions available for these platforms). I can't install it on
sanjuan or orcas.
That *was* C I was programming with, MySQL just provides some
header files and libraries that we can use in C to communicate with
it. In fact, now that I think about it, you ought to be able to
develop under NT with the exact same API if you like, you'd only have
to install those libraries and header files on the NT machine and
then communicate with the UNIX host. I'm running MySQL server on
dante20.u right now, and I just ran my little C program on dante21.u
(a completely different machine) and it worked fine. All I had to do
was modify my program to access "dante20.u" instead of "localhost" and
it worked like a charm.
If we go with MySQL and UNIX, I'd suggest we try to get accounts on
Michael's machine since then we'd know for sure our code will
work where it's the most needed.
gabriel
Here are some web pages that are worth
looking over.
http://www.tcx.se/
The MySQL home page.
http://www.tcx.se/Manual_chapter/manual_toc.html
A reference manual that probably has more than
we care about, and much of what we do care about is not
covered in depth.
But it would be a good idea to scan the index and check out what looks
interesting.
http://www.devshed.com/Server_Side/MySQL/
A really simple tutorial covering the use of MySQL on the
command
line and the database administration basics.
http://www.turbolift.com/mysql/3.21_C_API/toc.html
A short tutorial covering the C API of the previous MySQL
version
(so it may be a bit out of date).
Don't be put off by the fact that the introduction
is pretty much non-existent.
http://www.geocities.com/ResearchTriangle/Node/9672/sqltut.html
is a helpful tutorial on Structure Query Language (SQL)in general.
|