Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2003.06.26;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]

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

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




Страницы: 1 2 вся ветка

Форум: "Потрепаться";
Текущий архив: 2003.06.26;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.6 MB
Время: 0.029 c
14-84609
race1
2003-06-09 13:11
2003.06.26
m->wm


1-84137
namor
2003-06-09 15:56
2003.06.26
Прорисовка изображений в TDBlookUpComboBox


8-84466
Intell
2003-03-07 17:57
2003.06.26
Как сграбить картинку с видеоисточника?


8-84447
Sder
2003-03-09 11:23
2003.06.26
Вы случайно не знаете как в delphi получить avi из последовательн


1-84384
Aiax
2003-06-09 12:45
2003.06.26
Генерация случайных чисел без повторов





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский