Как хранить суммы?

← →
yurikon03 (2003-04-04 09:30) [0]

Подскажите, как грамотно спроектировать таблицу(ы). Есть фирмы, есть периоды (месяца) и затраты фирм за период. Для одних фирм известны затраты за каждый месяц, а для других только за суммарный период (нпр год). Добавлять в таблицу периодов «обобщенный год» или как?

← →
Md (2003-04-04 09:34) [1]

Может сделать ещё один столбец, значение которого означает период (1-год, 2 -месяц и т.д.)

← →
Соловьев (2003-04-04 09:35) [2]

три таблицы. 1-я Отношение "Затраты фирм"
три поля:
1-е - код фирмы 2-е - затраты 3-е - код периода

Таблица 2-я:
1-е - код фирмы 2-е - имя фирмы

Таблица 3-я:
1-е - код периода 2-е - имя периода

← →
Sergey13 (2003-04-04 09:57) [3]

2yurikon03 (04.04.03 09:30)
Поля:
1 - год
2 - месяц начала периода
3 - месяц конца периода
4 - фирма (код)
5 - сумма
При помесячном вводе 2=3. Следить за условием 2<=3. Следить за неперекрытием периодов.

← →
MsGuns (2003-04-04 10:54) [4]

Не слушай гемор "про типы периодов" - это дорога в ад. Месяцы - и только они ! Если инфа поступает не ежемесячно, то в соотв. "пустом" месяце будут нулевые "обороты". Принцип Главной Книги в бухгалтерии. Для подобных вещей лучше ничего не придумаешь. А получить данные за любой период (даже в днях как разницы между датами) можно будет, если информация о движении финансов будет заводиться в виде "документов" с датой, номером и т.д.

← →
Sergey13 (2003-04-04 11:25) [5]

MsGuns © (04.04.03 10:54)
>Не слушай гемор "про типы периодов"
Ну уж так то категорично зачем. Ты, конечно дельно предложил. Вот только "Принцип Главной Книги в бухгалтерии" однозначно хорош бывает только для "Главной Книги в бухгалтерии". А задачи могу быть и иными. И вот, если они у человека иные, то твой метод может дать бешеный рост объема инфы, не улучшая при этом ее качества.

← →
MsGuns (2003-04-04 11:31) [6]

>Sergey13 © (04.04.03 11:25)
Для учетных задач, завязанных на хронологию, ввод объекта "период" как сущности БД, ИМХО, опасное заблуждение. Просто каждая запись (под записью я подразумеваю любую цельную единицу добавляемой в БД порции инфы) должна иметь св-во типа время, по которому и можно оперировать для получения данных за период (в принципе - любой, вплоть до интервала с 8.30 утра до 14.30 след.дня и т.д.). НИКАКОЙ ИЗБЫТОЧНОСТИ ИНФОРМАЦИИ В БД ПРИ ЭТОМ НЕ ВОЗНИКНЕТ !. А вот грамотности, четкости и достоверности добавит.
Сергей, спорить не надо - просто поверь опыту.

← →
Sergey13 (2003-04-04 11:54) [7]

2MsGuns © (04.04.03 11:31)
Если задаче ПОФИГУ когда конкретно было сделано что-то, а важно отметить только факт этого, зачем усугублять ситуацию. Если в задаче возможен только вопрос про время года, зачем хранить время суток?
Повторюсь, я не против твоего предложения, я против "однозначности" твоего совета, когда не известны начальные условия.
>Сергей, спорить не надо - просто поверь опыту.
А вот это мне нравится!!! Типа - иди, несмышленышь, погуляй, пока дяди разговаривают? 8-)

2yurikon03 (04.04.03 09:30)
Ау-у. Ты где. А то мы щас с MsGuns © подеремся. 8-) Про что твоя задача?

← →
MsGuns (2003-04-04 12:06) [8]

>Sergey13 © (04.04.03 11:54)
>Если задаче ПОФИГУ когда конкретно было сделано что-то, а важно отметить только факт этого, зачем усугублять ситуацию.

Судя по сабжу, задаче НЕ по фигу.

>Если в задаче возможен только вопрос про время года, зачем хранить время суток?
Я привел пример с временем суток лишь для убедительности того, что мой совет универсален. Не надо тебе время - используй только дату ! В БД вместе с датой время хранится все равно (в большинстве СУБД)

>А вот это мне нравится!!! Типа - иди, несмышленышь, погуляй, пока дяди разговаривают? 8-)

Рад, что тебе понравилось ;)) Опыт - штука уникальная и у каждого своя. Я не сомневаюсь, что у тебя есть немалый опыт (судя по твоим постам), но в ДАННОМ случае (именно в категориях "временных" и "периодичных"), ИМХО, он "пробуксовывет"

>А то мы щас с MsGuns © подеремся

Не собираюсь драться ни с кем, а тем более с людьми, которых уважаю и с мнением которых считаюсь.

← →
OneOfTheFew (2003-04-04 12:20) [9]

>MsGuns © (04.04.03 11:31)
>Для учетных задач, завязанных на хронологию, ввод
>объекта "период" как сущности БД, ИМХО, опасное заблуждение.

Хорошо, что прозвучали такие слова. Вопрос очень непростой и спорный. Куда деваться бедному программеру от "ввода объекта "период" как сущности БД",
если у каждого этого периода (будь он неладен) куча варьирующихся параметров: ну те-же прайс-листы. Вот взял Директор и "утвердил" на период с такого-то по такое-то такие-то расценки на что-либо, и еще с кучу всего "наутверждал" мерзавец!

Я не в драку лезу, просто хотелось бы развернуть эту тему, а то эти периоды все кровушку выпили.

← →
MsGuns (2003-04-04 12:21) [10]

Пример в дополнение:
Недавно сделал и сдал прогу "Учет давальческого сырья при изготовлении продукции на экспорт". Там ВООБЩЕ НЕТ НИКАКОЙ БУХГАЛТЕРИИ. В смысле счетов, сальдо, дебет-кредит и т.д.
Есть приходы сырья от иноср.поставщика, есть отгрузка продукции, изготовленной из этого самого сырья по некоторым определенным технологами нормам. ВСЕ ! Нужен учет движения сырья и продукции ПО ПЕРИОДАМ (месяц, квартал, полугодие или вообще произвольный период, например, с начала года по сегодня или за все время работы с данным поставщиком). Так вот, ВСЯ кухня у меня построена на датах поступления сырья и отргузки продукции.
Периоды, как таковые, задаются юзером для получения отчетов и используются как границы в запросах к соотв.сущностям БД. В самой же БД понятие "Период" как таковое отсутствует напрочь !

И, самое интересное, что Заказчик весьма доволен !
Старая прога (которую он практически не использовал) была построена именно на периодах. Т.е. нельзя было получить информацию (и даже отгрузить продукцию) о движении из "соседнего" периода или части его. В рез-те накапливался материал, не успевший "уйти" с продукцией в отведенный ему период, а в новом периоде по этому материалу была нехватка и прога "отказывалась" делать отгрузку РЕАЛЬНО изготовленной продукции.

ЗЫ. Я эти посты пишу совсем не для того, чтобы показать какой я, блин, вумный (это, ИМХО, не так), а чтобы людям неопытным помочь избежать подобных грубых просчетов при построении логики задачи и топологии БД.

← →
MsGuns (2003-04-04 12:27) [11]

>OneOfTheFew (04.04.03 12:20)
Надо хранить прайсы по периодам: Типа монитор стоит до 1.05.03 $135, а после - $145, будьте любезны ! Поставьте к прайсу доп. табличку (или многострочное мемо прямо в прайс), где отражайте граничные ДАТЫ (типа до этого числа) и соотв.цену (цены). Надо определить Прайс на такое-то число - дали запрос, где Max(Дата)<=Граница. Надо посмотреть динамику цен на мониторы за период (указывает ваш директор) - нет ничего проще - выборка по двум условиям !

← →
OneOfTheFew (2003-04-04 12:44) [12]

To MsGuns © (04.04.03 12:27)

Я в общемто согласен, но мне что так, что эдак - все едино и муторно. Единственное дополнение (ни в коем случае не наезд).
Мне кажется софт становится лучше, когда именно он берет контроль над непротиворечивостью информации, а не юзер. Я так наелся этих периодов: у меня помимо прайсов от периода зависят алгоритмы всяких там расчетов и проч.проч... Понимаешь, я вынужден агрегировать эту информацию под эгидой понятия ПЕРИОД, хотя бы потому, что если взять, например, 24 таких параметра и заставлять юзера всем им ставить пограничную дату (причем одну и ту же для всех:это в моей задаче так) - мне видится такое некорректным напрочь.

← →
Johnmen (2003-04-04 12:45) [13]

>MsGuns © (04.04.03 12:21)
>(это, ИМХО, не так),

Серега ! Скромность, конечно, украшает человека. Но нельзя же доходить до крайности в самокритике...:))))))

← →
MsGuns (2003-04-04 13:10) [14]

>OneOfTheFew (04.04.03 12:44)

В твоем случае (а он существенно отличается от сабжа, по крайней мере как я его понял), действительно есть смысл во введении в БД понятия "Период" как РАЗНИЦА МЕЖДУ ДВУМЯ ДАТАМИ, но не квартал, неделя и т.д. Для такого объекта может быть создана даже своя надстройка в БД (одна или несколько таблиц), где будут храниться все твои 24 характеристики. Прошу понять меня, что я НЕ ПРОТИВ ПЕРИОДОВ КАК ТАКОВЫХ, я против ТИПОВ периодов и прочей страхомордии в том месте, где должна быть предельная простота и ясность. В бухгалтерии (и не только) очень четко определено понятие "Период", но нигде еще в солидных программах я не встречал в структурах таблиц поле "Тип периода" и даже "период" (Месяцы и кварталы не в счет)
Если будут типы периодов и т.д. как советовали уже в этой ветке, то неизбежно их вложение, пересечение и т.д., что приведет к офигенному усложнению логики приложений. Именно это я и имел в виду и именно против этого так настойчиво выступаю ;)))

← →
OneOfTheFew (2003-04-04 15:35) [15]

To MsGuns

Согласен полностью! Ok

← →
yurikon03 (2003-04-04 15:59) [16]

>> MsGuns
Прога также про сырье + расходы по доставке + ПЛАН деятельности на будущие периоды.
Периоды действительно будут пересекаться. Если использовать только дату, то как определить - это затраты фирмы за месяц, квартал, год?
Радует, что вопрос нашел столько откликов, одиночество - печальная вещь :-(.

← →
MsGuns (2003-04-04 16:03) [17]

>yurikon03 (04.04.03 15:59)
>Если использовать только дату, то как определить - это затраты фирмы за месяц, квартал, год?

Что есть квартал ? А год ? ИНТЕРВАЛ МЕЖДУ ДВУМЯ ДАТАМИ !
Что есть дата ? день-МЕСЯЦ-ГОД !!!

;)))

← →
yurikon03 (2003-04-04 16:04) [18]

>>Соловьев © (04.04.03 09:35)
>>три таблицы. 1-я Отношение "Затраты фирм"
>>три поля:
>>1-е - код фирмы
>>2-е - затраты
>>3-е - код периода

>>Таблица 2-я:
>>1-е - код фирмы
>>2-е - имя фирмы

>>Таблица 3-я:
>>1-е - код периода
>>2-е - имя периода

Сейчас все в точности так и есть. Но, думается, при таком подходе будут трудности при запросах суммы затрат за год - как указывать ограничения?

Как хранить суммы? Найти похожие ветки