Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!apple!dan From: dan@Apple.COM (Dan Allen) Newsgroups: comp.sys.mac.hypercard Subject: Re: Large Scale DataBase Message-ID: <16852@apple.Apple.COM> Date: 9 Sep 88 06:32:12 GMT References: <52305GFX@PSUVM> Reply-To: dan@apple.com.UUCP (Dan Allen) Organization: Apple Computer Inc, Cupertino, CA Lines: 46 In article <52305GFX@PSUVM> GFX@PSUVM.BITNET writes: >We use a rather large database (500,000 + records) holding a few >variables ( 25 +/-) related to industrial establishments. We manage >it with SAS on an IBM mainframe, but are curious as to whether such >a dataBase could be installed in an HyperCard environment to provide >interactive queries (a rarity, but nonetheless...) Our major motive >in doing so would be to take advantage of the (apparently) very fast >searching capabilities of HyperCard. (in most instances, interactive >users do not have the establishment ID number, and therefore must resort >to subString searches to locate the appropriate records. VERY inefficient >at the present time) > > >I would be delighted to hear from anyone with similar experience, or >from anyone able to formulate educated guesses... > >What we would have in mind at this time would be a single field per >record, concatenating all the relevant information in less than, say, >250 characters. Basic questions are: what stack size would it mean? >Is CD-ROM an alternative we should consider? (there would NOT be more >than one site) Can we build the stack automatically from an ASCII file? >What would be the expected search time? Any other approach you think is >superior? To be brutally honest... WE DON't KNOW. Stacks of cards in the 500,000 plus range have not really been tested too well. I do know that there may be some interesting bugs lurking in huge stacks, but we are making progress in this area: we just got a 1.4 GB hard disk to do testing of large stacks. Now for a back of the envelope calcuation... 500,000 cards with a minimum of 64 bytes of overhead per card and about 256 bytes of text per card would give us 152 MB of text, not including room for HyperCards internal indexing. I guess if it was even double it would still fit on a CD-ROM with some room for growth, but looking through the stack... who knows the search time... I hope it would be good. Yes, you could automatically build the stack for an ASCII file. I built a stack from 4 MB of ASCII text and it took an evening. Figure accordingly... All in all, your proposition may not be that feasible, but it does give us something to shoot for as we enhance HyperCard. Dan Allen HyperCard Team Apple Computer