Потребность в переименовании таблицы - вполне естественна при развитии БД, так же, как переименование полей, функций, исключений, представлений, доменов и всего остального. Для чего это нужно - очень хорошо написано в книгах по рефакторингу (как программного кода, так и баз данных (да, даже такие уже есть)).
В своем проекте я переименовывал ВСЕ таблицы минимум три раза. Первый - переход к префиксам (STREET -> DIR_STREET), второй - переход к категориям (DIR_STREET -> DIR_ADDRESS_STREET), третий - переход к $ как разделителю (DIR_ADDRESS_STREET -> DIR$ADDRESS$STREET).

Озвучу следующие причины переименования таблицы:
1. Внесения ошибки в имя (человеческий фактор);
2. Изменение назначения таблиц, что должно отразиться на ее имени;
3. Изменение принципов именования метаданных;
4. Переработка унаследованных БД.
5. Расширение функций проекта.

Например, был справочник узлов газоснабжения "DIR$GASSUPPLY$UNIT" (ГРУ/ГРП). Там было еще несколько справочников, относящихся к газоснабжению. По прошествии времени выяснилось, что надо добавить справочники: типов узлов, назначения, источников газа, связки услуг и узлов, и еще несколько. В итоге в группе DIR$GASSUPPLY$ образовалась мешанина из справочников различных областей. Путем переименования всё, что относится к ГРУ/ГРП, было выделено в отдельную группу DIR$UNIT$.

P.S. Здесь рассматривалось только теоретическое обоснование, а не вопрос сложности этой операции.

TPAKTOPA,

Я с тебя удивляюсь. Ты правда считаешь, что я вот так, взял, переименовал таблицы, поля и сижу довольный, что сломаны отчеты, экспорты, печать извещений и прочее? У тебя проект с гораздо более сложными связями, и основания для переименования метаданных должны быть соответствующими. Мне - проще. Проект один, разработчик - один, поэтому безбоязненно переименовываю метаданные так, как считаю нужным (обычно пачкой, так проще). Программный генератор запросов сделает все за меня, а настроенная подсистема тестирования отчетов, экспортов и прочего сразу же собщат о проблемах. ES нет.
Почитай книгу "Рефакторинг баз данных", там есть методические рекомендации по различным видам рефакторинга БД, в том числе как быть с крупными БД и как с мелкими. Так вот, в случае крупных БД или БД со множественными связями, шаг рефакторинга может длиться годами. То есть создали новую таблицу, перелили данные, настроили прозрачную работу приложений с новой таблицей как со старой, обновили ПО, удалили старую таблицу.
А рефакторинг нужен, так как метаданные, так же, как и исходный код, со временем начинают гнить.
P.S. Не надо переходить на личности.

Мимопроходящий,

А рефакторинг ПО?

Di_LIneCyberMaxА рефакторинг ПО?
... опиум для неокрепших прогерских умов.
Бо оное потребно лишь при изменении бизнес-задач, кои отражает ПО.
А если новые задачи, то и ПО - new.
Остальное - красивое название латания собственных косяков. :-)
То есть конкретно ты, Диля, закончив вуз и устроившись на работу программистом, тут же начал писать четкий и ясный код, не ошибившись в выборе имени переменной, не изменив впоследствии назначение переменной, класса, не спускал/поднимал поле/метод по классовой иерархии? Не приходилось сливать вместе классы, расщеплять классы? Не приходилось чистить исходники, удаляя остатки кода, устаревшие комментарии, неиспользуемые методы, дублирование функциональности?

Мимопроходящийиз программки для овощного ларька не получится слабать ЭРП.
А из чего получится слабать ERP?

МимопроходящийCyberMaxА из чего получится слабать ERP?оставь надежды.
Это не ответ.

Di_LIneА если выпускники-прогеры кодят так, как ты написал, то... в дворники. ;)
Не всем же бог дал столько красоты ума и проницательности, сколько тебе. Вот и приходится...

Di_LIne,

Я на асме еще на спектруме писал, потом на PC под досом. И что?