remco@tnoibbc.UUCP (Remco Bruyne) (02/12/90)
Hello, A short time ago I posted a request about information concerning database systems capable of networking, storing pictures and with support to create and maintain applications with a reasonable amount of work. I got some responses some of which were very useful. The question was: >We are looking for a database system which suits the following needs: > >1) Should be able to run on several types of hosts. >2) Should not get too slow with databases of about 100,000 and more records. >3) Reasonable costs, may be dependent on the host system used. >4) Should be reasonably easy to generate/maintain and change applications. >5) Should be able to interface to other DBMSs (maybe with some interface > software). >6) Capabilities for storing images/line pictures should be present now or > in future implementations of the product. Also think of interfacing to > existing drawing/digitizing programs. >7) Capabilities for network communication, because it is necessary that > information can be retrieved from remote systems. > >That's all :-). > >Probably this system doesn't exist, but when you know of something that >comes really close, could you let me know? Here follows a summary for the interested (in the order in which I received the messages): ---------------- Date: Tue, 30 Jan 90 15:02:10 -0800 From: Donovan Hsieh <donovan@csl.sri.com> Message-Id: <9001302302.AA01620@julius.csl.sri.com> Subject: Wanted: DBMS for distributed information containing images In remco@tnoibbc.UUCP of comp.databases, Remco Bruyne writes "Wanted: DBMS for distributed information containing images": I guess most existing commercial RDBMS should meet your requirements more or less except (6). This is also pretty much depending on how you want to manipulate your images/line pictures data. If you simply want to store them as it and bring them back to whatever tools for processing. There are two ways you can handle it: a. Store them into a special long fiield which may handle data up to 4KB (vendor dependent). Of course, you may want to compress and decompress them before and after the access to save storage space. b. Another way is to implement it as a database application instead of using the database system feature. In your database schema, a special field which contains either a file pointer to those images files, or a reference path name which may lead your applications to access the file and pass to the tools. If however you want a fine grained control over the internal data structure of those images and line picture files. I would suggest you to use an OODB which is available on several vendors. This gives you the richest data modeling capability in the long run. Currently, those OODBs are almost implemented in a client/server architecture on the network. Some even provide backward SQL compatibility to certain extent. Donovan Hsieh Computer Science Lab Stanford Research Institute Menlo Park, CA ------------------------------------------------------------ From: prc@erbe.se (Robert Claeson) Message-Id: <9001310919.AA16119@maxim.erbe.se> To: remco@tnoibbc Check out version 6.3 of Ingres (the one with knowledge management and object capabilities). It should fit your bill well. Robert ------------------------------------------------------------ Date: Wed, 31 Jan 90 16:45:52 +0100 From: johan@cwi.nl Message-Id: <9001311545.AA01859@kangaroo.cwi.nl> [This response was in Dutch] I give a short summary in my own words and hope I correctly reproduce the main information...] To my opinion Ingres satisfies all requirements except 6. A future version (not the next) will probably have support for this. >1) Should be able to run on several types of hosts. I know of: Apollo, Dec (VMS en Unix), Gould, HP, NCR, Pyramid, Sequent, Sun 286 en 386's (Unix, OS/2, MS(DOS), the latter with restrictions). >2) Should not get too slow with databases of about 100,000 and more records. Ok. [I left this untranslated :-)] >3) Reasonable costs, may be dependent on the host system used. Depends on the number of users. >4) Should be reasonably easy to generate/maintain and change applications. SQL + Quel, which is comparable to SQL, but a little more powerful. Ther are 4 levels of interactive use: name enduser development- support for ease-of-use time (order) development maintenance of applications QBF + uur - + SQL - uur - - 4GL ++ week + + 3GL +++ maand ++ + SQL has a 'tty-interface', the others a form-interface. A screen represents a form containing fixed texts, fields with attributes. The form-definition can be made easily for QBF, 4GL and 3GL. [stuff deleted] 4Gl can be converted to 3GL (C, Fortran, Pascal , Cobol, Ada) with embedded SQL-calls and form-control statements. >5) Should be able to interface to other DBMSs (maybe with some interface > software). There is a gateway system for information exchange to and from most well-known systems (DB2, SQL/DB, ... ) >6) Capabilities for storing images/line pictures should be present now or not yet >7) Capabilities for network communication, because it is necessary that > information can be retrieved from remote systems. TCP/IP, based + other options. Other characteristics: good multi-user properties (locking; data-integrity by handling multi-statement transactions atomically. slow in single-record operations (large overhead) compared to other systems fast mutli-record operations. requires a lot of resources (+/- 50 MB binaries end support files); data in Ingres-tables with Random_access and some indices easily needs 10 times more space than a corresponding sequential Unix-file; A server with some clients need about 10 MB of RAM; abundant cpu and io necessary Johan Wolleswinkel CWI, Postbus 4079, 1009 AB Amsterdam, Kruislaan 413, The Netherlands Phone: +31 20 5924122 Fax: +31 20 5924199 Telex: 12571 (mactr nl) Internet: johan@cwi.nl or ...!hp4nl!cwi.nl!johan Johan, thank you for your extensive explanation which was very useful. ------------------------------------------------------------ From: dlewis@cper1.Dayton.NCR.COM Message-Id: <9001312154.AA01138@uunet.uu.net> Progress Software Corporation has a 4GL called Progress. You can access foreign databases on Unix and NCR Mainframes running our proprietary OS called VRX. You can access Total databases (from cincom) and Oracle databases. In May, they will be releasing the Progress to Progress database access so a DB can access multiple Progress databases. This would be one possibility. >Dave ------------------------------------------------------------ From: uwm!dgh%unify@relay.EU.net (David Harrington) Message-Id: <9001311723.AA23624@unify.UUCP> Organization: Unify Corporation, Sacramento, CA, USA Unify Corp., 3870 Rosin Court, Sacramento, CA 95834, is a developer of application development technology and tools. We have a toolset that consists of a visual, WYSIWYG, GUI application screen generator combined with a powerful, event-driven 4GL, which is called Accell/SQL. Accell/SQL runs on Unify's OLTP RDBMS, Unify 2000, as well as Oracle V5.x & V6.x; Informix/SQL, Sybase and SCO Integra. As regards your requirements: 1. Unify 2000 runs on > 20 hardware platforms. 2. Unify 2000 is rated at 150 TPS on the TP1 benchmark. 3. Unify 2000 is priced based on # users and size of the h/w platform. 4. Accell/SQL gives you the application development environment that should easily meet your development needs, now and in the future. 5. Accell/SQL interfaces to (and runs on, as a native implementation) all the databases listed above. 6. The Open Look release of Accell/SQL will provide full graphical capabilities, including the ability to manipulate bit-mapped images and interfaces to drawing packages. Unify 2000 supports this capability with its BLOB data type. 7. In addition, remote database access is available to Accell/SQL applications via Unify's Accell/NET product, via SQL*NET for Oracle and Sybase's client/server architecture. Looks like this is what you need. -- David Harrington internet: dgh@unify.UUCP Unify Corporation ...!{csusac,pyramid}!unify!dgh 3870 Rosin Court voice: (916) 920-9092 Sacramento, CA 95834 fax: (916) 921-5340 ------------------------------------------------------------ Date: Wed, 31 Jan 90 13:00:15 PST From: sybase!cyoung@relay.EU.net (chris young) Sybase runs on many different flavors of UNIX, VAX/VMS, STRATUS, and others. And there are probably a few platforms which are native to Europe of which I am not aware. >2) Should not get too slow with databases of about 100,000 and more records. Sybase consistently provides high performance on all of these platforms. Benchmarks for Sun machines are available. Databases can run into the Gigabyte range. >3) Reasonable costs, may be dependent on the host system used. Sybase is not inexpensive, however it provides one of the lowest price/per- formance ratios available. Our pricing schedule should be available from the Sybase office in the Netherlands. (see below) >4) Should be reasonably easy to generate/maintain and change applications. Sybase enforces referential integrity and other business rules at the database level. Therefore a change in the business rules requires changing the rules in one place, in the database. Ensuring that each application gets the change and is properly coded does not constrain the integrity of the system. Among many other benefits, this architecture provides for lower maintenance costs. With the Application Productivity Tools (APT), application development and prototyping efforts are reduced. Forms are easily generated in 4GL code which can be modified/extended to suit the developer's needs. >5) Should be able to interface to other DBMSs (maybe with some interface > software). Sybase's Client/Server Interfaces provides for customized front-end (Open Client) and back-end (Open Server) applications. This means that you can develop front-ends that are able to talk to differing back-ends and back-ends that can talk to differing front-ends and back-ends that can talk to differing back-ends. This is accomplished through a self-describing data protocol called the Tabular Data Stream (TDS). The protocol is not a network protocol (ie it does not replace TCP/IP, for example) rather it is a data messaging protocol that is transmitted between the front-end and the back-end via the network. What all this means is that it is possible to develop an Open Server application that acts as a go-between for the Sybase SQL Server and another database engine. In fact, Open Server applications have been built that communicate between Sybase and DB/2, IMS, and RMS. Open Server is a product containing the necessary routines to build a custom server. This means that the developers themselves can build the server and do not need to wait for the vendor to produce a gateway product to the desired database. Most vendor gateways try to provide functionality that may not be needed for a particular application. And most gateways don't allow for custom code that provide specialized functions which an application may need. This provides for greater flexibility when developing interfaces between databases. >6) Capabilities for storing images/line pictures should be present now or > in future implementations of the product. Also think of interfacing to > existing drawing/digitizing programs. Sybase has a binary datatype that allows up to 2GB of storage per row. I am aware of applications in the US which interface with Sybase, however I do not know the company names. If this is an issue, let me know. >7) Capabilities for network communication, because it is necessary that > information can be retrieved from remote systems. Precisely because Sybase has invested in the Client/Server architecture, communication between database servers is matter-of-fact. Not all components are available yet (such as transparent data access between servers) but many of the essential parts are. Two-phase commit is one example. I am assuming by your phone number that you are loccated in the Netherlands. We do have an office in the Netherlands. (Sorry, but I don't know the city). The phone number is 31 569205. (I hope that is correct. If not, let me know and I'll track down the correct number and a person's name to contact.) Thanks, Chris Young Consultant Sybase - Denver, US phone: (303) 721-3308 cyoung@sybase.com ------------------------------------------------------------ Date: Fri, 2 Feb 90 16:18:29 PST From: sybase!tiger@relay.EU.net (tiger whittemore) I believe the Sybase RDBMS should handle all of your criteria very well. I may be biased as an employee, but I believe Sybase has a very good reputation, and features to support the functionality you've mentioned. You can contact Sybase at 415 596-3500. ------------------------------------------------------------ -- --------------------------------------------------------------------------- Remco Bruijne USENET: remco@tnoibbc.ibbc.tno.nl PHONE: +31 15 606437 ---------------------------------------------------------------------------