FiveTech Support Forums

But it has some limits regarding access, security, navigation, etc.

Hello,

I develop software with MS Sql Server sinse 10 years .

I 'll no more use DBF in network development.

Select with linked table is very easy .

Have a good day .

Philippe

#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.”

4. Query logic should live in your code – not buried in a database engine

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:

Dear All ,

SQL has strong features:

a) Powerful Indexing almost no rebuild is needed

b) SQL does aggregation in very few lines

c) Strong transaction management for OLTP Apps

d) Concurrent Management

many more...!

Thanks

Shridhar

Hi Reinaldo,

Thanks for the input – from a technical point of view you're right: most hosted servers come preconfigured with MySQL and are ready to use.

However, things are quite different for us here in the EU, especially in Austria and Germany. We have to follow strict GDPR rules when working with personal data – and that makes using third-party hosting (like Amazon, Oracle, etc.) more complicated.

Key points we need to consider:

Data transfers to non-EU countries (like the US) are problematic due to legal access (e.g., the CLOUD Act).

A data processing agreement (DPA) is mandatory – and must be actively signed.

Technical and organizational measures (TOMs) must be clearly documented.

Full transparency is required about where and how data is stored and processed.

That’s why many of us prefer EU-based or even self-hosted solutions when dealing with sensitive user data.

Best regards from Austria!

Otto

Hello,

I fully agree that SQL brings powerful features, especially for classic business systems:

a) Powerful indexing with minimal rebuilds

b) Fast aggregations in very few lines

c) Reliable transaction management for OLTP

d) Great concurrency handling

These are well-proven advantages, and they make SQL a great choice for established use cases like financial systems, administrative records, and structured reporting.

But I’m currently working on something different — a highly dynamic, context-driven workflow for processing human communication (e.g. anonymized emails, JSON mappings, context-aware responses). Everything is in constant flux:

The data structure is semi-structured at best (e.g. [Guest:ID], [Date:ID])

Placeholder formats evolve frequently

Contextual logic (e.g. temporal flow, RAG-augmented reasoning) is essential

Workflows need to adapt quickly — not go through migration scripts and schema locks

In such a case, I feel SQL might get in the way rather than help — and that file-based + script-based approaches (e.g. JSON + Python) offer more agility.

That said:

Are there scenarios where SQL could still add value in such dynamic, non-relational contexts?

Or would you agree this falls outside of where SQL shines?

I’d love to hear your thoughts — especially if you’ve built hybrid approaches.

Thanks!

Otto

SQL is great for transaction based workflow, but it is a nightmare for strong interactive apps.

Dear All ,

UPI Indian Payment System is great example which is running on SQL database e.g. Oracle , PostgreSQL , MySQL approx. 1000 TPS in one bank.

Thanks

Shridhar

Thanks Shridhar – technically you're right, but here in Europe a system like UPI would never be built with something like Harbour. It lacks scalability, security certifications, and enterprise support. Harbour is better suited for small, local business applications.

By the way – are you really considering Harbour for such systems, or was it just an example?

Best regards,

Otto

Dear Otto ,

As Harbour using C platform it should be used also to develop scalable apps. I am not expert in developing languages but I do not know what it is lagging HVM from JVM ( java virtual Machine ) ?

Thanks

Shridhar