Conference ilbbak::ibi_focus

>>I know that this topic has been discussed over and over, but since I'm quite
>>new with FOCUS, please give me some experts' ideas.  I quite understood that
>>FOCUS/Rdb is very slow compared with FOCUS database or Rdb database query.

	This is mostly myth in my opinion.  I've used FOCUS to query
	(report from) RDB, RMS and FOCUS files and I can't tell the 
	difference.

>>N, is using FOCUS/Rdb, but they're using PowerHouse between FOCUS and Rdb to
>>increase the database query performance.  From my point of view, using 3
>>database systems is more than enough for my new customer to handle.  Please
	
        This I don't understand.

>>more than 30 sales sites covering whole Japan.  So, I'm proposing to use
>>VAXes to distribute the database with Rdb/VMS and VAX Data Distributor.

	Sounds like a great idea.

>>However, since the customer has so many FOCUS procedures, they do not want to
>>write high-level language programs with DEC Forms.  And I found out the
>>performance of FOCUS/Rdb query...  What could I do?
	
        I thought we were talking about querying, now you jump into 
	transaction processing.  I've only done one TP application (external)
	using FOCUS/RDB.  Doing simple screens hitting on one or two
	relations is something FOCUS can handle.  FOrget batch transaction
	processing (unless IBI improved over the past year).  

>>Well, I'm still considering to use FOCUS/Rdb with VAX Data Distributor.  I
>>want to propose to build FOCUS database after distributing the Rdb database
>>in batch mode, every night.  How does this sound like?  How will you answer
>>to this question?  Any comments are welcome...

	Sounds unnecessary.

>>Also, I quite like the FOCUS's ALL-IN-1 interface, too.  Since I can make
>>FOCUS looks like a part of ALL-IN-1, and I can maintain FOCUS files with ALL-
>>IN-1's file cabinets.  Why shouldn't I use Datatrieve instead of FOCUS?

	You would do better to buy a dog.

-richard

	I continually hear folks complain about FOCUS against Rdb for queries,
	but, with some tuning of the database as well as some of the FOCUS
	procedure being 'optimized' to use the tables in the database better,
	I've found that it can work.

	I worked on a project a while ago to convert over our FOCUS databases
	to Rdb and at first it seemed discouraging to find the performance
	taking a hit.  By going into a heavy pilot mode and working with the
	users to find out HOW they were using the data most frequently,
	we (the team) brought up additional indexing as well as denormalized
	sections of the database to improve performance on the database with
	FOCUS.  We didn't go live with the system until the users accepted
	the new system as well as the performance.

	I helped a lot of FOCUS users to 'modify' their fexes just a little
	bit here and there and the results were wonderful - making use of
	an index where, perhaps, they weren't originally, using the fields
	on the database with edits or masking versus doing a lot of DEFINE
	for the  tables on the database...there's a lot we did and I can
	say that in 90-95% of the cases, we were able to get the performance
	as good as or BETTER than what they expected from the FOCUS tables.

	The first database was 2-3 Gig.  The one I'm working on now is over
	15 million blocks in size and we're also using FOCUS against this one.

	Feel free to call or send mail for any additional information....

	I guess you could call me an optimist!

	Lisa C

Thanks, people out there.  People around me has been beating me so bad that
I'm going with FOCUS/Rdb.  Well, your comments gave me a power to go on with
my idea.  I guess I need to do some performance checking in a couple of
weeks, and I really need your comments!

By the way, the reason of using high-level language programs with DEC FORMS
is that we, digital, don't have user-friendly query language.  You know how
FOCUS displays the output, and you also know how DATATRIEVE displays the
output.  DATATRIEVE is a nice tool for engineers, but not for end users.

Please keep me informed with FOCUS/Rdb!

Best Regards,
Clyde.

>> Also, I quite like the FOCUS's ALL-IN-1 interface, too.  Since I can make
>> FOCUS looks like a part of ALL-IN-1, and I can maintain FOCUS files with ALL-
>> IN-1's file cabinets.  Why shouldn't I use Datatrieve instead of FOCUS?
    
    Presumably you mean TABLETALK. MRE V2.1 has a menu-guided DTR report
    writer called DTRTalk, which, in my opinion, is even better than
    TABLETALK. See conference INCH::MRE_INTEREST for further details.
    
    	Terry

>    Presumably you mean TABLETALK. MRE V2.1 has a menu-guided DTR report
>    writer called DTRTalk, which, in my opinion, is even better than
>    TABLETALK. See conference INCH::MRE_INTEREST for further details.

Thanks, Terry.  I'll check that conference.  However, as usual, we have a
problem with its supported language.  I mean, in Japan, English written
reports are not accepted... But I could access the company doing the
Japanization work on FOCUS.  Again, thanks for your info.

Best regards,
Clyde

  reply to .2

>>	I continually hear folks complain about FOCUS against Rdb for queries,
>>	but, with some tuning of the database as well as some of the FOCUS
>>	procedure being 'optimized' to use the tables in the database better,
>>	I've found that it can work.

		I AGREE.  Too often database application problems using
		FOCUS are caused by
		 1. People who don't know enough about Focus  or
		 2. People who don't know enough about database design or 
		 3. A combination of above. 

>>	The first database was 2-3 Gig.  The one I'm working on now is over
>>	15 million blocks in size and we're also using FOCUS against this one.
	
		When you try to move hundreds of thousands or millions of 
		records the efficiency of the code Focus generates to DSRI
		is a factor near the bottom of the list and the list includes
		DB design, Applic. code design, disk and data distribution,
		hardware config.  etc etc   Heck, even a magnet would take a 
		while to move 61 trillion bits.

		I definitely would consider 15 mil blks a significnat 
		challenge using any tool.  Good Luck.  Keep us posted.

-richard

>		When you try to move hundreds of thousands or millions of 
>		records the efficiency of the code Focus generates to DSRI
>		is a factor near the bottom of the list and the list includes
>		DB design, Applic. code design, disk and data distribution,
>		hardware config.  etc etc   Heck, even a magnet would take a 
>		while to move 61 trillion bits.

Oops!  I thought FOCUS was generating SQL accessing Rdb...  Is FOCUS directly 
accessing DSRI?  Sorry for my poor FOCUS<->Rdb interface knowledge...

Clyde.

    Yea, Focus generates calls to DSRI, just like any Digital to RDB product.