Do some research on database normalization and on naming conventions for tables/fields/indexes/sequences. There are varying schools of thought on both so I can't point you to one correct answer to rule them all. But having just about any set of rules and adhering to them strictly is better than having no rules at all. Doing so just prevents a class of problems you don't want to deal with.
Write down your rules and disseminate them to the development staff who will be submitting schema change requests. Think of them as commandments, like "you must always <do this thing>" and "you must never <do that thing>". It may take some time and some iterations to get to where you want to be but the process of creating the rules and the process of enforcing them is important.
Maybe the developers will help you refine what you want. They might come to you with a change that doesn't satisfy a rule but they present a compelling case for changing the rule. But if they don't comply for no good reason, like they're running late or they're feeling lazy or they copied some code from the internet, don't make exceptions. The rules are the rules, until they change.
A nice benefit of having rules that you always adhere to is that you can eventually create tooling to help with scanning the quality of the proposed changes. For example if you know that every table must have a description, a program could scan a proposed .df (or a database created/updated from that .df) and test whether every new table satisfies that rule. You could even make that scanning program available to submitters so they can pre-scan their changes and don't waste your time with change requests that you will reject.
Take a look at some .df files and note the possible attributes for each type of object: tables, fields, indexes, sequences, LOB columns. Which attributes do you consider essential? Make rules that they must always be included. In my past life, because we didn't yet have such a system in place, I wasted time going back to developers to get information that they neglected to provide in a .df or I rejected their change because it was obviously incomplete. No descriptions or labels? Rejected. A table with no indexes? Rejected. Array fields? Rejected. Fields that are named differently across tables? Rejected (though maybe hard to detect). But that back and forth is a waste of everyone's time.
Also, give some thought to modern best practices. There are a lot of things you
can do in OpenEdge, but that doesn't mean you should do them in 2021 and beyond. Examples might be array fields (extent > 0), file and field triggers, tables without indexes, etc. And there might be other features or design decisions where you won't necessarily reject the change outright but you will flag it for further discussion because you consider it "use with caution". Example questions for developers:
- Do you really want to create a CLOB column to store that big SOAP request after you process it?
- Couldn't it just be written to a log file?
- If not, why not?
- If we approve this, what happens when it becomes huge and is a maintenance headache? Have you considered the life cycle of this data?
- Do you really want to create an entirely new database to store that one new table and its indexes?
- Do you understand all of the implications of that?
- Can you list them?
- Do you really need 250 fields in one table?
- Could this better be split into multiple tables?
- Are all of these fields actually attributes of the entity being modeled, or are they attributes of some other entity related to it?
- Do you really want to create an abbreviated index?
- Do you really understand the implications for the DBA of adding a word index?
Another problem I've seen is "digging the hole deeper". A development team works for years on a product without such rules, or with bad ones, and rejects adopting new rules because "it would be too time-consuming to change everything to the new paradigm" or "but we've always done it this way and it works". If you have an existing application and are trying to deal with your technical debt, it is never too late to do better. Consistency isn't a virtue when you are consistently following a worst practice without even knowing why, just because it's always been done that way. Having a 500-table application where 450 tables have confusing and inconsistent names and 50 tables are well designed and documented is better than having 500 tables where they are all similarly bad.