Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
SQL 6.5 vs ORACLE as back end for VFP front-end intranet
Message
De
19/08/1997 17:56:44
Bob Lucas
The WordWare Agency
Alberta, Canada
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Applications Internet
Divers
Thread ID:
00045658
Message ID:
00045686
Vues:
41
>I am involved in the planning stages of some applications being developed for our organization to be used on an intranet. All of the applications I have developed to date have been in Foxpro 2.6 and VFP 3.0 and 5.0. The potential intranet applications will have thousands of transactions added daily. In researching SQL Server 6.5, it appears to be the ideal back end for these applications.
>
>Here is the problem. Someone here wants the applications developed with ORACLE as the back-end. Now, I don't know squat about Oracle, so I'm not going to say anything nasty about it. However, it appears to me that Microsoft SQL Server 6.5 would be the natural choice.
>
>Does anyone out there have an opinion on this matter? Even better, does anyone know of anu documentation comparing the two products ORACLE and Microsoft SQL Server 6.5?

I am currently working on an application that uses SQL Server (5 GB database) and I have worked with Oracle in the past. I don't know necessarily if one is superior to the other although I would say that Oracle is a little more robust. SQL Server has sometimes locked up on us. SQL Server uses page level locking which can sometimes cause problems.

I really like the SQL Server tools (Enterprise manager, ISQL etc) compared to the UNIX interface I used with Oracle. Maybe it's better now.

My current choice is SQL Server but as a developer 'I DON'T CARE!' I can write an app to work with either. (There are differences in stored procedures so some of the code needs to be database aware).

The one thing I don't like with SQL Server is the backup methodology. With Oracle, if you wanted to reorganize data or reduce table extents, you could do a dump of the table, drop it and then reload from the dump. To grow tablespaces after having added some files (ie, reducing a tablespace made up of three files to one) was just a matter of doing the dump, dropping the tablespace, recreating it with a new size and then reloading the data. It was easy to dump selected tables.

SQL Server devices are not like Oracle tablespaces. You can never change a device. When you dump a database you must reload it into devices (files, really) that are exactly the same size as the original. A SQL Server dump is really a page dump, not a data dump like Oracle. It was much much easier to unload and reload data in Oracle into differently sized databases. SQL Server is much less flexible in this regard. I am sure they have their reasons. Put it this way, an Oracle dump will be sized to match the data in the database, not the size of the tablespace. SQL Server dumps will be the size of the database even if there is no data in it!

Make your choice based on the knowledge of the people who have to support the environment. This will be more important than the advantages or disadvantages of one or the other product.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform