Ok, I will try to chime in this subject:
#1-- SQL hides your data behind layers of magic “You don’t own your data if you can’t see it.”
#2. Filesystems are more transparent, flexible, and AI-friendly “AI loves structure. Not secrecy.”
SQL is "magic" or "mysterious" or "incomprehensible" --yes, but only to anyone who does not understands it. Just like DBFs are incomprehensible to my cyclists friends who are great cyclists but have never seen the command prompt. SQL is not more complicated. Just different.
4. Query logic should live in your code – not buried in a database engine
This sounds nice, but in reality it is a lot easier to have your database reject certain transactions or behave in a specified manner than worrying about any possible way that any given code here or there that I may forget exists and writes or reads from a table may behave under certain unforeseen conditions. Why not just have the db centrally enforce the rule?
5. Want auditability? You won’t find it in SQL logs. * With files, auditing is easy:
* Use Git, rsync, `diff`, or timestamped snapshots
* With SQL:
Uffff, nothing further from the truth. I can't imagine asking a user to git, svn, diff, or anything else looking for how data changed, by whom and when. With SQL I simply have a trigger that writes to the audit table anytime a record is added or changed or deleted. Show audittrail table records that match a unique record id to see the audit trail on any given record. That's it. User gets to see full auditing. All you had to do was write the trigger that logs changes and you only write that once.
I'm sure a dbf user does not miss, money fields, or blob fields, or timestamp fields, or VarChar fields, or TinyInt fields. A DBF user does not miss long field names like: PropertyPhotoID and the such. **BUT** once you start using these fields, break through dBF limitations, start using triggers, have db enforce data integrity where no child is left orphaned... it will be hard to go back.
I can understand smaller systems with 5 or even 10 users and 10k records working with dbf fairly well. But if you ever aspire to have your system be used by 25 concurrent users, store millions of records, with with extended field types... I would think past dbfs. Even for smaller systems with less than 50 tables and 5k records, I find it is safer, easier, faster to write using some SQL.
I see Mr. Rao has done a great job at making it easier to transition to MySQL. He even has a method to import data from dbfs to MySql. I had to write my own since I was porting from ADS, including stored procedures and functions. My advise is to take advantage of Mrs. Rao's work and jump right in. Eventually SQL will be second nature and you will have a hard time staying with just ISAM on dbfs.
BTW-- any hosted server (Amazon, Oracle, DreamHost...) have MySQL db already configured so your system will run on any 3rd party server.
Just something to think about.
