I don't believe it...

[MasterRacker]

I've had the "pleasure" of inheriting an app built on the Progress database. There is also a SQL Server version, however the vendor sold my new employer on the Progress version claiming the SQL Server version is slow. In the past I also supported a FoxPro base app, where the vendor is porting to SQL Server but claimed they had a hard time getting performance out of the SQL Server version. In this case I know they were developing a DB independence layer allowing the same client to use either backend, to the point where they were even trying to duplicate the FoxPro indexes on the SQL version. Personally, I feel this is a mistake.

IMHO, I just don't see how a properly designed client/server app wouldn't outperform a shared-file DB. I think these vendors are jumping into SQL without the proper knowledge or trying to do a straight port without optimizing for the new platform. Am I wrong about this? Other comments?

_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[PRPhx]

Yor right. A well designed client/server app DOES perform well. I'm using one at work. It's based on MS SQL Server 2000. The main db is approx 12 GB! I have over a thousand tables and approx 500 users. It's an image retrieval system, with the images stored as individual tiffs. The db is used to store index info about each image, along with info about each and every field, along with other info.

 

[HarleyQuinn]

If people have any skill at SQLServer (or indeed SQL, not meaning you MasterRacker there) there should be no problems with the using it at all, in fact, I'd prefer it (but not to Oracle, but that's personal preference )

HarleyQuinn
---------------------------------
The most overlooked advantage to owning a computer is that if they foul up there's no law against wacking them around a little. - Joe Martin

Get the most out of Tek-Tips, read FAQ222-2244 before posting.

 

[Olaf Doschke]

Hi MasterRacker,

I'm in such a situation as well, porting a foxpro database to MS SQL Server. We have roughly planned it the way you describe: as straight port without recreating all those indexes. But We're also reimplementing the main application that uses that database, which makes it easier to also do some minor design changes regarding normalisation and field name conventions.

I'm looking forward to be able to use stored procs to aggregate some data which is the slow part of the application now. But indeed some things are very good and fast with a file based database. Seeking a single record does not have the overhead of connecting, sending sql, compiling and pulling this all through the data acess layers like ODBC or even OLE DB.

We made some performance test with one critical and lenghty process of comparing recipes, and the SQL Server gye was proud SQL Server was faster when more than about 50 recipes were compared. Nice I said, but the normal case is comparing 2 or 3 recipes. The point is the rsulting excel sheet should be readable to humans...

But the point is, if a database grows a certain size, has a certain number of users and a certain value, SQL Server is more secured. An querying small sets of data may be slower but still fast enough, within the 3 seconds response times a user can wait for this data in any case. And a server always wins in situations were you need a small amount of data aggregated from a large amount of data. As long as the server has enough resources for all the users (in my case about 500).

Bye, Olaf.

 

[jrbarnett]

One of the systems I support is a personnel and payroll system, written in Cobol. We use an ISAM database, sitting on the D: drive of the server for this app by default, then do an overnight conversion to SQL Server, which is used for reporting.

Why?
- We can just use the SQL Server database, but the performance when carrying out certain functions (notably performing a pay run) is nothing short of abysmal: 2 hours on SQL Server; 10 mins on ISAM.

I can only conclude that this payroll system and your app come from the same team of developers...

John

 

[SQLSister]

Virtually every commercial software package I've ever supported (or seen demonstrated or had reason to get into the guts of) that supports multiple database back-ends is slow. I believe part of this is bad database design (OOP prgrammers should never be allowed to design databases but that's another issue) in general, but I also believe it is because the decision to support multiple databases means that it is impossible to performance tune the queries as much of what needs to be done to really make queries perform better is database specific. What will increase performance in SQL Server is not always what will improve performance in Oracle because their database engines handle things differently.

"NOTHING is more important in a database than integrity." ESquared

 

[oradba101]

In some cases, a product that can support multiple databases has all the programming written from the front end as opposed to the back-end database. So instead if using PL/SQL for Oracle, T-SQL for SQL Server, etc. which is more efficient most vendors will program the database operations from the front-end app. This, I believe, is what causes the slowness.

Regards,



William Chadbourne
Oracle DBA

 

[Thargy]

RANT ON

Database Independence belongs in the same folder as those queries written by experts, along the lines of

SELECT * FROM ANYTABLE WHERE ANYCONDITION IS MET AND FAST=TRUE.

The really vital bit for database independence is the FAST=TRUE. Failure to use this widely recognised piece of pure programming excXXXXXXellence will always lead to misery.

Has anyone ever made a business case for database independence? If so, what was/is it, as I for one would love to hear the pearls of wisdom which must surely emerge therefrom.

To my knowledge, the only way to provide genuine independence is via stored procedures, which present an identical interface to the outside world, regardless of the underlying technology. In this way, the database is free to be tuned and administered in the best way, without having to worry about the front end. However, I would also love to see two identical interfaces, no matter how well written, in say T-SQL and PL/SQL.

In the real world, these will require different OLE DB drivers (or some such) so you will not be truly technology independent, as even then you will be dependent on someone's driver technology.

I despair when I read that such drivel is still being espoused by so-called experts.

Rant off.

T




Grinding away at things Oracular

 

[harebrain]

Don't forget that Progress isn't just a DB engine, it's an app dev environment. Progress isn't strictly relational, either, as it allows such things as array fields. If the app is written in this environment, and it uses Progress's "extra features," a half-*ssed port to another DB is bound to be miserable.

But look on the bright side: Progress is a lot like dBase.

 

[piperent]

I concur with 'harebrain'. What he refers to as 'extra features' are, in fact, part of the whole and provide the inherant functionality that makes Progress what it is. What Progess does in it's own database using it's own internal 4GL language is everybit as functional, fast, and dynamic as what would be found in a SQL counter-part. In fact, Progress's built in SQL engine can return a complete dataset in comparable time. SQL is slow in doing specific things, where-as a properly indexed database (whether it's Progress, DBase, Informix, Sybase, or whatever) reduces the number of accesses required to find data, thereby giving much faster responses to specific queries. They all have there place and perform well when used properly. So, don't sit back and think that SQL is the be-all and end-all. It's not, and never will be.

IMHO, you use the tool that best fits the job, not the tool that best fits you.

Just my 2 cents
JP