Можно ли переименовывать таблицы?

← →
kaif (2003-06-03 17:30) [0]

Как правило в IB таблицы (как впрочем и процедуры) не переименовываются. Представим себе, что существует таблица, куча хранимых процедур, которые ее используют, куча всяких foreign key на нее и так далее.
Возможно ли, аккуратно соединившись с базой данных, и, изменив что-то в системных таблицах, добиться переименования какой-то таблицы. И при этом чтобы все остальное продолжало работать. Допустим, тексты хранимых процедур я потом исправлю командой ALTER PROCEDURE.
Кто-нибудь пытался такое проделать?
Или ну его на фиг?..

← →
DrPass (2003-06-03 17:59) [1]

Главный вопрос: а зачем фигней заниматься - создай новую и перенеси в нее данные (всего два оператора!).

← →
kravchuk (2003-06-03 18:12) [2]

Или Extract Metadata а там Find And Replace, или закоментить все процедуры и триггеры, переименовать таблицу и снова Find And Replace :) без IBExpert никуда

← →
Sandman25 (2003-06-03 18:47) [3]

В чем может быть смысл переименования?
Если к таблице должны обращаться по другому имени (например, чужая программа, на которую нет исходников), то можно сделать синоним.
А если переименование Только ради красоты, то "ну его на фиг?.." :)

← →
kaif (2003-06-04 00:12) [4]

Видимо, действительно, ну его на фиг.
Хотелось именно ради красоты.
У меня система конфигурируемая. В ней в процессе конфигурирования учетной системы можно создавать таблицы и удалять или изменять поля этих таблиц. И иногда бывают выбраны неудачные названия, которые потом хочется изменить прямо в базе.
Если никто этим не занимался, то я откажусь от этой затеи (добавления функции "перименовать таблицу").

← →
Alexandr (2003-06-04 06:29) [5]

давай так.
Переименования таблиц нет не было и не будет потому что это
1) Нафиг никому ненадо
2) Серверу фиолетово как таблицы называются (хоть красиво, хоть некрасиво, хоть с ошибками, хоть в транслите)
3) Если юзеру некрасиво - создай таблицу алиасов названий таблиц, и пусть каждый юзер по-своему таблицы именует...
тут может дойти до того, что таблицы просто нумероваться будет по-порядку(или не по-порядку), как и процедуры, триггеры и прочее...

← →
AlexSerp (2003-06-04 08:51) [6]

Базу надо проектировать.
А не шить на бегу и перешивать.

← →
stone (2003-06-04 09:42) [7]

> Если юзеру некрасиво - создай таблицу алиасов названий таблиц,
> и пусть каждый юзер по-своему таблицы именует...
> тут может дойти до того, что таблицы просто нумероваться
> будет по-порядку(или не по-порядку), как и процедуры, триггеры
> и прочее...

Такой подход используется в 1С. Юзерские таблицы именуются типа (sc146, sc147 ...), а для юзеров это "Справочник такой-то", ...

← →
kaif (2003-06-04 13:49) [8]

2 Alexandr © (04.06.03 06:29)
Таблица алиасов не поможет, потому что красивые имена нужны для использования в SQL-запросах, а IB не имеет механизма встроенных алиасов для таблиц. А я конфигурирующему бухгалтерскую систему предоставляю прямой доступ ко всем таблицам системы и конфигурации при помощи SQL. в этом одна из фишек моей системы в в отличие от той же 1С - прозрачность базы и осмысленные имена таблиц.

>AlexSerp © (04.06.03 08:51)
>Базу надо проектировать.
>А не шить на бегу и перешивать.

Так не бывает. Разработка учетных задач всегда требует переделок базы. Например, вначале имелся справочник BATHROBE (банные халаты), в нем уже есть данные, ссылочная целостность на документы, затем выясняется, что хорошо бы халаты выделить в отдельный класс, а то, что было в BATHROBE обозвать "Домашней одеждой". У меня сложная система справочников с наследованием атрибутов классов. В конце концов возникает отдельный класс махровых изделий (полотенец и банных халатов), скажем TOWEL, а таблицу BATHROBE уже хочется переименовать в HOME_CLOSES, но невозможно из-за кучи ссылочной целостности.
Если бы не уже введенные данные, я бы просто уничтожил все классы и создал заново (в моей системе это можно сделать за пол-часа). Однако девочки уже набили 5000 товаров разных классов и кучу документов.

← →
AlexSerp (2003-06-04 13:58) [9]

А надо было просто создать НОМЕНКЛАТУРНЫЙ справочник, в котором предусмотреть тип товара.
И вот у тебя будет НОМЕНКЛАТУРНЫЙ справочник и к нему справочник типов товаров. И ВСЕ.
А справочник типов товаров спокойно можно представить деревом.
Т.е. там и подтипы могут быть.
Добавляй хоть тыщу типов товаров.
Я не прав?

У меня сложная система справочников с наследованием атрибутов классов.
Ты сам себе заморочки сделал.

Похоже у тебя нет опыта прикладного программирования.
Перенос опыта ООП на базы данных не всегда хорош.

← →
Danilka (2003-06-04 14:01) [10]

Alexandr © (04.06.03 06:29)
Ну-ну. А в орокле пашет без проблем. Специально есть оператор "rename ... to ..." наверное сдуру завели идиоты какие-то.
Можно переименовать таблицу, вьюху, синонима.

← →
Danilka (2003-06-04 14:10) [11]

kaif © (04.06.03 13:49)
может, попробовать так:
1. взять ddl таблицы со всеми индексами, триггерами
2. грохнуть эти индексы и триггеры
3. переименовать в ddl название таблицы на новое, и запустить его
4. скопировать данные из старой таблицы в новую и прибить ее

думаю, на все уйдет не больше получаса.

← →
kaif (2003-06-04 14:18) [12]

2 AlexSerp © (04.06.03 13:58)
Когда ты увидишь, как это сделано, ты, возможно, изменишь свое мнение. У меня весь опыт из прикладного программирования и состоит. Не знаешь - не говори.
Я 10 лет только и разрабатывал, что системы справочников, пока не придумал эту фишку. Фишка удивительная на самом деле. Можно соединить наследование атрибутов и полностью нормализованную реляционную структуру. Но это изобретение. Описывать здесь долго. Скоро опубликую - узнаешь. В этой структуре у меня больше нет никаких проблем со справочниками.
А слово НОМЕНКЛАТУРНЫЙ это просто слово. Вот когда тебе понадобится, чтобы у каждого класса свои поля были (например, у винчестеров отдельное поле - объем, а у банных халатов 2 поля - размер и дизайн) и по любому полю по любому типу документов можно было бы легко SQL запросы делать с группировками, тогда увидишь как твой подход работает. Да еще чтобы ссылочная целостность документов на всю эту лабуду поддерживалась принятым в IB манером.

← →
kaif (2003-06-04 14:21) [13]

2 Danilka © (04.06.03 14:10)
Это тривиальное решение и наиболее верное. Еще надо будет сотню раз дисконнектится (ключи не любят, чтобы их удаляли, если они только что использовались).
Просто я искал какой-нибудь обходной путь...

← →
AlexSerp (2003-06-04 14:22) [14]

У меня тоже свои подходы есть.
Твой мне показался перемудреным.
Все ДОЛЖНО быть проще.
И я могу сделать проще.
Так что пардон.

← →
AlexSerp (2003-06-04 14:23) [15]

Забыл. А твой подход привел к гемору, с которым ты и обратился сюда.
Извини, но такой уж я.

← →
Sandman25 (2003-06-04 14:25) [16]

Попробуйте заменить TDBText на TDBEdit. Будет та же ситуация?

← →
Sandman25 (2003-06-04 14:26) [17]

Извиняюсь, перепутал thread.

← →
AlexSerp (2003-06-04 14:26) [18]

И еще.
Так не бывает. Разработка учетных задач всегда требует переделок базы.
Еще как бывает.

← →
Sandman25 (2003-06-04 14:42) [19]

AlexSerp © (04.06.03 14:26)

Если база спроектирована грамотно, она только расширяется путем добавления полей и таблиц. Например, у нас есть таблица справочников (товаров, единиц измерений и еще кучи всего), где каждый справочник хранит инфо в виде дерева. Дополнительно есть таблицы для особых справочников - например, для товаров хранятся ставка НДС, наименование на госязыке и т.д. Неважно, что придет в голову заказчику, ничего не придется удалять.

← →
AlexSerp (2003-06-04 14:48) [20]

Sandman25, а я разве с тобой спорю?
Я как раз о том же.

← →
Danilka (2003-06-04 14:51) [21]

Sandman25 © (04.06.03 14:42)
Угу, а скажет, например, заказчик что-то типа: "хочу вести несколько фирм в одной базе, в разных мне геморойно, вот, хочу все в одной, я вам денег за ето дам немеряно" и придется всю-все структуру править. :))
И вообще, случаев, когда приходится переделывать то, что нормально работает как часы - великое множество. Правда виноваты в них заказчики. А в том что с ними соглашаешся - их деньги. :))

← →
Sandman25 (2003-06-04 14:55) [22]

У нас предусмотрена многофилиальная структура, с кучей молов на каждом филиале, с кучей участков у каждого мола, с кучей балансовых групп для каждого товара на каждом участке у каждого мола. Финансовый учет тоже можно делить, а можно и не делить - пользователи сами настраивают, на какие счета будут идти проводки при каких операциях. Так что ничего изменять не придется :)

← →
Sandman25 (2003-06-04 14:56) [23]

AlexSerp © (04.06.03 14:48)

Виноват, ошибся.

← →
Danilka (2003-06-04 14:59) [24]

Sandman25 © (04.06.03 14:55)
Неужели ничего нельзя сделать? :))
Неужели у вас все предусмотренно?

Ну, тогда завтра к вам придут, и скажут: "а мы вот видели у Кайфа проводки многосторонние, как в международке, мы такие-же хотим" (а у вас, наверняка, российские) вот-тут то вы и побегаете. :))

← →
Danilka (2003-06-04 15:02) [25]

это просто пример, я всего лишь хочу сказать, что вчера вы сдали систему, с вами расплатились, а завтра к вам придут и попросят переделать ее, сделать такое, чего не предусмотрено, и вы будете переделывать - лишних денег не бывает. :))

← →
Sandman25 (2003-06-04 15:04) [26]

Извини, и тут не угадал. У нас проводки молдавские :)
Но есть куча настроек каждого типа документа, причем настраивает опять таки сам пользователь.
Если понадобится какая-то настройка, мы просто ее добавим ( у нас есть справочник настроек :)) и при проведении документа (то есть в хранимой проц-ре) будем проверять на эту настройку (и делать международные проводки).

← →
Sandman25 (2003-06-04 15:06) [27]

Danilka © (04.06.03 15:02)

Я понял, что это пример. Но я все же настаиваю, что мы будем не ПЕРЕделывать, а добавлять новые возможности к уже имеющимся.

← →
Danilka (2003-06-04 15:12) [28]

Sandman25 © (04.06.03 15:04)
нет, там проводки совсем другие, структура табицы другая, не как у нас (упрощенно): "счет дебета, счет кредита, сумма", а "счет, сумма, признак:дебет/кредит" и на каждую проводку - несколько записей, необязательно четное кол-во, см:
http://delphimaster.net/view/14-1054567133/

у вас, ведь, наверняка не так? :))
а если делать именно так, то придется переделывать... боже мой, сколько всего! :))

← →
Danilka (2003-06-04 15:15) [29]

просто, все учесть это может только... незнаю даже кто.
и я уверен, не существует такой структуры, к которой можно было-бы предьявить любые требования без изменения самой структуры.

← →
Sandman25 (2003-06-04 15:30) [30]

Хорошо, уговорили.
Пришлось бы на сделать VIEW для международных проводок. по большому счету никто же не видит, как оно на самом деле у нас хранится. Главное - чтобы в режимах просмотра отображалось как надо.

← →
dj next (2003-06-04 16:01) [31]

to kaif,Danilka

вся эта борьба с написанием универсального софта начата не вами
и боюсь не вами закончица. Когда-нибудь появятся базы основанные
на других принципах Но пока если база реляционная то и работать
надо с ней соответственно - проектировать и реализовЫвать структуру и вообще хочется посоветовать вам ознакомится с реляционной теорией там всё круто на самом деле
а ваш простите онанизьм приводит толька к тормозам при больших
объёмах данных и больше ни к чему - проверено

← →
Danilka (2003-06-04 16:09) [32]

dj next (04.06.03 16:01)
Дружище, ты о чем?
По-моему я тут только и делаю, что пытаюсь обьяснить что нет ничего универсального.

А к чему приводит мой "онанизм" интересно откуда ты знаешь, если не видел ни разу ни одной моей модели данных, реальных объемах с которыми приходится работать и ни одной моей строчки кода?
:))

И, думаю, что про реляционные БД я узнал, когда ты еще в пеленки писался, дорогой диджей. :))

← →
dj next (2003-06-04 16:41) [33]

to Danilka

знаю одного чела который делает то же что и вы
классы динамическое наследование и тд и тп
всё тормозит удобства пользования - ноль правда всё работает
и даже деньгу приносит
он убил на это 10 лет и по-моему зря
этакий второй 1С короче

← →
Danilka (2003-06-04 16:44) [34]

dj next (04.06.03 16:41)
Дык, а где я упоминал слова "классы" "динамическое наследование" и т.д.?
Или Kaif, по-моему он тоже их не упоминал.
:))

← →
dj next (2003-06-04 16:45) [35]

а вообще фишка в том чтобы предвидеть возможные изменения
настроения клиента и закладывать это в структуру но для этого
требуется определённое погружение в сам предмет и его изучение
скажем непросто заколбасить поле "Приход" а вникнуть в бухгалтерию и заколбасить мастер-таблицу "Код прихода"
неважно нужна ли она щас - она понадобится!

you wrote:
И, думаю, что про реляционные БД я узнал, когда ты еще в пеленки писался, дорогой диджей. :))

сомневаюсь что ты помнишь что такое КАРАТ-М ))

← →
Danilka (2003-06-04 16:48) [36]

dj next (04.06.03 16:41)
просто интересно, в двух ветках сегодня и вчера пытался доказать, что нет универсальности, одна специфика, и на тебе - обвиняют в универсальности и т.д. :))

Универсальный инструмент? Быть может - тот-же дельфи. Можно с его помощью сделать еще более эффективный инструмент для создания БД, интерфейса к БД. Но сами базы - сплошная специфика.

← →
Danilka (2003-06-04 16:54) [37]

dj next (04.06.03 16:45)
>фишка в том чтобы предвидеть возможные изменения
>настроения клиента

Это уже из области парапсихологии. :))
Вообще можно, на основе личного опыта обсудить какую-то часть модели данных с заказчиком и сделать ее более "правильной", чем то что он требует, но абсолютно все учесть невозможно. В этом и беда, об этом я постов ..дцать говорю только в этой ветке.

← →
dj next (2003-06-04 17:04) [38]

to Danilka
ну дык вот и я грю про тоже а kaif натоптал какую-то
УНИВЕРСАЛЬНУЮ комбинацию база-интерфейс и хочит с его помощью решить любую
задачку короче не работать а стричь купоны идея хороша но
реализация вылазит за возможности сегодняшних баз данных
как следствие - приходится извращаться переименование таблиц
создание объектов "на лету" как следствие - неиграбельность
хотя для циников - сойдёт не он ведь будет со своей прогой работать
я вот про чо а ты про чо? :)

← →
dj next (2003-06-04 17:08) [39]

to Danilka
>но абсолютно все учесть невозможно
да можно! нужно в предмет въехать как следует! клиент ведь не
монстр какой если он торгует холодильниками он не будет
просить тебя сделать поле "Время полураспада")))

← →
dj next (2003-06-04 17:11) [40]

>что вчера вы сдали систему, с вами расплатились, а завтра к вам >придут и попросят переделать ее, сделать такое, чего не >предусмотрено, и вы будете переделывать - лишних денег не >бывает. :))

вот это верно!))))

Можно ли переименовывать таблицы? Найти похожие ветки