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

← →
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]

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

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

← →
kaif (2003-06-04 19:41) [41]

Сколько ругани!
Ладно, задолбали.
Привожу свою систему справочников. И пусть кто-то скажет, что она не реляционная.

Создаем класс "Товары"
CREATE TABLE GOODS(
ID INTEGER NOT NULL,
ARTICLE VARCHAR(20) NOT NULL,
CONSTRAINT PK_GOODS PRIMARY KEY(ID)
);

Создаем класс "Марки производителей"
CREATE TABLE TRADEMARK(
ID INTEGER NOT NULL,
NAME VARCHAR(50) NOT NULL,
CONSTRAINT PK_TRADEMARK PRIMARY KEY(ID));

Создаем класс "Винчестеры" (потомок класса "Товары")
CREATE TABLE HDD(
ID INTEGER NOT NULL,
TRADEMARK INTEGER NOT NULL,
HDD_VALUE INTEGER,
HDD_SPEED INTEGER,
... и другие поля
CONSTRAINT PK_HDD PRIMARY KEY(ID));

Автоматически создается еще ссылочная целостность:
ALTER TABLE HDD ADD CONSTRAINT FK_HDD1
FOREIGN KEY (ID) REFERENCES GOODS(ID) ON DELETE CASCADE;
ALTER TABLE HDD ADD CONSTRAINT FK_HDD2
FOREIGN KEY (TRADEMARK) REFERENCES TRADEMARK(ID);

Создаем класс "Всяко-разно" (Тоже потомок класса "Товары")
CREATE TABLE SOMESHIT(
ID INTEGER NOT NULL,
SHIT_NAME VARCHAR(100),
CONSTRAINT PK_SOMESHIT PRIMARY KEY(ID));

Автоматически создается еще ссылочная целостность:
ALTER TABLE SOMESHIT ADD CONSTRAINT FK_SOMESHIT1
FOREIGN KEY (ID) REFERENCES GOODS(ID) ON DELETE CASCADE;

Добавление записи в класс "Винчестеры" делается двумя SQL-командами (обеспечивает компонент на клиенте)
INSERT INTO GOODS(ID,ARTICLE) VALUES (...)
INSERT INTO HDD(ID,TRADEMARK,HDD_VALUE,HDD_SPEED) VALUES (...)

Добавление записи в класс "Всяко-разно" делается двумя SQL-командами (обеспечивает компонент на клиенте)
INSERT INTO GOODS(ID,ARTICLE) VALUES (...)
INSERT INTO SOMESHIT(ID,SOMESHIT_NAME) VALUES (...)

Для редактирования тоже нужно столько SQL-команд, какова вложенность класса.

Для удаления достаточно удалить запись из базового класса.

Таким образом, мы имеем класс "Винчестеры", который наследует атрибут "Артикул" от класса "Товары", но имеет ряд дополнительных атрибутов, которые не имеет класс "Всяко-разно", который, в отличие отт класса "винчестеры" имеет атрибут "Наименование". Классы "Торговые марки" и "товары" в данном случае - базовые.
Фишка в том, что атрибуты объекта хранятся сразу внескольких таблицах. Атрибуты, унаследованные от предка - в таблице предка, собственные атрибуты в таблице данного класса.
Теперь мы делаем уникальный индекс на поле "Артикул"

ALTER TABLE GOODS ADD CONSTRAINT UK_GOODS1 UNIQUE (ARTICLE);

И мы получаем 2 разных класса, у которых общая уникальность на артикул.
Теперь делаем таблицу документа "Накладная", в которой заводим поле GOODS и делаем ссылочную целостность на таблицу, поле ID: ALTER TABLE FACTURE ADD CONSTRAINT FK_FACTURE1
FOREIGN KEY (GOODS) REFERENCES GOODS(ID);

Теперь и винчестеры и всяко-разно могут попасть в накладную.

Сборка класса винчестеры:
SELECT
GOODS.ID,
GOODS.ARTICLE,
GOODS.TRADEMARK,
HDD.TRADEMARK,
TRADEMARK.NAME, //как бы lookup-поле
HDD.HDD_VALUE,
HDD.HDD_SPEED
FROM
GOODS, HDD, TRADEMARK
WHERE
GOODS.ID = HDD.ID AND GOODS.TRADEMARK = TRADEMARK.ID

Текст этого запроса компонент справочника генерит автоматически.

Теперь запрос по накладным с группировкой по маркам проданных винчестеров:

SELECT
SUM(FACTURE.AMOUNT),
HDD.TRADEMARK,
TRADEMARK.NAME
FROM
FACTURE, HDD, TRADEMARK
WHERE
FACTURE.GOODS = HDD.ID AND HDD.TRADEMARK = TRADEMARK.ID
GROUP BY
HDD.TRADEMARK, TRADEMARK.NAME

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

ПУСТЬ КТО-НИБУДЬ МНЕ СКАЖЕТ, ЧТО Я НАРУШИЛ ХОТЬ ОДИН РЕЛЯЦИОННЫЙ ПРИНЦИП! "Не нарушить закон пришел я, но исполнить закон..." (И.Х. Евангелие от Иоанна) :))

Наоборот. Впервые данные хранятся в абсолютно нормализованном виде, причем номализация получается сама-собой. В той конфигурации, что сейчас крутится у заказчика более 100 таблиц и 140 хранимых процедур. Из них таблиц 45 - только справочники. Всю систему классов я могу воспроизвести за пол-часа при помощи моей системы. Но я вынужден мириться с неудачными названиями таблиц классов, если база используется, так как все пронизано ссылочной целостностью.

Создавая классы и их наследников в такой системе я нигде (!) не пришел в противоречие.

Вот часть структуры классов (это все отдельные таблицы):
Базовые классы выделены.

Контрагенты
Заказчики
Фирмы
Собственные Магазины
Частные лица
Производители

Дизайны
Дизайны посуды
Дизайны постельного белья
Дизайны домашней одежды

Виды коллекционных товаров
Виды комплектов постельного белья
Виды наволочек
Виды простыней
Виды пододеяльников
Виды домашнего белья
Виды посуды
Виды скатертей
...

Товары
Постельное белье
Комплекты
Наволочки
Пододеяльники
Простыни
Посуда
Аксессуары
Упаковка
Домашняя одежда
Устаревшие
Упаковка

и.т.д.

← →
kaif (2003-06-04 20:03) [42]

2 dj next (04.06.03 16:01)
>... и вообще хочется посоветовать вам ознакомится с реляционной >теорией там всё круто на самом деле
>а ваш простите онанизьм приводит толька к тормозам при больших
>объёмах данных и больше ни к чему - проверено

Просьба не считать других идиотами.
Я привел Вам мою структуру, если Вы находите, что это "онанизьм", то сообщу Вам, уважаемый, что у меня полный двусторонний бухгалтерский баланс всей компании с 30тыс проводок помощью SQL-запроса собирается за 0.08 сек, что соответствует не хуже 370тыс. проводок/сек. Это на IB и сервере 2ГГц.

Вся моя работа последних лет посвящена тому, чтобы добиться самых высоких скоростей и тем не менее создать строго реляционный и гибкий бухгалтерский движок, альтернативу 1С. А если у кого мозги не варят и он не знает иного способа организовать классы с наследованием, кроме как в BLOB их код запихивать, то пусть примет мои соболезнования.

← →
uw (2003-06-04 20:42) [43]

>kaif © (03.06.03 17:30)

Вообще-то, CASE-средство типа ERwin делает то, что сформулировано в первом посте, легко. Если база данных была сгенерирована "руками", то и теперь с помощью ERwin можно сделать Reverse Engineer, а потом что-то меняить в структуре базы данных, не трогая данных.

← →
kaif (2003-06-05 00:14) [44]

2 uw © (04.06.03 20:42)
Хорошая идея. Правда я с ERwin почти не работал. А что при Reverse Engineering ERWin может как-то и данные вытянуть? Я почему-то думал, что эта технология только со структурами метаданных работает. Потом ERWin - по моему, дорогая технология. Я не могу ее рекомендовать разработчикам только ради одной такой ситуации в дополнение к своей оболочке.

← →
uw (2003-06-05 00:57) [45]

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

← →
Alexandr (2003-06-05 06:50) [46]

2kaif

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

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

← →
Alexandr (2003-06-05 06:58) [47]

да... и почитал я еще весь бред...
Херню всякую предлагают.
kaif прав и идет в правильном направлении.

а предложенный
"rename ... to ..." из оракла правильно исправит все ссылки на таблицу? (триггеры, имена индексов и прочее)? Мож он и клиентское приложение сразу подправит, а?

← →
Anatoly Podgoretsky (2003-06-05 07:20) [48]

Ну если бабок срубить, то конечно надо переделывать и много, много раз. А если по уму то погружение и проработка.

← →
Danilka (2003-06-05 07:38) [49]

kaif © (04.06.03 19:41)
Кстати, в том-же ERWin-е есть понятие класса, все это там легко реализовывается на модели данных.
У нас в системе организовано то-же самое, например, есть класс "документ", откуда есть связанные с ним остальные документы: договора, счет-фактуры и т.д., причем часть документов, (счет-фактуры, платежные документы, кассовые и т.д.) вынесены в отдельный подкласс - бух.докумет, то есть документы имеющие проводки.

Alexandr © (05.06.03 06:58)
>"rename ... to ..." из оракла правильно исправит все ссылки
>на таблицу? (триггеры, имена индексов и прочее)? Мож он и
>клиентское приложение сразу подправит, а?
Да, все ссылки он правильно исправит, для того и существует, вопрос из области, а "select ... from ... правильно сработает?", но вот имена индексов и триггеров он трогать не будет.

← →
Danilka (2003-06-05 07:42) [50]

kaif © (05.06.03 00:14)
>Потом ERWin - по моему, дорогая технология.
В IBExpeert -е есть что-то подобное, в Tools-ах лежит какой-то "Database designer", на сколько я понимяю, для русскоязычных IBExpert бесплатен.
Правда я с этим дизайнером еще не работал, не знаю насколько он удобен, ERWin очень удобен.

← →
kaif (2003-06-05 16:49) [51]

Дело в общем не в том, ERWin или IBExpert умеют такое делать или нет (переименование таблиц). В любом случае они не могут сделать ничего за пределами того, что позволяет gds32.dll. И все, что они делают - создание новой таблицы, копирование удаление старых и создание новых FOREIGN KEY, замена вхождений в текстах хранимых прроцедур (уже сложнее) - я это все тоже могу реализовать без всяких ERWin.
Но я, собственно, чего вопрос-то задаю...
Часто на форуме по базам данных я замечаю сообщения о том, что народ правит системные таблицы IB. Так вот я и спрашиваю. Пытался ли кто-то решать ИМЕННО задачу переименования таблицы ТАКИМ СПОСОБОМ и конкретно на IB?
Если нет - то пардон. Я либо пойду длинным путем, либо вообще откажусь от этой затеи.

2 Anatoly Podgoretsky © (05.06.03 07:20)
>Ну если бабок срубить, то конечно надо переделывать и много, >много раз. А если по уму то погружение и проработка.

К сожалению, я уже в другой ветке про это говорил. Менеджеры редко сотрудничают с программистом на стадии разработки конфигурации. Однако они начинают очень активно сотрудничать на стадии внедрения. Это организационная специфика написания сетевых клиент-серверных учетных систем на заказ и как я не пытался преодолеть эту ситуацию, мне этого не удалось ни с одним заказчиком...

← →
kaif (2003-06-05 17:11) [52]

2 Alexandr © (05.06.03 06:50)
>я остальное потом почитаю, но вот эта проблема решается простым >препроцессором запросов - пусть он слова подменяет перед >выполнением запроса.

Идея препроцессора очень правильная. Но я не хочу этого делать. Я хочу, чтобы к моей базе мог обратиться из внешнего мира любой программист и иметь дело с теми же именами таблиц, с какими он имеет дело из-под моей системы. Именно это я и называю прозрачностью базы. Ясность ее построения и возможность обратиться туда с помощью SQL из внешнего мира. Например, из PHP-скрипта прямо влезть в базу, получить баланс и отослать в виде динамического HTML в браузер.

2 Danilka © (05.06.03 07:42)
Не знаю, что в ERWin называт классом.
Я лишь знаю, что существует инерция мышления, говорящая всем, что каждый товар, к примеру это одна строка в некой таблице.
То есть, что объекты реального мира суть экземпляры своих сущностей.
Я пришел к выводу, что это не так. Каждый объект реального мира это некоторая суперпозиция сущностей. И поэтому для него нужно несколько раз сделать INSERT в разные таблицы.

Например, если мы определили "Халат", как класс, потомок класса "Одежда", который, в свою очередь является потомком класса "Товар", то для того, чтобы корректно описать халаты нам нужно для каждого халата вставить 3 записи:
1. В таблицу "Товар" вставить запись (ID, "Артикул").
2. В таблицу "Одежда" вставить запись (ID,"Муж/жен", "Размер").
3. В таблицу "Халаты" вставить запись (ID, "Дизайн")

Итого, нам нужно 3 INSERT-а для добавления одного халата.
Поле ID для всех 3 записей должно иметь одно значение, чтобы потом возможно было собрать справочник халатов.

Это и есть 5 нормальная форма, ИМХО.

← →
Anatoly Podgoretsky (2003-06-05 17:23) [53]

kaif © (05.06.03 16:49)
Одно другому не противоречить, лучше рубить бабки по уму :-)
А ситуацию с разработкой знаю, но говорит она о другом, скажем так о нехватке ресурсов для нормальной разработке, при том любых ресурсов, включая в первую очередь людские.

← →
Sandman25 (2003-06-05 17:26) [54]

kaif © (05.06.03 17:11)

Я не понимаю смысла "некоторая суперпозиция сущностей", но с моей точки зрения халат - это запись в таблице tovar (type, id, name, attributes), которая имеет foreign key на таблицу справочников spravochnik(type, id, id_ref, level), причем type для всех товаров имеет одно и то же значение.
Если о халате известно что-то дополнительно, причем это что-то используется только для просмотра, то это что-то можно записать в attributes. Если же нужно добавить что-то, что будет использоваться в расчетах (например, ставка НДС или размер), то нужно либо расширить первую таблицу (добавив поле stavka_nds) либо добавить новую таблицу razmer(type, id, razmer).
И тем не менее халат все равно остается "одна строка в некой таблице"

← →
Danilka (2003-06-05 17:36) [55]

kaif © (05.06.03 17:11)
Я это понял, это отличная идея. У нас это тоже применяется, еще до того как я пришел в эту фирму.
Для того, чтобы корректно втавить, например, счет-фактуру мы делаем insert в три таблицы:
1. "Документ" (ID, Номер, Дата, ...)
2. "Бух. документ" (ID, Сумма, ...)
3. "Счет - фактуа" (ID, Банк.счет, ...)

:))

Теперь, на счет имени. Проверил у себя в тестовой базе:

update RDB$RELATIONS
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

update RDB$RELATION_FIELDS
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

update RDB$RELATION_CONSTRAINTS
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

update RDB$INDICES
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

update RDB$TRIGGERS
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

update RDB$USER_PRIVILEGES
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

update RDB$VIEW_RELATIONS
set RDB$RELATION_NAME="PROBA_PERA"
where RDB$RELATION_NAME="EI$DATASET";

Поругалась 3 раза, на апдейт:
RDB$RELATION_CONSTRAINTS, RDB$INDICES и RDB$USER_PRIVILEGES.

После чего, на всякий случай, вырубил сервер и снова врубил.
Теперь, все данные что были в таблице EI$DATASET у меня в PROBA_PERA, запросы, вроде проходят нормально, и селект и инсерт и апдейт.
Exstract DDL показывает, что у таблицы больше нет индексов, раньше были.
Боюсь, накрылся системный индекс по ключевому полю. Но это не беда.

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

← →
Danilka (2003-06-05 17:49) [56]

да, сервер Firebird 1.5

← →
Danilka (2003-06-05 18:00) [57]

Sandman25 © (05.06.03 17:26)
Это все обсуждается, есть разные подходы, например, статья Анатолия Тенцера "БД – хранилище объектов" интересная в этом плане, но сейчас мне уже надо бежать домой... :))

← →
kaif (2003-06-05 18:50) [58]

2 Danilka © (05.06.03 17:36)
>Я это понял, это отличная идея. У нас это тоже применяется, еще >до того как я пришел в эту фирму.
>Для того, чтобы корректно втавить, например, счет-фактуру мы >делаем insert в три таблицы:
>1. "Документ" (ID, Номер, Дата, ...)
>2. "Бух. документ" (ID, Сумма, ...)
>3. "Счет - фактуа" (ID, Банк.счет, ...)

Совершенно верно! Я рад, что до этого додумался не я первый.
Это единственно верный способ хранения информации. Просто никто еще не пытался это делать со справочниками.

А знаете почему?
Потому что неясно, как потом печатать накладную, в которой должны вместе оказаться халаты со своими размерами и. к примеру, ароматические свечи, которые обладают совершенно иной атрибутикой.
Именно эту проблему мне удалось решить при помощи так называемой подсистемы форматирования имен, в которой имена собираются для каждого класса по тому правилу, которое придумает конфигурирующий и хранятся в единой таблице OBJECT_NAMES.
Причем способы сборки наименований могут быть разными для одного и того же класса, например, сборка русского наименования и сборка иностранного наименования для заказа товара за границей.
Подсистема форматирования наименований организована в виде взаимосвязанных ХП на сервере, текст которых создается автоматически в процессе настройки справочной системы.
Срабатывают эти процедуры в момент добавления/редактирования объектов в справочниках. Поэтому это не занимает много времени. Если нужно собрать накладную для печати достаточно простого SELECT * FROM FACTURE, OBJECT_NAMES
WHERE FACTURE.GOODS = OBJECT_NAMES.OBJECT_ID

Каждый объект справочной системы в таблице OBJECT_NAMES представлен 1 строкой.

2 Sandman25 © (05.06.03 17:26)

>Я не понимаю смысла "некоторая суперпозиция сущностей", но с >моей точки зрения халат - это запись в таблице tovar (type, id, >name, attributes), которая имеет foreign key на таблицу >справочников spravochnik(type, id, id_ref, level), причем type >для всех товаров имеет одно и то же значение.
>Если о халате известно что-то дополнительно, причем это что-то >используется только для просмотра, то это что-то можно записать >в attributes.

У всякой задачи есть сразу всем очевидное и совершенно неправильное решение.

Что такое attruibutes, которое используется только для просмотра?

А если надо не "только для просмотра"?
А если как раз эти вещи (анализ продаваемости халатов с группировкой по "размерам" и продаваемости наволочек с группировкой по "дизайнам") и интересен в первую очередь?

Неужели Вам не приходилось искать обувь с размером 43, которой нигде нет, а есть только с размером 42?
И только потому что торговые фирмы просто не владеют ситуацией и не в состоянии анализировать ассортимент?

Вот многие товарищи преклоняются перед иерархическими справочниками 1С и пытаются воспроизводить такие даже в дельфийских программах.
Пусть подумают, что завтра придет заказчик и скажет:
хочу увидеть наличие того-то складе в таком-то разрезе.
А у него дерево с 10 уровнями вложенности девицы нагородили и чего там только нет. Я уже не говорю о том, на каких языках все это набивалось (первые две буквы в слове "водка" могут вполне где-то оказаться английскими) и на каких уровнях иерархии фигурировало. И будет полный ступор с таким отчетом. Или полная лажа. Или сегодня заработает, а завтра тот же отчет покажет ерунду.

Так что разные товары должны храниться в разных таблицах. Но ссылочная целостность должна быть организована таким способом, чтобы при попытке удалить любой товар, фигурирующий в документах, IB не дал этого сделать. И так, чтобы уникальность того же артикула поддерживалась в рамках всех товаров.
И получается, что иного решения, кроме того, что я привел, просто нет:

Вот ссылочная целостность:
"Накладные" -> "Товары"
"Одежда"->"Товары"
"Халаты"->"Одежда"
"Носки" ->"Одежда"
"Свечи ароматические"->"Товары"

Для удаления конкретного халата нужно удалить его запись в таблице "Товары". Если в накладной есть ссылка на этот халат, то сработает foreign key "Накладные" -> "Товары".
Точно так же есть получается, что невозможно удалить "Носки" или "Свечи ароматические", хотя это все находится в разных таблицах. Главные принципы:
1.Вложенность класса определяет количество INSERT, которые нужно сделать, чтобы вставить экземпляр данного класса в систему.
2.Удаление производится путем удаления из базового класса, далее срабатывает CASCADE DELETE.

В результате мы получаем равноправные поля для группировок при любых SQL-запросах и никогда не имеем дела с деревьями в справочной системе.
Вместо деревьев объектов или типов мы имеем дерево классов, которое понятно, что означает: объекты низших классов хранят свои унаследованные от предков атрибуты в таблицах классов-предков.

← →
Sandman25 (2003-06-05 18:59) [59]

Сейчас я должен уходить, но вот мое краткое возражение на

>Неужели Вам не приходилось искать обувь с размером 43, которой нигде нет, а есть только с размером 42?

У нас предусмотрена система "исполнений". В исполнение включается ссылка на справочники, например, "ткань", "размер", "цвет". Генерируется номер исполнения (автоинкрементное поле), и записываются связи с указанными справочниками. При оприходовании товара можно указать номер исполнения. Таким образом, можно легко определить остатки и обороты как по конкретному исполнению (ткань шелковая, цвет красный, размер 42), так и по его конкретному признаку (размер 42).
Все, надо бежать :)

← →
kaif (2003-06-05 19:12) [60]

2 Sandman25 © (05.06.03 18:59)
То, что Вы говорите, напоминает мне метод начислений. Вы просто применили бухгалтерский метод решения задачи. Бухгалтерски можно решить любую задачу с заранее поставленными условиями и целями.
А правильное хранение данных позволит решить любую задачу, какую вообще возможно решать на этих данных. Например, свести вероятность ввода дубликата товара в справочник товаров к нулю (Слабо?). Имеется в виду дубликата по смыслу, а не по написанию названия. То есть иметь настоящую смысловую классификацию.

Хотя я не считаю, что мое решение следует навязывать всем. Это особая система. И те, кому она придется по вкусу, пусть потом спорят о ее преимуществах по сравнению с другими подходами.

Есть и другие проблемы именований товаров (идущие от налоговой). Вот как их решать, я пока вообще не знаю. Неужели нужны приказы директора:
Постановляю считать "Каща манная" тем же товаром, что и "Манная каша".
...

← →
Sandman25 (2003-06-06 10:14) [61]

kaif © (05.06.03 19:12)

>То, что Вы говорите, напоминает мне метод начислений. Вы просто применили бухгалтерский метод решения задачи. Бухгалтерски можно решить любую задачу с заранее поставленными условиями и целями.

Не совсем понимаю, и думаю, что Вы тоже не совсем меня понимаете. В справочник исполнений пользователь может добавить любое количество признаков (запах, высота, объем и т.д.) и тем не менее все будет работать. Налицо такая же гибкость, как и в Вашей системе, но она достигается не созданием специализированных таблиц типа halat(id_tovara, razmer) для каждого товара, а использованием всего двух дополнительных таблиц ispolnenie(id_isp, opisanie) с одной записью на каждое исполнение и attr_ispoln(id_isp, sprav_type, sprav_id) с переменным числом записей для каждого исполнения, где sprav_type и sprav_id служат foreign key на таблицу справочников.
Кстати, как Вы будете реализовывать запрос клиента, который захочет выяснить наиболее "продаваемые" цвета - например, как он может узнать, что синие халаты, синяя посуда, синие шторы и синие телевизоры продаются лучше всего? Имеется ввиду, что его не интересует продажа в разрезе конкретного вида товара.

>Например, свести вероятность ввода дубликата товара в справочник товаров к нулю (Слабо?). Имеется в виду дубликата по смыслу, а не по написанию названия. То есть иметь настоящую смысловую классификацию.

Если в одной ветви справочника заведены 2 товара, у которых все значения, кроме названия одинаковы, то нужно проверить название товаров. Если там Каша манная и Манная каша, то это дубликаты. Но проблема в том, что можно только выдавать предупреждения пользователю, что существует похожий товар. Однозначно решить проблему невозможно, даже если привлечь ИИ. Особенно у нас в Молдавии, где зачастую перемешаны названия на молдавском, русском и английском языках.

← →
Sandman25 (2003-06-06 10:16) [62]

>(первые две буквы в слове "водка" могут вполне где-то оказаться английскими)

Есть идея проверять ввод и запрещать в пределах одного слова использовать символы из разных языков. Это немного замедлит ввод справочников, но я думаю, оно того стоит. Надо будет начальству предложить идею :)

← →
Danilka (2003-06-06 10:37) [63]

Sandman25 © (06.06.03 10:14)
это очень похоже на ту статью, что я давал раньше, вот ссылка на нее: http://podgoretsky.com/ftp/Docs/Delphi/Tenser/6.zip

Если это то-же самое, то у такого подхода тоже есть свои недостатки, например, вопрос доступа: одному пользователю можно видеть только халаты, и нельзя, например, туфли (на счет товаров - маразм конечно, но по-отношению к документам, есть такое и очень часто). Т.к. и туфли и халаты лежат в одной таблицы, то он может с помощью какого-нибудь IBExpert-а легко получить доступ к этой информации.
Конечно, можно, например, вьюхами решить часть проблемы, но есть здесь и другие проблемы, если капнуть глубже, правда свои недостатки и достоинства есть у любого подхода. :))

← →
Danilka (2003-06-06 10:42) [64]

Sandman25 ©
Кстати, это уже не будет один товар - одна запись, это будет одна запись в таблицу товаров, и куча - в таблицу атрибутов. :)))

← →
Danilka (2003-06-06 10:47) [65]

Sandman25 ©
Вообще, статья Анатоия Тенцера довольно интересная, я ее только недавно почитал какое-то время обдумывал, искал недостатки в этом способе, то что у вас есть опыт работы с таким подходом - значит вам больше известно об ее недостатках. У меня пока небыло времени и возможности попробовать на ком-нибудь применить эти идеи. :))

Еще, очень интересно было-бы услышать мнение Кайфа об этой статье.

← →
Sandman25 (2003-06-06 11:29) [66]

Danilka, спасибо за статью! Сейчас почитаю.
А насчет доступа - у нас есть разные типы документов, причем они с точки зрения налоговой могут быть по сути одними и теми же, и тогда единственный смысл заведения нескольких типов - пользователю дается доступ только на некоторые из них. Причем при этом можно проверять (по настройке, устанавливаемой администратором) еще и чтобы в операции участвовало материально-ответственное лицо, к которому у пользователя есть доступ (либо даже чтобы мол был с того же филиала, что и пользователь).

← →
Zacho (2003-06-06 11:39) [67]

> Sandman25 © (06.06.03 11:29)

Еще можно посмотреть http://www.ibase.ru/devinfo/oop_rdbms.htm
и http://www.stikriz.narod.ru/art/oobd.htm

← →
kaif (2003-06-07 01:29) [68]

2 Danilka © (06.06.03 10:37)
> Еще, очень интересно было-бы услышать мнение Кайфа об этой >статье.

Если избрать тот путь, что изложен в статье, то, пожалуй, автор реализовал все достаточно красиво.
Однако я пробовал итди по этому пути лет 6 назад, когда писал одну из своих первых систем на IB. Собственно, все недостатки такого подхода автор отметил (кошмарные LEFT OUTER JOIN-ы и полное отсутствие декларативной ссылочной целостности). Но я бы к этому добавил еще вот что:
Вертикальное унифицированное хранение "Атрибутов" приводит к примитивизации типов данных, невозможности задействовать не только ссылочную целостность, но и CHECK CONSTRAINTS, невозможность использовать отдельные триггеры для в принципе разных сущностей, одним словом, я вообще не понимаю, зачем тогда нужна СУБД класса IB и все ее кайфы.
После первой же попытки использовать такие подходы я тогда отказался от всего этого НАПРАВЛЕНИЯ, несмотря на всю кажущуюся заманчивость. И много лет придерживался классики, хотя приходилось мириться с тем, что полной нормализации справочников не удавалось добиться. И только изобретя тот способ, что я описал (как всегда, я изобрел велосипед, так как вижу, что ERWin испльзует в точности тот же метод в отношении документов...), мне удалось решить проблему объектно-ориентированных справочников окончательно. Причем не только не приходя в противоречие с принципами реляционных баз, но наоборот, впервые используя всю мощь СУБД (foreign key, triggers, unique indices) по назначению и добиваясь максимальной нормализации данных просто тыкая кнопки "Добавить класс-потомок", "Добавить поле", "Удалить поле" и т.п. И при этом получив универсальный интерфейс ввода данных в справочники и выбора из них, реализованный на уровне ядра учетной системы, избавив конфигурирующего от необходимости писать окна для каждого класса справочника. Вместо этого я предоставляю конфигурирующему несколько компонентов, вызывающих диалог справочника нужного класса, в котором, он щелкнув по любой колонке, может упорядочить по этому полю (автоматический перезапрос с новым ORDER BY), включить фильтр, выбрать или добавить новую "запись" или отобразить "подчиненный" справочник (любой справочник, который содержит поле ссылки на данный).
Сборка справочников происходит автоматически с помощью только INNER JOIN с максимальной скоростью. И никакой избыточности в хранении данных и никакой примитивизации типов данных и никаких LEFT JOIN.

← →
kaif (2003-06-07 01:39) [69]

2 Sandman25 © (06.06.03 10:14)
Ваша техника "исполнений" очень изящна и она мне нравится. К сожалению, в моей системе отсутствует реализация таких вещей. Но я не хотел бы путать эту тему со справочниками и способами хранения данных.
Если все товары имеют атрибут "Цвет", то ничего не стоит вставить такое поле в базовый класс "Товары" (ссылку на новый справочник "Цвет"). В моей справочной системе все товары тут же заимеют это поле, так как это поле предка. Причем это поле сразу проинициализируется пустым значением ID=0 справочника "Цвет". Любой справочник имеет такой неуничтожимый пустой элемент (ID=0) как только его создали.
Однако в Вашем случае процессом управляет юзер, а в моем - конфигурирующий, так как это вставка поля в таблицу, а не добавление данных. И в общем это разные решения, конечно. И мой подход более жесткий.

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