What Was Wrong With Dbase

It was pretty easy to make applications in dbase [ExBase]. I don't know of our increasingly complex environments have bought us much over dbase.

DBase couples the persistence to the logic and the (G)UI. Coupling is bad. Modern languages are powerful enough to persist transparently, so they decouple the data store better.

I generally disagree with SeparateDomainFromPresentation, as described in that topic. Indirection is not free. Spend it wisely. --top

{Relational is about much more than just persistence. It is an organizational technique. True, dBASE was only semi-relational, but the issue still applies. In theory the actual implementation could change. The database interface was just that: an interface. Clipper, a dBASE derivative, for example allowed one to swap the database engine with little or no code change. There were multiple vendors of the underlying engines. Some even were put on top of dedicated RDBMS, such as Oracle. However, the cursor-nature of dBASE often did not work very efficiently with the set-based nature of the "more pure" relational. There was a sort of ImpedenceMismatch? caused by cursors versus sets. This mismatch is part of its downfull, that and the growing popularity of OO (deserved or not).}

Is your concern about generating value for your customers or coupling?

When you can't change X without changing Y, customers must wait longer for your value.

Sometimes neither X nor Y will change. Sometimes changing X and Y together is easy. Not every app grows''.

And many times an app grows by changing things together. We spend a great deal of time separating the front end and the back end when it's often not necessary. It just creates more work. One should DoSimpleThings.

I liked dBASE a lot. It was a great RAD tool for small-to-medium projects. However, you had to follow certain design rules to keep non-trivial projects from turning into a mess. In that sense, it is kind of the Perl of Tables.

"A mind is a terrible thing to DBase" --PhlIp