Also: I think knowing your way around triggers and such is quite important too though. I should learn them properly some day.
I've had the displeasure of working with databases with triggers that fire other triggers, and all that logic should've been moved into the application itself. They're a powerful tool to have in your toolbox, but should be used sparingly, and should be kept as simple as possible.
The same table stores: Addresses (primary, secondary), sex, names (up to 3), date of birth, what currency, and many MANY more values.
Yes, that's one table.
Also: Another table literally stores full tables in it. (Basically some kinda key with which to identify the subtable so you can select on it.)
Progress has no real concept of set based queries, instead it accesses all tables like a cursor.
And that's not even scratching the surface. The DB is bad and should feel bad. Just yesterday I went into a 2 hr rant about it with some people I often talk to.
Foreign keys, too, are a foreign concept to progress. But hey, work is work.
However, one thing that could be done is to use views (maybe scoped in their own schema) to make the database look normalized (Facade the database). This would help with writing future SQL.
It is then possible to iteratively normalize the underlying tables by pointing legacy code at the normalized views until the denormalized tables are no longer in use. Finally, "convert" the views into tables and drop the denormalized tables.
(I have to write the sync code from the new system to the old one)
Some denormalization is sometimes warranted. As for the rest I agree with you. Sounds like madness.
This DB is many things, but most definitely not thiught out.
Basically nothing is normalized.