Помогите правльно организовать таблицы

← →
elena_pp (2006-06-02 12:22) [0]

Пишу программу годовая заявка:
Есть таблица заказов KOD,..., M1,M2...M12, где M1-M12 количество заказанного.
Нужна таблица цен на каждый месяц (CENA):
Организовала так KOD, CENA, DAT.
Только цена поставленная в 1-м месяце действует, пока не появиться новая цена (предположим в 5-м месяце).
Теперь, что бы SQL отобрал цену в 3-м месце делаю так:
select t.KOD,...,M1,M2...M12
(select c.CENA from Z_HIS_CEN c where c.DAT=(select max(DAT) from Z_HIS_CEN where DAT<"01.04.2005" and kod=c.kod ) and v.kod=c.kod) as C2,... C12
from NSI_TOVAR t
Чувствую, что-то намудрила, SQL свое отрабатывает и получает то, что нужно, но срабатывает около 10 минут. Может можно как нибудь по проще...:)

← →
Sergey13 © (2006-06-02 12:32) [1]

>Есть таблица заказов KOD....
KOD чего? Заказа? Товара?
Что будет если за месяц цена менялась не 1 раз? Да даже и один - какю брать - ревоначальную или конечную? Может проще (и правильнее?) посчитать среднюю цену товара и использовать ее?

← →
Sergey13 © (2006-06-02 12:33) [2]

Блин! Опечаток то сколько. Сори. 8-)

← →
elena_pp (2006-06-02 13:00) [3]

KOD товара

← →
MsGuns © (2006-06-02 13:10) [4]

Прежде чем создавать таблицы, надо
1. Четко описать задачу
2. Определить входную и выходную информацию (документы, отчеты, картотеки, прайсы и т.д.)
3. Описать бъекты: "поставщики", "покупатели", "товар", "склад", "приходный документ", "расходный документ" и т.д.
4. Увязать все объекты в одну модель.
5. Выделить справочники (первая ступень нормализации)
6. Определить связи один-ко многим (например, для документов, прайсов, картотек..) (вторая ступень нормализации)
7. Приступать к переносу модели "в металл", т.е. в БД

Тогда не будут появляться "шедевры" типа сабжевого

← →
elena_pp (2006-06-02 14:37) [5]

<<MsGuns
К разработке приступили так
1. Техническое задание на программу, в которой указаны
>>1. Четко описать задачу
>>2. Определить входную и выходную информацию (документы, отчеты, >>картотеки, прайсы и т.д.)
>>3. Описать >>бъекты: "поставщики", "покупатели", "товар", "склад", "приходный >>документ", "расходный документ" и т.д.
>>4. Увязать все объекты в одну модель.

5. Справочники следующие: Справочник товаров, таблица заказа, справочник истории цен.
6-7 . Связи один ко многим KOD в справочнике товаров и KOD таблицы CENA
Связи один ко многим KOD в справочнике KOD и KOD таблица заказов
Остальные связи рассказывать не буду - связано около 15 таблиц и справочников, в результате действуют уже 12 программ.
Теперь задача следующая - увязать историю цен с заказом :)

← →
Sergey13 © (2006-06-02 14:53) [6]

2[5] elena_pp (02.06.06 14:37)
Ты бы лучше задачу описала попдробнее.
>Пишу программу годовая заявка:
Заявка на следующий год? Или это статистика за прошлый/текущий? Хотя какая статистика в заявке. Какая разница для заявки на будущий декабрь, какая цена была в прошлом декабре? В общем, смысл работы мне лично пока не понятен.

← →
MsGuns © (2006-06-02 14:59) [7]

>5. Справочники следующие:
>Справочник товаров

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

>таблица заказа

"Заказы" - это самостоятельный объекты, а не справочник. Поэтому надо их выделить в самостоятельные таблицы с привязкой к покупателям. Так же, как и "Заявки" - для поставщиков

>справочник истории цен.

Не нужен вообще. "Цена" не есть объект, а есть лишь св-во других объектов: фактур приходов и расходов, складской карточки товара при учете по товару, прайсов

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

Напрасно. Прежде чем лепить таблицы надо все же выстроить модель. Которой пока не видать.

>Теперь задача следующая - увязать историю цен с заказом :)

Фантомная задача, "вылезшая" из неправильно построенной модели и неясно предсавляемыми задачами проекта.

← →
MsGuns © (2006-06-02 15:07) [8]

Для нормального складского учета должны быть определены объекты:
"Контрагент"
"Группа контрагентов" (дерево)
"Товар"
"Группа товара" (дерево)
"Карточка" (текущий остаток, ср/взв цена учетная при учете по товару)
"Приход от поставщика" (заголовок+фактура+проплаты)
"Накладные" (отгрузка, внутр.перемещение, списание, возврат от покупателя и т.д.) (заголовок+фактура+проплаты)
"Склад" - для многоскладского хозяйства
"Картотека" - "второй этаж" "Склада", состоящая из "карточек"
"Прайс-лист" (несколько уровней в зависимости от связок с прайсами поставщиков и прайсами покупятелям)
"Заявка" - для планирования и отслеживания поставок от оптовых поставщиков, с которыми есть "долгоиграющие" договора
"Заказ" - для планирования и отслеживания отгрузок покупателям, с которыми есть "долгоиграющие" договора

Если есть розница, то надо еще кое-чего ;)))

← →
Mamed (2006-06-05 12:38) [10]

Kod tovara,chena ,nacahlanay data,konechnayadata

1. Таблица товаров (может быть несколько нормализованных или иерархических таблиц). По крацней мере, каждый товар характеризуется уникальным кодом.
1.1. Возможно, в конечной таблице товаров хранится ТЕКУЩАЯ цена на товар (у меня это просто упрощало многие выборки, но по хорошему - надо смотреть и прикидывать).

2. Таблица заказов. Фактически - уникальное число (код заказа), дата-время оформления заказа, дата-время исполнения заказа (если надо). Возможно - общая сумма заказа (для упрощения некоторых выборок).
2.1. Детали заказа. Уникальный код, вторичный ключ на 2.Код_Заказа, вторичный ключ на код товара, количество товара.

3. Таблица "История изменения цены товара". Код товара, дата изменения цены, цена "ДО", цена "ПОСЛЕ".

ИМХО, так.

← →
elena_pp (2006-06-09 17:55) [12]

Спасибо Ega23 - воплотила пункт 3 (Таблица "История изменения цены товара". Код товара, дата изменения цены, цена "ДО", цена "ПОСЛЕ"). Все работает!!!

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