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

← →
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) как только его создали.
Однако в Вашем случае процессом управляет юзер, а в моем - конфигурирующий, так как это вставка поля в таблицу, а не добавление данных. И в общем это разные решения, конечно. И мой подход более жесткий.

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