What do you think the advantages of DBFs are? I am going to do a comparison, and I want to be fair to DBFs.
Advantages to SQL (SQL Server, SQL Server Express, MySQL, Informix....) too, if you want.
Easy to develop
No runtime costs/client - SQL Server Express is free as are several Open Source products
portable: can run on a local drive, NT/2000 server, Novell, Samba - This needs some support: why is this an advantage?
Can be accessed Natively by a handful of languages -- Mike Helland
Open. As in Not Secure.
Can't back up an Open Table Not so see Backup Open Files
2 files for a Data Table
3 files for one with Memo's
SQL based database
Wide selection of datatypes, including Identity, GUID, 64 bit BigInt, not to mention Custom, Table, Cursor, Variant...
SQL Server Express is Free
not portable, only runs on Windows (NT/2000. Win9x,Windows CE) - This only applies to MS SQL - I would say the rest (My Sql, Informix, Oracle…) run on a variety of platforms.
Apples and Oranges
I disagree with most of the supposed advantages because they leave too much out of the equation.
A DBF (a file with repeating sequences of data): There are at least half a dozen data access engines available to get at the data in a DBF. These range from pre-compiled programs such as VFP, VdB, to Code Base C libraries.
A SQL database, which uses a software engine that _always_ sits between the data and the client (the actual structure is hidden from the developer).
Speed: depends on the developer, the software, the access method used, the network load, server load, and the hardware.
Easy to develop: many of the same development tools may be used for DBFs and SQL.
Scalability: both may be scaled, SQL is a purchased black box solution with many users, and much testing already done.
Live backups: available for both DBFs and SQL. DBFs involves the developer, or Backup Open Files, SQL involves responsibility shifting to the IS backup people.
The choice is a lifestyle change IMO, not a choice of which is better, unless security is the issue.
Also, don't forget that it may require user interface and workflow changes to a legacy app to make the switch. For instance, if users are used to being able to fast forward and rewind to the top and bottom of a giant table and scroll every record in between without requesting record sets using criteria, this could be a problem for making the SQL argument. -- Randy Jean
Another common UI feature in most non client/server desktop apps (that is also hard sell to change) is that of pre-populated dropdown lists for lookups. These are real fast when coming out of DBF's even if you are using views. If they are of relatively large size and you are going to use SQL, uh-oh! Time to change to list forms, etc. We have an app now that was designed with all surrogate keys and no user entered keys (candidate keys) so this will be a problem. The users have grown accustomed to IntelliSense type entry for these fields. For fast data entry, you need to have codes that the user can enter vs. always having to select from a dropdown or a list form. So, what I'm saying is that DBF vs. SQL can be a lot more than just looking at the data, it can definitely require changes to the overall presentation design, too. -- Randy Jean
Just an FYI - There is an excellent quick-fill textbox control that uses SPT that is described in Creating Visual FoxPro Applications with Visual FoxExpress. -- Randy Jean
Exactly. Using SQL is great if your clients can handle only getting some of the data. DBFs are perfect for those clients whose
needs wants merit having access to all the data, all the time. Mainly, though, it's a big design issue: real-time, or 'refreshing'?
Besides, I've always seen a DBF solution as more in-line with smaller businesses, or those who don't really need to centralize their data. -- MattPorter
MS SQL2000 pricing http://www.microsoft.com/sql/howtobuy/default.mspx#E2G
I tell people: SQL Server Express (free) for small to medium shops or $20,000 for unlimited. -- ?CFK
Last I checked an unlimited seat, single CPU license was less than $5,000 -- Randy Jean
You need to check your usage against the license you intend to use. For example, you will need an unlimited license if running a web server/service as you don't know how many end-users you will have. Add another CPU or a backup server (or a test server) and you need more licences. Still, you're probably getting more revenue, right? ;) Rob Spencer
On the subject of pricing: If an app is distributed with SQL Server Express, can Enterprise Manager be included? If not, then how much must one pay? -- ?CFK
Not sure how long this has been available, but SQL Server Express has free management tools that can be downloaded and used for free. Yippee! -- Randy Jean
You are forgetting; MySQL is essentially free for Linux boxes.
Not essentially, it is free. It runs on a free OS with free clients, so it is free. There are also some other arguments made here that do NOT apply to MySQL.
(necessarily) free anymore unless your client application is GPL . MySQL was free but it turns out this is not always the case.
You will need to read the licensing agreements very carefully to determine if you are legally required to purchase the software and/or license. I strongly encourage you to go to the website http://www.mysql.com/company/legal/licensing/ and check for yourself to see if you need a commercial license.
If I read the licensing correctly, a commercial license is required if you are shipping mysql with your product. It's probably just as easy to stipulate that your clients have a running instance of mysql that you can connect to. -- Brian Marquis
What, no learning curve? You learned SQL Server at one time, didn't you? Or, for those who haven't learned yet, You have a choice of what to learn.
See also: My Sql
Contributors Carl Karsten Alex Feldstein Randy Pearson wgcs Jason Nance, Randy Jean
Category Data Category Application Design Category Needs Refactoring
( Topic last updated: 2008.04.22 07:32:00 PM )