tp@mccall.uucp (02/07/90)
I've read about databases but never used one before. Thus forewarned, could anyone answer a few questions for me? I am writing an application that has to maintain some moderately complicated data structures on disk and get to them in reasonable amounts of time. I could do this with indexed files, but it would be easier with a database, so I'm trying to convince management that I need one. I am considering Rdb for various reasons. The only info I have on it is the SPD. 1) I think relational would be simpler to use and more flexible in the long run (I know it will handle this application just fine). 2) We already buy stuff from DEC, so it is easier than searching through myriad 3rd party vendors. 3) I'm currently trying to justify switching to CD-ROM for media and documentation updates, and I figure Rdb should be on those, which would be convenient and save us money on updates. The questions: 1) Are any of the above reasons faulty? 2) Are segmented strings sufficiently general to implement BLOB's (Binary Large OBjects)? I have some unstructured data that I'd like to stick in the database for future access. I'd like to have this pointed to by a standard relation, and for all usual concurrency and integrity controls to apply. 3) Is network access to a remote database transparent and fully functional, or are there restrictions? In particular, I need concurrent local and remote access, as I do remote support on these applications. 4) If I write a set of library routines and/or shareable images that access an Rdb database, to be shared by several applications, do I need the full development version of Rdb to link against those libraries/images? In other words, if there is only one system on which development of database access software would ever be done, but other systems where people would need to link against the shareable images thus produced, is it sufficient to have Rdb Runtime Only installed on those other systems. 5) Are there any other packages I REALLY should consider? Price is an issue, but so is application development time. I can't take the time to do an extensive search, and I can't afford to get something cheaper that would require more effort to use (as it would increase development time). On the other hand, if there are packages of equal or better functionality that are SIGNIFICANTLY cheaper, or packages of equivalent price that are SIGNIFICANTLY better, I would like to know about them. My development environment and my target production environment are all LAVC's of VAXstations. I'll summarize any useful responses I get via email back to the same groups to which this message is posted. Thanks. -- Terry Poot (800)255-2762, in Kansas (913)776-4041 The McCall Pattern Company, 615 McCall Rd., Manhattan, KS 66502, USA UUCP: rutgers!ksuvax1!mccall!tp Internet: tp%mccall@ksuvax1.cis.ksu.edu
godfrind@ricard.enet.dec.com (Albert Godfrind) (02/08/90)
In article <2120.25d0258f@mccall.uucp>, tp@mccall.uucp writes... >2) Are segmented strings sufficiently general to implement BLOB's (Binary >Large OBjects)? I have some unstructured data that I'd like to stick in the >database for future access. I'd like to have this pointed to by a standard >relation, and for all usual concurrency and integrity controls to apply. There is no limit to the size of an object that a segmented string can hold (other than practical limitations due to disk space, transfer times, etc). Each segmented string (as the name implies) is implemented as a chain of segments; each segment is limited to 64K; so to store an object that needs more than 64K, your program needs to split it into as many segments as necessary; the total chain of segments is still considered as one 'object' by Rdb/VMS. >3) Is network access to a remote database transparent and fully functional, >or are there restrictions? In particular, I need concurrent local and >remote access, as I do remote support on these applications. Yes it is, via DECNET. All you need is to prefix the file spec of the database root file with the name of the remode decnet node (REMOTE::DISK:[DIR]DB.RDB); or you can use a logical name to point alternatively to a local or a remote database. The database on any node can be accessed concurrently from local users on that node and users on remote users on other nodes; maintenance activities can be done locally as well as remotely. >4) If I write a set of library routines and/or shareable images that access >an Rdb database, to be shared by several applications, do I need the full >development version of Rdb to link against those libraries/images? In other >words, if there is only one system on which development of database access >software would ever be done, but other systems where people would need to >link against the shareable images thus produced, is it sufficient to have >Rdb Runtime Only installed on those other systems. Yes, you only need the full development license on the node where you compile and link your applications; the major difference between the development and runtime kits is that the development kit includes the RDML and SQL pre-compilers and the SQL Module Language compiler, with the necessary libraries. The database engine proper is the same for both kits; there is no re-linking necessary to move the application from the development to the runtime node. Note that you automatically get an Rdb/VMS Runtime License with your VMS license (you still have to buy the Runtime Kit). +-----------------------------------------------------------------------------+ | Albert Godfrind These are MY views, all MINE ! | | Digital Equipment Corp. | | European Technical Center INET: godfrind@ricard.enet.dec.com | | Valbonne, France UUCP: ...!decwrl!ricard.dec.com!godfrind | +-----------------------------------------------------------------------------+