Tighter App And Database Integration

One common complaint about using existing RDBMS is that they are not tightly woven with application languages and/or frameworks. A lot of adaption and conversion code and configuration must be provided in order to communicate between each.

Proposed solutions include:

• Use an RDBMS that has an app language built in. Examples include:
  • RelProject
  • DuroProject?
  • Alphora D4
  • Oracle's PL/SQL
  • MS's and Sybase's TransactSql
  • ExBase and other DesktopDatabasees.

• EmbraceSql - An app language(s) that attempts to integrate tightly with existing RDBMS via SQL.

• More to come...

(Please place responses and comments about the list below)

---

Discussion

Most such products tend to be either "client-weak" or "server-weak". Client-weak means that the tool is mostly server bound and has poor client-side tools for a "rich client experience" (powerful GUI). Server-weak means it does not scale well in terms of transaction volume and reliability, such as A.C.I.D. compliance.

Perhaps it's asking too much to do well in both database-land and GUI-land. Tools that try to be everything have a high failure rate as far as market acceptance.

Delphi has always done well because it is both a DB and GUI tool (data aware components and gui-data binding components). Visual Basic has also had data aware components. Aren't these the keys to their success? Problem I see in Delphi is people still use XML, INI files, string lists, and arrays, when they could be using a database built in as if it was a native type inside the language. Similar problems in C++, php, perl where people use hashlists, associative arrays, and containers without having any relational tools in the language natively. Possibly MicrosoftLinq tries to solve some of it in DotNet, but LINQ is not likely theoretically sound or based on enough relational theory.

---

CategorySoftwareTools