I worked a lot on a legacy system developed in Progress ABL (formerly unknown as Progress 4GL). I am still working on that system, but I am mostly an analyst no

I worked a lot on a legacy system developed in Progress ABL (formerly unknown as Progress 4GL). I am still working on that system, but I am mostly an analyst now and don't really write code (only short scripts to extract data). We still use it because a core application has been developed in it for the last 20 years, and replacing it with something else is currently unfeasible. It's a sort of PL/SQL for a non-relational DBMS. It recently (last 5 years?) got OO extension - the product is still used/mantained/extended. To be honest, I doubt that "we could learn" much from it. I mean "RDBMS were not just a fad, after all" is not something we need to learn, right? (and no, it's not part of the NOSQL family, it is just old and odd). Some other lessons we don't really need to learn now are, off the top of my head: - I think we don't really need foreign keys, folks - What about something like a virtual table that only exists in memory but which allows you to optionally revert any changes on it by doing a rollback? (except that if you do that you also rollback any changes to the real tables, of course) - Views are just a passing fad, also, foreign keys are for sissies - data integrity is done in your application. - You know what? we could do query optimization at compile time instead of at runtime, it will be easier for us to write the query planner, even if this also mean that if you add an index later you have to recompile everything. - You keep harping on this concept of foreign keys. Listen, just use a strict name convention for fields and things will sort fall in piec... I mean in place by themselves. - Function/Procedure signatures are not really hard enforced so... if you have a function with 23 parameters and you call it with 22 (or 24) it will bomb at runtime because the compiler will not warn you. - Speaking of signatures... we all know that dates are really an epoch plus a real, no? So I think it's sorta ok if you pass a number to a procedure that has a date as input parameter... Some of the points mentioned above might have been mitigated in the more current version (or will be in the next one) except for the foreign indexes because those will stay like that forever (officially declared in their roadmap 2 months ago).