Нужен совет по структуре таблиц

← →
KIR © (2003-05-15 13:38) [0]

Ситуация следующая: есть две таблицы, олицетворяющие оплаты клиентов.
1 таблица - главная в ней заголовок: дата, сумма, ключ клиента и т.д.
2 таблица - подчиненная в ней коды товаров, за которые уплочено.

В принципе ситуация стандартная. Но дело в том, что иногда (довольно редко процентов 5-10) оплата производится по безналу. Хочу спросить совет как это грамотно оформлять. у меня два варианта:
1 - добавить в мастер таблицу 2 поля типа SMALLINT и ставить в первое поле единичку, а второе оставлять пустым, если нал. И ставить в первое нолик, если безнал, а во второе ставить единичку, когда деньги поступили на счет. Но тогда получится целая куча как бы лишних единичек и null"в, т.к. в основном в итак платят наличностью.
2 - создать еще одну таблицу с двумя полями, которая будет пополняться только в случае безнала

← →
gek © (2003-05-15 13:44) [1]

> 1 - добавить в мастер таблицу 2 поля типа SMALLINT

Тогда уж лучше одно - 0 or 1

← →
JohnnyJ © (2003-05-16 09:54) [2]

Если в основном платят налом, то лучше второй вариант.

← →
Sergey13 © (2003-05-16 10:07) [3]

2JohnnyJ © (16.05.03 09:54)
>Если в основном платят налом, то лучше второй вариант.
Чем лучше? Чем первый. 8-)
Так на постоянном объединении двух таблиц больше потеряешь, ИМХО. Я бы поддержал gek © (15.05.03 13:44)

← →
Сергей Суровцев © (2003-05-16 10:44) [4]

Вариант gek © (15.05.03 13:44)
Но лучше в подчиненную таблицу - так гибкость больше.

← →
Sergey13 © (2003-05-16 10:57) [5]

2Сергей Суровцев © (16.05.03 10:44)
>Но лучше в подчиненную таблицу - так гибкость больше.
Какая гибкость? Если есть оплата, то если вы занесете данные о виде оплаты ЧАСТИ записей в другую таблицу, это означает, что для оставшихся записей информации о виде оплаты просто НЕТ. Какая тут гибкость? Ты попробуй написать запрос по документам с выводом вида оплаты для обоих вариантов, и сразу все станет ясно. Я не говорю, что это сложно, я спрашиваю - зачем?
Тут рассматривался вариант с нал/безнал. Логично предположить, что может добавиться еще, например, бартер. Что, в другую подчиненную таблу писать?

← →
Anatoly Podgoretsky © (2003-05-16 11:12) [6]

Деньги не пахнут, а если пахнут, то нужна колонка с видом запаха.

← →
Danilka © (2003-05-16 11:19) [7]

Sergey13 © (16.05.03 10:57)
ну, если что-то предполагать, то можно предположить, что для безнала что-то еще понадобится, (например номер счета) что для безнала нафиг не нужно - отсюда и гибкость. :))

если-же быть есть уверенность что ничего не добавится, тогда лучше все-таки gek © (15.05.03 13:44)

← →
Danilka © (2003-05-16 11:27) [8]

упс...
вместо:

что для безнала нафиг не нужно - отсюда и гибкость. :))

следует читать:

что для нала нафиг не нужно - отсюда и гибкость. :))

← →
Sergey13 © (2003-05-16 11:30) [9]

2Danilka © (16.05.03 11:19)
>ну, если что-то предполагать, то можно предположить, что для безнала что-то еще понадобится, (например номер счета) что для безнала нафиг не нужно - отсюда и гибкость. :))
Ты предлагаешь на КАЖДУЮ оплату номер счета вешать? Я то думал что этот номер в свойствах клиента прописан. А для нала тогда может понадобиться вид валюты и курс на дату.
Что то из мухи слон прорисовывается. 8-) Наверное в "потрепаться" пора переносить. 8-)

← →
Danilka © (2003-05-16 11:34) [10]

Sergey13 © (16.05.03 11:30)
1. у клиентов может быть не один десяток счетов, кроме того, это просто пример, где там гибкость.
2. потрепаться, ну если есть желание, у меня, честно говоря, нету, пусть хозяин ветки решает сам, надо ему что-то на безнал дополнительно вешать или нет.

конечно, номер счета клиента будет в платежке

>Sergey13 © (16.05.03 10:57)
>Какая гибкость?
Лишних баз не нужно, у него их две есть и хватит. Но
признак оплаты, как и совмещенный с ним тип оплаты
(0-не оплачено / 1-оплачено нал / 2-оплачено безнал)
нужно ставить в списке товаров, т.е. подчиненной
таблице. Гибкость в том, что часть одного и того же
заказа (на который в главной безе одна строка) может
быть оплачена, часть нет, часть налом, часть безналом
и т.д. Могут появиться и другие виды оплаты, которые
в этом случае легко добавить. Я бы еще и дату на
базу товаров повесил - когда была оплата каждого товара.

Может и не набо было поднимать эту ветку... 8-)

2Danilka © (16.05.03 11:37)
>конечно, номер счета клиента будет в платежке
В платежке (бумажной) будет, но каждый раз вводить 20и значные счета - через пару месяцев у клиентов будет и правда будет "не один десяток счетов" 8-) Эти счета должны быть в справочнике клиентов а не в сведениях по оплате.

2Сергей Суровцев © (16.05.03 14:31)
>Нопризнак оплаты, как и совмещенный с ним тип оплаты
нужно ставить в списке товаров
Ты че?!!! Был документ и список товаров в 1000 позиций. Ты предлагаешь в каждую позицию заносить (разносить!!!) оплату. да тебя расстреляют бухгалтеры. Оплата относится к документу, а не к каждому товару отдельно.

>Гибкость в том, что часть одного и того же
заказа (на который в главной безе одна строка) может
быть оплачена, часть нет, часть налом, часть безналом
и т.д. Могут появиться и другие виды оплаты, которые
в этом случае легко добавить.
В этом случае нужна отдельная таблица оплат по ДОКУМЕНТАМ со связью один ко многим.

>Я бы еще и дату на базу товаров повесил - когда была оплата каждого товара.
Тебя бы заставить работать с такой базой. 8-)

Sergey13 © (19.05.03 09:25)
>каждый раз вводить 20и значные счета
это уже интерфейс как их ручками вводить, выбирать из списка или еще как.

ну, конечно можно все сделать по документам и связям между ними, так будет даже правильнее, сейчас мы автору ветки по-быстрому набросаем модель данных, пусть реализует, зато все будет по-правильному. :))

Нужен совет по структуре таблиц Найти похожие ветки