Is it good practice to refer to a table with different names in a database schema?
There are many examples of best practices for schema naming e.g. here and here
Keeping it simple and based on experience and opinion of course, when designing schemas, we want:
PrimaryKey: Auto-incremented value in the naming pattern &lt;entity name(singular)&gt;_ID e.g. thing_id or ThingID.
UniqueKey: Add a unique constraint on a unique key. In a strong entity, usually on a real-world reference (e.g. student_id). In associative tables, these are usually on combinations of foreign keys (e.g student_id, course_id).
Foreign Keys: These are references to auto-incremented values in their source tables and so are the same data type and name as the values they reference. So without looking at the whole schema, if I see ThingID in a different table not called Thing, I know it points to the primary key of the Thing table.
In your case, I would say you should:

First decide what the correct solution should be for future maintainability and support of the schema alone without any other considerations. Imagine you are a new team member and you look at this new design with its naming structure, would you be able to understand it?
Determine what is preventing the team from executing the correct solution e.g. no one is comfortable with the code base or you didn't write it or you don't feel that anyone on the team has the wherewithal to modify the code and not break the application.
If #2 is insurmountable, then consider


a. Making the changes in #1 but add a layer like a view (add a &quot;v_tablename&quot;) with the same old names and call the views instead of the tables from the code so the application works
b. Making the changes in #1 but add a layer or interface in the code base which allows some mapping of new field classes to old existing field classes so the application works
c. Isolate the schema and application in a separate parallel environment in which changes are made in both code and schema and verified thoroughly to ensure that the application works.


If you have zero access to the code base, then you just make the correct changes for the new tables - perhaps using a prefix-naming standard so you can identify old schema vs new schema.
If old schema has the correct naming, of course continue with it.

Overall, treating the codebase with undeserved trepidation can force inch-by-inch workarounds/accommodations and eventually, the team ends up with a design and system in both code and schema that no-one fully understands. This possible reality can add risk to your organization.