"Подолью" еще немного масла в огонь. Это мнение одного из профессионалов - Rick Strahl, занимающегося производством программного обеспечения для электронной коммерции (прошу извинения за английский язык - к сожалению, я не видел перевода этой книги в сети):

To SQL or not to SQL

The question of whether to migrate an application to a SQL back end invariably comes up when dealing with high-performance server applications. When you think about back-end data, keep in mind that VFP has an amazingly fast data engine—if speed is what you're after, VFP is likely to be the best choice, while SQL Servers provide security and data stability.

Using Visual FoxPro data

There are good reasons to migrate to a SQL back end, but many applications may not have a need for them. FoxPro works well even against very large data sets, so take the time to test performance. Don't blindly jump to a SQL back end! Consider the following points:

Native data is great for server back ends.
For server applications, it's appropriate to use Visual FoxPro as a local data source because only a small number of simultaneous VFP clients access the data at once. Data is usually local to the machine on which the server is running—or it's on a fast, low-volume network. Unlike many standalone network applications, in a Web application a data connection is not from the user to the database, but from the Web server to the data. The execution environment is also very controlled because data access occurs from a server rather than from end-user client machines. Many data-integrity issues that can crop up in typical network applications—with large numbers of clients stemming from configuration and client problems—are not an issue with server applications.

VFP performance is much better than SQL.
Keep in mind that VFP has an amazingly fast data engine. If speed is what you're after, VFP may be the best choice. I worked on one application that, when I converted from local VFP data to a SQL back end, data access ran between two and three times slower for short requests and five to 10 times slower for complex queries and administrative tasks. Proper tuning of SQL Server (which took several outside consultants several weeks) brought this down a little, but still left SQL Server running nearly twice as slow on average. Where performance counts, Fox data is an excellent choice. Even if you are using SQL Server data, take advantage of the Fox engine by downloading and caching static data in local cursors to save round trips to the server.

VFP can handle large data volumes.
I worked on one high-volume commerce site where VFP back-end data was used with servers peaking close to 750,000 back-end hits a day on a single, four-processor NT box. The actual day-to-day operations of running an online shopping site ran flawlessly.

VFP has problems only with batch updates against heavily used, live data.
So, why switch to SQL if all is rosy? There are a few problems with VFP data access on operations that should normally be left to EXCLUSIVE use. On this project, there were issues dealing with the frequent data updates that performed large imports into live, online databases. Many of these operations could have been performed with EXCLUSIVE operation, but this wasn't possible due to the time these import operations were taking. With multiple active servers, these update operations running against live online databases would occasionally corrupt the database and the indexes. Operations that turned up these problems were APPEND FROM and DELETE on large groups of records, while other instances of Visual FoxPro were actively using these same tables. (Note: These issues could have been worked out, but a management decision at the time forced the move to a SQL back end anyway. The moral of the story is that you can get around these issues if you can recognize the problem when it occurs.)

Using a SQL Server back end

Fox data is fast, but SQL Server provides a number of features that are simply impossible to accomplish with FoxPro data. In many situations, the tradeoff for performance can be worth it. The advantages of a SQL back end are:

Improved stability
The main reason for the move to SQL at the above site was for better stability. Getting away from the DBF/CDX file structure has resulted in significantly improved up time. The environment and nature of online batch updates mandated this move to get around data consistency problems encountered with native VFP data. The biggest problem with native data wasn't the fact that it got corrupted, which happened only on very few occasions—it's that it went undetected for quite a while, causing inconsistent but not easily traceable problems on the live site. As you might expect, those kinds of problems are almost more serious than outright failures that are immediately visible. With the SQL back end, data corruption has never occurred, albeit at the cost of very lengthy and slow updates that often lock out users while the operations run.

50+% performance loss (SQL and Internet overhead)
Overall, application throughput dropped by more than 50% when the move to SQL Server occurred. If you're moving from Fox data to SQL Server you'll almost certainly face a similar performance hit.

Lightened CPU load on Web server
SQL Server was installed on a dedicated server machine and migrated much of the data processing load to the SQL Server box, away from the Web server/VFP machines. Running a complex query on a VFP front end won't cripple the Web server because the CPU-intensive query now runs on the SQL Server. The idle CPU power can then serve other requests and more connections. The flip side is that SQL Server is now bearing the majority of processing load, with the majority of CPU power focused on the data access layer. This has potentially expensive implications if the SQL back end must be upgraded. Scaling a SQL Server beyond a single machine is difficult and expensive as well.

More complex data access issues
The move to SQL also brought difficult issues in terms of data administration. SQL servers are hard to deal with for large update commands and purges that occur on heavily used data. Locking issues can make it impossible to update data that's being operated on—extensive use of stored procedures and sectioned processing is often required to accomplish tasks such as clearing out log files. This was one reason for moving to SQL on the Surplus site, and as it turned out, these issues were not addressed, resulting in update operations that would at times take more than 10 minutes, compared to 30 seconds or so in native Fox data. General administration of SQL Server is also more difficult: Tuning the server, managing security, maintaining data partitions, and monitoring backup and performance are not trivial tasks. They require personnel with previous experience or training, or outside consultants who specialize in SQL administration. SQL Server 7.0 makes this process somewhat easier through improved self-tuning logic in the server and much improved administrative interfaces, but knowing what to tune when the time comes still remains an important aspect of any SQL Server application. If you don't have the in-house resources, be sure to budget outside help—tuning a SQL Server is one of the most important aspects of a successful SQL application.

Was it worth it? Yes!
In retrospect, was it worth it to give up the huge performance benefit of local Fox data? In this case, most definitely yes! Stability of the application went way up, and the site experienced fewer problems getting locked or stuck with data-corruption issues. Centralized data access and management through SQL Server has also made the administration process more centralized and allows automating some of the heavy data-maintenance tasks in the middle of the night. The tradeoff was performance, which was addressed by bringing more concurrency to the front ends by adding additional machines to take requests from the Web server.
Weigh the advantages and disadvantages of VFP and SQL Server carefully. SQL Server 7.0 presumably improves performance considerably and eases some of the locking issues that continue to be the biggest problem in the batch update process. Fox data can go a long way for you, so compare your options and requirements to what you can accomplish.