home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / 7757 < prev    next >
Encoding:
Text File  |  1992-11-10  |  17.5 KB  |  510 lines

  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!munnari.oz.au!hp9000.csc.cuhk.hk!cucs5.cs.cuhk.hk!shlam
  3. From: shlam@eng.ie.cuhk.hk (Alan S H Lam)
  4. Subject: Public domain DBMS
  5. Message-ID: <1992Nov11.035253.21617@cucs5.cs.cuhk.hk>
  6. Keywords: public domain
  7. Sender: news@cucs5.cs.cuhk.hk
  8. Organization: Faculty of Engineering, The Chinese U. of Hong Kong
  9. Date: Wed, 11 Nov 1992 03:52:53 GMT
  10. Lines: 498
  11.  
  12.  
  13. About two week ago, I had posted a question for asking any public domain database on unix platform. And I received serveral useful mails. Here I would like to express my gratitude to the persons who had send me e-mails. Thanks. Some netters request me to post the reponse to this news group. Hence, I summarize the response as below.
  14.  
  15. My boss seems to pick up the POSTGRES. Does anyone have any comment on that? I will very appreciate it if you could send me any comment on  POSTGRES. Thanks.
  16.  
  17. Alan.
  18.  
  19.  
  20. Response
  21. ==========
  22.  
  23.  
  24. Return-Path: ags@gec-mrc.co.uk
  25. Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) 
  26.           id <sg.17126-0@ben.uknet.ac.uk>; Wed, 4 Nov 1992 13:47:48 +0000
  27. Received: from gec-mrc.co.uk by eros.uknet.ac.uk via PSS with NIFTP (PP) 
  28.           id <10398-0@eros.uknet.ac.uk>; Wed, 4 Nov 1992 13:47:36 +0000
  29. Date: 4 Nov 1992 13:46:54-GMT
  30. To: shlam <shlam@eng.ie.cuhk.hk>
  31. Subject: PD DB
  32. From: ags <ags@gec-mrc.co.uk>
  33.  
  34. Alan,
  35.  
  36. I have recently ftp'd Postgres and I've read the documentation.
  37.  
  38. Postgres is a large database system produced at UCLA Berkley,
  39. available free.
  40.  
  41. It is not "small, simple" as you asked, it may be easy to use (I
  42. haven't installed it yet). It required about 8 Meg of RAM and 45
  43. Meg of disc space. It's available for SUN, SEQUENT and DEC
  44. workstations.
  45.  
  46. It's multi-user, client-server (I think). It is described as
  47. "relational or object-oriented - pick your favorite buzz-word".
  48. It isn't SQL - the authors of Postgres are very critical about SQL
  49. and IMHO they're quite right.
  50.  
  51. It looks pretty good on the whole. I'm not intending to install it,
  52. as it's too big for my fairly trivial application.
  53.  
  54. I am looking for something simpler - ideally available free in source
  55. form (I want to run it on a Sparc and also possibly port it to a PC
  56. running Linux). Could you let me know if you find anything which
  57. fits this description?
  58.  
  59. Thanks, Gavin.
  60.  
  61.  
  62. -- The above may not represent the views of GEC Marconi, but is probably
  63.    Copyright (C) 1992 GEC Marconi Ltd.
  64. Gavin Spittlehouse, Software Engineering Group, GEC Marconi Research Centre,
  65. Chelmsford, Essex UK CM2 8HN. 0245 73331 x3245   ags@uk.co.gec-mrc
  66.  
  67.  
  68.  
  69. Return-Path: robertp@csis.dit.csiro.au
  70. Received: from carina (carina.csis.dit.csiro.au) by lynx (4.1/1.0)
  71.     id AA23250; Thu, 5 Nov 92 11:01:24 EST
  72. Received: by carina (4.1/1.0)
  73.     id AA18241; Thu, 5 Nov 92 11:01:20 EST
  74. Date: Thu, 5 Nov 92 11:01:20 EST
  75. From: robertp@csis.dit.csiro.au
  76. Message-Id: <9211050001.AA18241@carina>
  77. To: shlam@eng.ie.cuhk.hk
  78. Subject: anonymous ftp'able database
  79.  
  80. Dear Alan,
  81.  
  82. I just read your News request for a public domain database.
  83. You might like to take a look at REQUIEM - it's available 
  84. by anonymous ftp from dcssoft.anu.edu.au in the pub/requiem
  85. directory.
  86.  
  87. There are two versions available, a multi-user one and one that 
  88. allows embedded queries in a standard C program.  My advise would
  89. be to get the latter one.
  90.  
  91. If you are running on a Unix machine, you should have no problem,
  92. but let me know if you do.  The README files are pretty helpful.
  93. The query language is RQL (Relational Query Language) based on the
  94. Relational Algebra and similar to SQL.  There is a file GRAMMAR 
  95. that describes it fairly well.  
  96.  
  97. Hope it's what you're after.
  98.  
  99.  
  100. Robert Power
  101.  
  102. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  103. robert.power@csis.dit.csiro.au            
  104. CSIRO Division of Information Technology
  105. PO Box 664                     tel: +61 6 275 0960
  106. Canberra ACT 2601 AUSTRALIA.            fax: +61 6 257 1052
  107. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  108.  
  109.  
  110. Date: Thu, 5 Nov 92 13:20:46 EST
  111. From: robertp@csis.dit.csiro.au
  112. Message-Id: <9211050220.AA19187@carina>
  113. To: shlam@eng.ie.cuhk.hk
  114. Subject: Re: anonymous ftp'able database
  115.  
  116. I developed The embedded version of REQUIEM as my honours 
  117. thesis last year.  My supervisor was the co-author of the 
  118. system, Mike Papazoglou.  I don't actually use it for 
  119. personal or work purposes but I do offer a casual support
  120. for anyone who uses it - if they find any bugs in it, I 
  121. try and fix them (when I get time).
  122.  
  123. I think REQUIEM is a good relational database.  Having worked 
  124. with SQL, the RQL language provides an alternative approach
  125. to an interactive relational query language, one that I
  126. believe is worth knowing.  
  127.  
  128. The embedded query language that I developed was influenced 
  129. more by INGRES than ORACLE, and I think it is a better 
  130. coupling of C and a database language than either of those 
  131. two systems provide.  It is this which motivates me to keep 
  132. an eye out for potential users of REQUIEM and to tell them 
  133. about it.
  134.  
  135. As for performance, I can't really say.  REQUIEM was developed
  136. as a research and educational tool, but is being used by a 
  137. number of people world wide.  One of its benefits is that the 
  138. source code is written in C and is freely available.
  139.  
  140. Let me know of any other Dbases you find out about.  I would
  141. be interested in any evaluation/comparisons you do.
  142.  
  143.  
  144. Robert Power
  145.  
  146. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  147. robert.power@csis.dit.csiro.au            
  148. CSIRO Division of Information Technology
  149. PO Box 664                     tel: +61 6 275 0960
  150. Canberra ACT 2601 AUSTRALIA.            fax: +61 6 257 1052
  151. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  152.  
  153. Date: Thu, 5 Nov 92 20:20:55 +1100
  154. From: SiewSiong Tan <u883399@sol.surv.utas.edu.au>
  155. Message-Id: <9211050920.AA20636@sol.surv.utas.edu.au>
  156. To: shlam@eng.ie.cuhk.hk
  157. Subject: Re: Any public domain database on the net?
  158. Newsgroups: comp.databases
  159. References: <1992Nov3.024854.25956@cucs5.cs.cuhk.hk>
  160.  
  161. In comp.databases you write:
  162.  
  163.  
  164. >I want to know if there is any public domain 
  165. >database (which is small, simple, and easy to
  166. >use) on the net that I can download to
  167. >use. I heard of postgress. Does anyone use
  168. >it? What is your comment on that?
  169.  
  170. Hi Alan;
  171.  
  172. I am using POSTGRES (obejct Oriented DBMS) and GEO++. 
  173. GEO is a GIS front end to postgres DBMS. My comment
  174. is they as as good as any other commercial DBMS.
  175.  
  176.  
  177.  
  178. >If you know any public domain database,
  179. >please send me a e-mail. I will very
  180. >appreciate it. Thanks.
  181.  
  182. You're welcome. The other P D DBMS that I know of is the
  183. ENCORE OO DB, I haven't try it so I can't comment.
  184. it is available at 
  185.     wilma.cs.brown.edu in pub as encore.tar.Z
  186.  
  187. hope this help.
  188.  
  189. cheers
  190. +-----------------------------------------------------------------+
  191. |  SiewSiong TAN                               GPO Box 252C       |
  192. |  University of Tasmania                      Hobart, Tasmania   | 
  193. |  Dept of Surveying & Spatial Info Science    Australia 7001     |
  194. |  email: u883399@sol.surv.utas.edu.au         fax: (002) 240282  |
  195. +-----------------------------------------------------------------+
  196.  
  197. From: bjtong@cs.unsw.oz.au (Banchong Harangsri)
  198. To: shlam@eng.ie.cuhk.hk
  199. Date: Thu, 5 Nov 92 22:07:01 +1100
  200. Message-Id:  <921105110701.26756@cs.unsw.oz.au>
  201. Subject: Re: Any public domain database on the net?
  202.  
  203. Path: usage!metro!munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!drawing.adelaide.edu.au!andrew
  204. From: andrew@drawing.adelaide.edu.au (Andrew Trotter)
  205. Newsgroups: comp.databases
  206. Subject: P.D Databases
  207. Message-ID: <1b3dotINN4qh@huon.itd.adelaide.edu.au>
  208. Date: 9 Oct 92 07:53:01 GMT
  209. Sender: andrew@moe (Andrew Trotter)
  210. Reply-To: andrew@drawing.adelaide.edu.au (Andrew Trotter)
  211. Organization: University of Adelaide
  212. Lines: 23
  213. NNTP-Posting-Host: moe-gw.drawing.adelaide.edu.au
  214.  
  215. --
  216. I'm new to this news thing but I am interested in relational data bases
  217. with sql, similar to Informix, etc. Are there any public domain data bsaes
  218. with this type of capability.
  219.  
  220. Infact I would be interested in any database (public domain at present)
  221. that is compilable for Unix, DOS and Apple. This is most likely
  222. impossible but you can only ask.
  223.  
  224. I need this as is to be one of two interfaces for a graphically and 
  225. texturally driven Facilities Management system.
  226.  
  227. Any polite pointers will be received with thanks, others will be ignored.
  228.  
  229. Thanks in advance.
  230.  
  231. *********************************************************************
  232. ***  Andrew Trotter                  *        email :-      ***
  233. ***  CADD Manager. Buildings Branch  *                  ***
  234. ***  University of Adelaide          * andrew@moe.adelaide.edu.au ***
  235. ***  P.O. Box 498.             ********************************
  236. ***  ADELAIDE S.A. 5000                   *      Phone (08) 228 5900      ***
  237. *********************************************************************
  238. Newsgroups: comp.databases
  239. Path: usage!metro!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsc!cbfsb!att-out!pacbell.com!decwrl!netcomsv!netcom.com!stevedav
  240. From: stevedav@netcom.com (Steve Davidson)
  241. Subject: Public domain DATABASE SYSTEM. (Responses)
  242. Message-ID: <1992Oct9.033404.13163@netcom.com>
  243. Keywords: database public domain copyleft ingres requiem postgres exodus mbase 4BSD
  244. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  245. Date: Fri, 9 Oct 1992 03:34:04 GMT
  246. Lines: 259
  247.  
  248.  
  249. This is a compilation of responses to my original post regarding 
  250. free database systems.  I start with the original post and follow 
  251. with a summary of the results.  The last part includes the 
  252. responses verbatum.  
  253.  
  254. ORIGINAL POST:
  255.  
  256. Can anyone suggest a free, public domain, or copylefted
  257. database system that meets the following requirements:
  258.  
  259. It is multi-user with record locking.
  260. It must have fast indexing including a B-tree and a hash.
  261. It needs to maintain a large and growing collection of data.
  262. It should interface well with Unix utilities.
  263.  
  264. Any suggestions are appreciated.
  265.  
  266. I will re-post results if anyone shows interest.
  267.  
  268. Steve Davidson
  269. steved@cfcl.com 
  270.  
  271. =================================================================
  272. SUMMARY OF RESPONSES:
  273.  
  274. The responses included the following software:
  275.  
  276. 4BSD O/S layers
  277. Postgres 
  278. Ingres
  279. Mbase
  280. Requiem
  281. E/Exodus
  282.  
  283.  
  284. My interpretation of the more-interesting points follows:
  285.  
  286. The 4BSD O/S provides O/S "primitives" in support of databases
  287. such as low-level indexing schemes and structured files.  Read 
  288. the email response on this one.
  289.  
  290. Postgres is my favorate in large part due to the current activities 
  291. surrounding the project.  This has obvious benefits of support and 
  292. improvement.  The Postgres project may be related to 4BSD.
  293.  
  294. I did not have to time to research Ingres, Mbase, Requiem or 
  295. E/Exodus.
  296.  
  297. ======================================================================
  298. THE REPLIES:
  299.  
  300. From: seiferth@rufous.cs.unm.edu (Justin Seiferth)
  301.  
  302. Try mbase (comp.sources.unix Vol 28).  If you find something better,
  303. please let me know.
  304.  
  305.  
  306. ======================================================================
  307. From: Tero Laakkonen <laakkone@cc.helsinki.fi>
  308.  
  309. ingres? look in archie where you can get it.
  310.  
  311.  
  312. ======================================================================
  313. From: Stefan Grefen <grefen@wilbur.zdv.uni-mainz.de>
  314.  
  315. Try Postgres from postgres.berkeley.edu.
  316. There is a perl and tcl interface to postgres.
  317. Hope this helps
  318.  Stefan
  319. -- 
  320. Stefan Grefen   ---   Johannes Gutenberg University Mainz   ---    Germany
  321. Email: grefen@goofy.zdv.uni-mainz.de
  322.  
  323.  
  324.  
  325. ======================================================================
  326. From: M{nnist| Tatu <tm@cs.tut.fi>
  327.  
  328. You should try postgres which is a next generation DBMS. It is about
  329. 200000 lines of C code and available free of charge by anon ftp from:
  330.   postgres.berkeley.edu      (128.32.149.1)
  331.  
  332. It is still under development, has few bugs but anyway it is the best
  333. I've seen for $0.
  334.  
  335. ---------------------------------------------------------------------------
  336. Tatu Mannisto                                   Tampere Univ. of TeXnology
  337. +358 31 185 414    home                           Internet: tm@cs.tut.fi
  338. +358 31 162 951    work (HB230)
  339. ---------------------------------------------------------------------------
  340.  
  341. ======================================================================
  342.  
  343. From: mike acklin <EACKLIN@UAFSYSB.UARK.EDU>
  344. Subject:      Re: Public domain DATABASE SYSTEM.
  345. To: stevedav@netcom.com
  346. Status: R
  347.  
  348. Hi
  349. Try CBASE from Simtel20 archive. It'll need some tweaking, and I don't know
  350. for sure about multiuser yet, but it's a pretty nice design if you're a
  351. C-programmer...if not, it's a good place to become one....
  352.  
  353. Let me know what other responses you get, as I'm doing an evaluation similar
  354. to yours. If I find others myself, I'll let you know.
  355.  
  356. Michael Acklin
  357. Research Analyst
  358. Office of Institutional Research
  359. University of Arkansas, Fayetteville
  360. eacklin@uafsysb.uark.edu
  361.  
  362. ======================================================================
  363.  
  364. From: <bostic@postgres.berkeley.edu>
  365.  
  366. First, so you can stop reading quickly, the system I'm going to
  367. direct you to does NOT have record locking in the production
  368. version.  Record locking has been done, but it's still a prototype.
  369.  
  370. That said:
  371.  
  372. The 4BSD system now has the underlying layers (C application layers)
  373. of such a beast.  The upper layers will be added in the next year or
  374. so, including full transaction support.  It's freely redistributable,
  375. like all Berkeley software.
  376.  
  377. It has B+tree and extended linear hashing implementations, as well as
  378. an interface to fixed and variable length records (the latter is
  379. intended to permit use of UNIX files as databases).  The interface is
  380. consistent across all access methods.  The hashing and B+tree
  381. implementations are at least as fast as any others we have found.  The
  382. hashing implementation has record locking completed, the B+tree has a
  383. prototype.  The record interface has not had locking implemented,
  384. although, since it's built on top of the B+tree code it wouldn't be
  385. difficult to do.  There is an underlying shared memory buffer pool used
  386. by all of the access methods.
  387.  
  388. If you want more information, let me know, or, you can get details on
  389. the intended transaction support from the LIBTP paper in the Winter
  390. 1992 USENIX Proceedings.  Details of the hashing implementation are
  391. in the Winter 1991 USENIX Proceedings.
  392.  
  393.         uunet!bostic
  394.         bostic@okeeffe.berkeley.edu
  395.  
  396.         Keith Bostic                    +1-510-642-4948
  397.         457 Evans Hall
  398.         CSRG, CSD
  399.         University of California
  400.         Berkeley, CA  94720
  401.  
  402.  
  403. ======================================================================
  404.  
  405. From: afc@shibaya.lonestar.ORG (Augustine Cano)
  406.  
  407. Some months ago I looked into mbase (metal base 4) originally written for
  408. the atari, but version 4 meets, if I remember correctly, all the requirements
  409. above.  I is a relational database engine, no fancy user interface.  It is
  410. shareware and can be found at the wuarchive ftp site.  I'd be interested in
  411. whatever you can find out.
  412.  
  413. Thanks.
  414.  
  415. -- 
  416. Augustine Cano          INTERNET: afc@shibaya.lonestar.org
  417.                         UUCP:     ...!{ernest,egsner}!shibaya!afc
  418.  
  419. ======================================================================
  420.  
  421. From: jfr@redbrick.com
  422.  
  423. Look at the following recent post on Requiem.  I have found it to
  424. be very stable in previous releases (far more so than Metalbase
  425. or other PD/ShWr products that are available).   Its only drawback
  426. is that it uses Quel, not SQL (although I am trying to implement
  427. a SQL front-end which I may distribute).  
  428.  
  429. Good luck.
  430.  
  431. Jon
  432.  
  433. >>From: robertp@carina.csis.dit.csiro.au (Robert Andrew Power)
  434. >>Subject: Extensions to RDBMS REQUIEM
  435. >>Date: Wed, 30 Sep 1992 23:51:25 GMT
  436.  
  437. REQUIEM (RElational Query and Update Interactive systEM) is an 
  438. extensible, relational DBMS developed in C with a query language
  439. based on the relational algebra called RQL (Relational Query 
  440. Language).  Descriptions of REQUIEM can be found in :
  441.  
  442.         `An Extensible DBMS for Small-Medium Scale Systems',
  443.          Papazoglou, M.P., IEEE Micro, April 1989.
  444.  
  445.         or the book :
  446.  
  447.          Relational Database Management - A Systems Programming 
  448.          Approach, Papazoglou, M.P. and Valder, W.,
  449.          Prentice Hall International, UK, 1989.
  450.  
  451.  
  452. The original version has been extended in the following ways :
  453.  
  454.         - to make it a multi-user system and 
  455.  
  456.         - a preprocessor to allow embedded queries 
  457.           in standard C programs.
  458.  
  459. These changes are as yet mutually exclusive.
  460.  
  461. The source code for these extensions have been made available by 
  462. anonymous ftp to :
  463.  
  464.         dcssoft.anu.edu.au
  465.  
  466. The respective compressed and tar'ed files are 
  467.  
  468.         - REQUIEM.tar.Z (muli-user version)
  469.  
  470.         - Requiem.tar.Z (includes preprocessor)
  471.  
  472.  
  473. Any queries with the embedded version of requiem can be directed   
  474. to : 
  475.  
  476. robert.power@csis.dit.csiro.au
  477. CSIRO Division of Information Technology
  478. PO Box 664                                      tel: +61 6 275 0960
  479. Canberra ACT 2601 AUSTRALIA.                    fax: +61 6 257 1052
  480.  
  481. The person who wrote the multi-user version is no longer at the ANU
  482. and is in fact out of the country.  He will be starting a PhD at  
  483. Queensland University of Technology in 93 (or so I'm told).  Any
  484. queries regarding this version of Requiem will have to wait until
  485. then.
  486.  
  487. Robert Power
  488.  
  489.  
  490. ======================================================================
  491.  
  492. >From maney Mon Oct  5 09:53:26 1992
  493.  
  494. Try E/Exodus at ftp.cs.wisc.edu.  Exodus is an industrial strength
  495. storage manager.  E is persistant C++ based on gcc 2.2.2.  The
  496. persistant C++ pardigm makes for rapid transaction processing system
  497. development.  Exodus has state-of-the-art concurrecy, consistency
  498. and recover featrues including automatic self repair.  Binaries
  499. are posted for Suns.
  500.  
  501. -George
  502.  
  503. ======================================================================
  504.  
  505. --
  506. Alan S. H. Lam
  507. Department of Information Engineering, CUHK, Hong Kong
  508. E-mail: shlam@eng.ie.cuhk.hk 
  509. Tel: (852) 609 7975 Fax: (852) 603 5032
  510.