| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
FOREIGN KEY Обеспечение целоостности [D5, IB6.x]
Борис © (2002-12-17 11:15:00)Уважаемые господа!
Есть N таблиц.
Одна главная:
CREATE TABLE "T_SKLAD"
(
"PKEY" INTEGER NOT NULL,
"NOMINAL" VARCHAR(250) CHARACTER SET WIN1251,
"TYPE_ELEM" VARCHAR(250) CHARACTER SET WIN1251,
"TYPE_ELEM_SVAZ" INTEGER,
"PRICE" INTEGER,
"POSTAVCHIK" INTEGER,
"PRIMECHANIE" VARCHAR(250) CHARACTER SET WIN1251,
"SROK_POSTAVKI" VARCHAR(250) CHARACTER SET WIN1251,
"OSTATOK" FLOAT,
"DEFICIT_NORM" INTEGER,
"ZAKAZAT" INTEGER,
"ZAKAZANO" INTEGER,
"OPLATIT" INTEGER,
"OPLACHENO" INTEGER,
"P1" INTEGER,
"P2" INTEGER,
"P3" INTEGER,
"P4" INTEGER,
"P5" INTEGER,
PRIMARY KEY ("PKEY")
);
И есть подчиненные таблицы (их много, но они одинаковые)
CREATE TABLE "T_NORM_1"
(
"PKEY" INTEGER NOT NULL,
"SECOND_KEY" INTEGER,
"NORMA" FLOAT,
"NORMA_NA_N" FLOAT,
"P1" FLOAT,
"P2" FLOAT,
"P3" FLOAT,
"P4" FLOAT,
"P5" FLOAT,
PRIMARY KEY ("PKEY")
);
ALTER TABLE "T_NORM_1" ADD FOREIGN KEY ("SECOND_KEY") REFERENCES T_SKLAD ("PKEY");
Задача - Обеспечетиь, чтобы для каждой строки в таблице T_SKLAD была своя строка в таблицах T_NORM_N (1..N) завязанная Первичный ключ T_SKLAD - Вторичный ключ SECOND_KEY T_NORM_N.
Prooksius (2002-12-30 14:07:00) [1]> les © (30.12.02 13:49)
Празднуете? %)
les (2002-12-30 13:49:00) [2]Модератор удали моє сообщение а то матом буду виражаться :)
Сергєєв Володимир (2002-12-30 13:49:00) [3]Я вообще зажигаю больше по товар-склад для оптовых фирм. Почитал я тут ваш форум и вот мое мнение (для всех - это чисто мое мнение, я не претендую на истину в последней инстанции).
Во-первых, тебя кажется сразу послали к деревьям. И правильно послали. Вот прикинь следующую ситуацию: у тебя склад с товарами (комплектующими или прочей фигней), из которых собирают продукцию. Но, ведь собранное изделие - тоже в свою очередь может быть составляющим для другого изделия. Пример - общепит. Есть калькуляция на тесто для блинчиков (оладиков), которое в свою очередь входит в калькуляцию блюда "блинчики", которое является составляющей частью комплексного полдника.
Но посмотрим на ситуацию с другой стороны. А представь себе, что клиент покупает готовое изделие, а потом разбирает его на составляющие с целью продажи потом по частям или включения в другие комплекты. Пример - опять общепит. Предприятие покупает ликер в бутылках, "разбирает" его на граммы и включает в состав коктейлей. Как у тебя с этим, а?
Дык энто торговля, у в условиях производства(я говорю о заводе) - эта хрень на каждом шагу.
Я сделал так - таблица "ТОВАРЫ", в котрой есть столбец "НОМЕР КОМПЛЕКТА". Если он равен нулю - то этот товар конечный элемент, то есть разбить его на составляющие уже низя, если нет - то это комплект.
Есть другая таблица - "КОМПЛЕКТЫ", в которой внешний ключ - "номер комплекта", есть столбцы АйДи товара, кол-во, %надбавки на сборку, статическая сумма надбавки на сборку, %угара при сборке(например, в ювелирке. В Украине допустимы %угара при производстве Юв.Изд - 4%). Отношение "ТОВАРЫ:КОМПЛЕКТЫ"="1:М"
Все остальное - на триггерах и рекурсии. Практически 50% проги написано на SQL. Так зато потом ты обращаешься с товаром потом как с объектом, можешь его включить в состав другого комплекта, разобрать.
Так что, правильно народ говорит - сходи к деревьям.
Наталия (2002-12-30 12:11:00) [4]Почитай про join в SQL.
Delirium^.Tremens (2002-12-30 11:54:00) [5]Борис © (30.12.02 11:51)
> > кто нехотел читать? Да Вы и непредлагали. Путаите :) RFunc2
Извини, я ошибся, то был Брат :-)
Борис (2002-12-30 11:51:00) [6]кто нехотел читать? Да Вы и непредлагали. Путаите :) RFunc2
а Вот имхо, дошло:
Склад:
PKEY, Naimenovanie, Tip, Ostatok
Нормы:
PKEY, Product, Plata, Znachenie.
Тогда в Product уник. номер продукции, в Plata - уник. номер платы в пределах продукции.
И теперь при выборе платы и продукции делаем select * from
с условием product = номер продукции, плата = номер платы.
Вот мы выбрали один ко многим.
Получаем например:
T_SKLAD.NOminal, T_NORM.Znachenie
так если для значения T_SKLAD есть, а для него нет значения в таблице нормы. как быть? (В Access он автоматом добавляет поле в Нормы, а вот как это сделать в IB).
Delirium^.Tremens (2002-12-30 11:39:00) [7]2 Alexandr © (30.12.02 11:27)
> так-с...
> про деревья читать отказываемся...
Он и про RFunc2 доки читать не хотел, а пришлось ведь (наверно). Не обиделся ли он когда его к деревьям отправили?
Наталия (2002-12-30 11:35:00) [8]Ну тогда
Продукция->Платы 1:М
Платы->Нормы 1:M
Комплектующие->Нормы 1:М
Комплектующие->Склад 1:М
И в чём проблема?
Alexandr (2002-12-30 11:31:00) [9]Удалено модератором
Севостьянов Игорь (2002-12-30 11:30:00) [10]Удалено модератором
Alexandr (2002-12-30 11:27:00) [11]так-с...
про деревья читать отказываемся...
Борис (2002-12-30 11:23:00) [12]Наталия
На складе лежат не готовые комплекты, а комплектующие!
Вот значения этих самых комплектующих мы и изменяем. На складе имеются значения наличия компл. на складе.
В нормах - сколько каждого комплектующего (из основной таблицы) необходимо для производства одной платы. ТЬак вот этих плат неопределенное количество. Акаждая плата относится к какой-либо продукции.
ИМХО, неизбежно для каждой продукции создавать таблицу норм. А для каждого плана таблицу "План" с незавершенкой.
Наталия (2002-12-30 11:16:00) [13]Склад->Продукция связь 1:М
Продукция->Платы 1:М
Платы->Нормы 1:M
Вот вроде бы и всё в основных чертах, не нужно создавать дополнительные таблицы. Или я чего-то не понимаю?
Борис (2002-12-30 11:07:00) [14]Наталия
Не создавать таблицы не получится.
Однако я постараюсь свести к минимуму.
Наталия (2002-12-30 11:01:00) [15]Ты попытайся создать такую структуру БД, чтобы во время эксплуатации программы не приходилось создавать таблицы, а они были бы уже все созданы и их необходимо было бы только заполнять данными. Почитай книги по проектированию БД. У тебя, ИМХО, полная каша.
Борис (2002-12-30 10:51:00) [16]Sergey13
Создавать для каждого плана одну таблицу со списком выданных комплектующих и одну таблицу с нормами? Однако это значительно упростит работу.
Для каждой продукции список плат. На каждую продукцию делаем таблицу по нормам и планам. Будет значительно лучше. и таблиц станет меньше!
Sergey13 (2002-12-30 10:43:00) [17]2Борис © (30.12.02 10:19)
>У одной продукции на платы одни нормы. А вот эту продуцию могут запускать в производство сколько угодно раз.
И что? На каждый запуск новую таблицу? ИМХО, ты изобретаешь велосипед, но 1/2 колесный.
>to All. Вопрос стоит ен в обсуждении структуры базы данных
А жаль. ИМХО, тут то у тебя проблема как раз и есть.
>Как это можно организовать?
Наверное только через динамический SQL.
Но лучше брось эту затею. Попробуй еще подумать над структурой базы. Иначе этот твой вопрос тебе покажется детским лепетом через пол года, когда ты запустишь (может быть) свою прогу в эксплуатацию. Вот тогда перед тобой встанут действительно большие вопросы. 8-(
Alexandr (2002-12-30 10:27:00) [18]а не почитать тебе про "деревья в SQL"
хотябы на www.ibase.ru
Борис (2002-12-30 10:19:00) [19]Sergey
У одной продукции на платы одни нормы. А вот эту продуцию могут запускать в производство сколько угодно раз.
Delirium^.Tremens
А как реализовано в 1С?
Anatoly Podgoretsky
Вы обсолютно правы! И мной вынесено из той ветки (это было более года назад, тогда еще база была на Paradox-е, а сейчас необходимо реализовать на IB), что необходимо организовать именно в таком виде. Буду благодарен за советы по данному вопросу.
to All. Вопрос стоит ен в обсуждении структуры базы данных, а в конкретном вопросы:
Имеется таблицы со списком названий предположим Таблиц норм.
Необходимо в тригере пройтись по этой таблице и вставить в каждую таблицу нормы новую строчку (с определенными значениями). Как это можно организовать?
Delirium^.Tremens (2002-12-30 09:55:00) [20]2 Anatoly Podgoretsky © (30.12.02 09:53)
> Он уже этот вопрос задавал много месяцев назад, один к одному,
> тогда было дано много нормальных ответов.
:-) Сегодня, не то настроение, мастер.
| |
Страницы: 