Форум: "Базы";
Текущий архив: 2003.07.14;
Скачать: [xml.tar.bz2];
ВнизСтруктура базы InterBase Найти похожие ветки
← →
ruslan_as (2003-06-21 11:13) [0]Готовлю базу под ежемесячные платежи клиентов
Какая структура будет легче работать?
Эта:
Код клиента-Год-Номер месяца-Сумма (тогда будет 120000 записей ежегодно)
Или Эта:
Код клиента -Год- Январь -Февраль-...Декабрь - Сумма (тогда 10000 ежегодно)
← →
Наталия (2003-06-21 11:32) [1]Это зависит от того, какие операции ты собираешься над этими данными производить.
← →
Alexandr (2003-06-21 11:36) [2]сдается мне, первая.
← →
Digitman (2003-06-21 11:38) [3]
> будет легче работать
что значит "легче" ?
для табличных объектов БД есть понятия "вставка записей", "изменение записей", "удаление записей", "выборка записей"
для каждой из приведенных тобой структур комплексная и индивидуальная производительности операций вставки/изменения/удаления/выборки записей будут отличаться.
кр.того, конкретная схема индексации такой таблицы в обоих вариантах, веротно, будет различной (если вообще разрабатывается и применяется), что тоже влияет на индивидуальную и комплексную производительность сервера, выполняющего запросы по указанным операциям.
оперируя именно этими понятиями, уточни и переформулируй вопрос
← →
Danilka (2003-06-21 11:46) [4]ну, я-бы все-таки выбрал первый вариант, запросы намного более красивые получатся, например сумма всех платежей за выбраный период (9 месяцев) и т.д.
← →
ruslan_as (2003-06-21 11:47) [5]Записи будут расти в наростающем порядке
Сервер и клиент на одной машине
Над таблицой будут производиться в основном выборка и вставка записей.
Индексация в первом случае Код клиента -Год - Номер месяца
Во втором случае Код клиента -Год
← →
Anatoly Podgoretsky (2003-06-21 11:56) [6]Да в любом случае нехорошо, поскольку год отделен от месяца, правильнее код, дата, сумма. Да и еще ты хочешь это делать на рабочей станции и не жалко данных или они просто ничего не стоят?
← →
ruslan_as (2003-06-21 12:06) [7]спасибо!
>>Anatoly Podgoretsky
>>Да и еще ты хочешь это делать на рабочей станции и не жалко данных или они просто ничего не стоят?
Просто у них всего одна машина.
А год отделен от платежей, так как абонент может заплатить наперед (абонплата за месяц 5 грн а абонент заплатил 17 грн.).
Дату платежа прийдется вести отдельно.
Может еще какие советы будут...
← →
Digitman (2003-06-21 12:21) [8]При прочих равных условиях я бы тоже поступил по варианту
> Anatoly Podgoretsky © (21.06.03 11:56)
уник.индекс по "код-дата"
единственное, что может несколько осложнить конечную задачу - формирование cross-tab-выборки, если она нужна. здесь потребуется время на decode date (на клиенте это будет делаться или на сервере - не столь важно) по каждой записи в выборке, прежде чем начнется группировка.
в случае с "код-год-месяц" временные затраты на извлечение тек.года/месяца из полного формата даты не нужны, сразу же группировка выполняется.
← →
Digitman (2003-06-21 12:35) [9]
> ruslan_as © (21.06.03 12:06)
тогда задача усложняется.
видимо, одной таблицей здесь не обойтись.
придется, наверно, вести таблицу платежей как первичный справочник, вида "pk_id - код_клиента - дата_платежа - №документа - полная_сумма_платежа", и подчиненную таблицу-документ вида "fk_id - год - месяц - сумма_за_месяц", в которую на основании платежа как первичного док-та будут заноситься записи об абон.платах, разнесенные по месяцам
например, аб.плата = 5грн.
клиент 3 января заплатил за период с янв. по апр. тек.года 17 грн на основании квитанции такой-то.
в первичном справочнике фиксируется дата, №док, сумма платежа
в подч.таблице эта полная сумма разносится на 4 записи : янв. - 5грн., февр. - 5грн, март - 5грн, апр. - 2грн
в след.раз, когда клиенть будет осуществлять платеж, недостающие за апрель 3грн будут добавлены с этого платежа. Оставшиеся деньги разнесены по другим месяцам, за которые платеж еще не осуществлялся.
← →
MsGuns (2003-06-21 13:21) [10]Вариант с годом и месяцем (месяцами) хорош, если каждый клиент платит аккуратно один раз в месяц, что мне представляется весьма сомнительным. Кроме того, эта структура не предусматривает платежи наперед или просроченные (т.е. когда чел в марте платит за январь или в апреле за май-июнь и т.д.).
Поэтому предложение Анатолия, поддержанное Digitman ©, мне кажется более универсальным. Выборки по такой БД не должны быть долгими. Для некоторых постоянных типов запросов (например суммы платежей помесячно) целесообразно создать представления, что существенно ускорит наиболее часто выполняемые запросы клиентов.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.07.14;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.009 c