Video Migration from DBF to SQL (MySQL/MariaDB) Mr. Rao

[Otto]

Migration from DBF to SQL (MySQL/MariaDB) Mr. Rao
I just watched Mr. Rao's video on how to upgrade to SQL.
Thank you, Mr. Rao, it was very interesting.

Mr. Rao briefly showed the development history—why was a client-server database introduced?
Historical Context of SQL and Mapped Drives
SQL was indeed designed in an era when centralized databases were common, and applications often accessed these databases over networked environments sometimes via mapped drives. In this context, SQL's strengths—like optimizing network traffic, efficient data handling, and centralized data management—were critical because:
- Network overhead was significant when data had to travel between machines.
- Centralized control over data integrity, transactions, and consistency was a primary concern in multi-user environments.

Many people in this forum still do this, and that’s simply a design flaw—there are so many better solutions. The simplest is a microservice, in case you don’t want to spend money on a RemoteDesktop solution. Otherwise, RDP without source code changes is the most economical solution. And most importantly, it’s future-proof, because you can then simply run a web server in parallel—on the same machine!
I think you shouldn’t let SQL’s marketing gimmicks stress you out.

Modern Context: Web Server and Data on the Same Machine
In modern setups, particularly in my case where both the data (e.g., DBF files) and the web server are on the same machine, many of the performance concerns that SQL was designed to address may not be as critical. Here's why:
No Network Latency:
Since your web server and data are co-located, you avoid the network overhead that SQL was initially designed to optimize. Data access is local, so you aren't dealing with the same network delays or bottlenecks.
Direct Access to Data:
When the server has direct access to DBF files or any other local storage, you can manipulate and process the data immediately without needing to pass through the SQL layer. This is often more efficient when your data is in formats like DBF and you control how it's accessed.
Custom Logic and Flexibility:
You have more flexibility to design custom logic that is better suited for your specific needs, especially if you're handling data with a structure (like DBF files) that SQL databases may not natively support as efficiently.
By using low-level functions or custom-built code, you can optimize the processing for your specific use case, eliminating the overhead that generic SQL query parsing and execution might introduce.
Simpler Infrastructure:
Without the need for a full SQL server setup, you reduce infrastructure complexity. If your requirements are straightforward—like reading records, performing calculations, and sending results to a web client—you don't necessarily need the added layers that SQL brings, especially if all data is local.

These points underscore that the context in which SQL was originally designed has shifted. When the data and web server are on the same machine, many of SQL’s traditional strengths—such as optimizing network traffic and providing centralized data management—may no longer be as essential. In such cases, direct file access and custom logic can be a perfectly valid, and sometimes more efficient, solution.
In short, SQL is a powerful tool when it's needed, but in many modern, simplified architectures, its overhead might not always justify its use—especially when alternatives like low-level file access or lightweight databases might serve the purpose better.

Please keep in mind "it is a product of its time." File servers connected over a 10MB network card!

[Carles]

Hi Otto,

Even though it is a “product of its time” it is used by large companies today and for some reason it is.

I am not going to explain the benefits of SQL, but in any case everything comes down to whether you want to use SQL or Dbf technology. But if we focus on choosing Dbf, today Harbour is perfectly prepared to be used with microservices that you mention, webservices,… using libraries such as letodb, uhttpd2, mod-harbour, UT, Runnerxbase,… and there is no other system, none that can surpass Harbour's own RDD in quality and power.

I simply think that whoever wants to use DBF in any scenario has all the necessary tools.

Regards.
C.

[Otto]

Dear Carles,
Yes, you are right.
"I simply think that whoever wants to use DBF in any scenario has all the necessary tools."

But we need to adapt DBF a bit to the present time and further develop it.
I think there needs to be a point where one says, this DBF variant is only for Remote Desktop, where DBF files and the program are on the same server or for web applications.
You can then remove a lot of source code, making everything simpler and more streamlined.

Best regards,
Otto

[Otto]

Dear friends,

Here you can see my web XBrowse using a microservice to immediately store every change of a cell on the server. As you can see, this process takes around 150 ms.

Best regards,
Otto

[Rick Lipkin]

To All

I know I have said this many times in this forum ... \samples\AdoRick.prg is a loaded SQL Sample on what you can do with ado sql and I created a very simple Sql backend with MS Access and use just like dbf .. I put in this sample how you can create a Sql Ms Access table with code, incremental xBrowse look-ups to find records and much more ..

Any questions .. let me know
Rick Lipkin

[Silvio.Falconi]

Otto really I don't understand why one has to switch from dbf to mysql, I believe that we do not manage multiple quantities of data (such as banks or similar) that justify the use of mysql, it is only the trend of recent years to use this type of archive also because by converting on the web it was not possible to use the dbf files even if in the distant past I used ASP / ASPENET with the dbf archives and even created e-commerce shops, then I preferred to use wordpress and woocommerce.