fowork,

разбейте задачу на подзадачи:
1. Имеет смысл объединение таблиц Счет и Счет-фактура в одну или это создаст больше проблем, чем решит? Но проблему организации связей это не решит в любом случае.
2. Что все-таки первично - счет или счет-фактура? Имхо все-таки счет (хотя я могу ошибаться), т.е. имеет смысл Счет-Фактуру привязывать к Счету, но сделать эту связь необязательной (NULLABLE). Либо можно создать отдельную таблицу связей между ними.
3. Если создана таблица связей Счет-Счет-фактура, то проблема, считайте, уже решена:в платеже ставите ссылку на запись в этой таблице и через нее вытаскиваете счета.
Если нет - тогда создаете в платеже 2 отдельных необязательных связи и накладываете условие проверки, что указаны связанные счета. Либо триггерами поддерживаете валидность этих полей.

fowork,

1. Про уменьшение количества таблиц ничего больше добавить не могу - информации мало. Только, учитывая, что связь счет-счет-фактура фактически N-N (вроде как вы с этим согласились), ссылку на "опорный документ" использовать все равно не удастся, нужна таблица связей.
2. А вы уверены, что одна платежка не может в таком разе закрывать несколько счетов-фактур/счетов? Может тут тоже таблицу связей придется использовать?

fowork,

эммм.... ну вообще про номенклатуру речи не было. А раз уж она появилась - зачем вы пытаетесь запихать ее в таблицы счетов???? И потом, вы так и не ответили - платеж собствено к чему привязан? Допустим если у вас 2 счета сч1 и сч2, два счета-фактуры сф1 (закрывающий половину сч1 и половину сч2) и сф2 (закрывающий вторую половину сч1 и сч2), и один платеж на общую сумму- как вы это будете хранить?

foworkто iljy

>как оно может отразиться в будущем (если в ту же таблицу отправятся товарные накладные например) (мой пост в 12:11, конец п.1)

> один платеж на общую сумму- как вы это будете хранить?

в таком случае в платежах (bank_payment) будет 2 записи: 1 ссылается на счёт-фактуру1 и 2 ссылается на счёт-фактуру2, но обе записи имеют данные одной платёжки (номер, дату, отправитель, получатель и т.д.)
А если платежей тоже 2, и первый гасит часть суммы из сф1, а второй - остаток сф1 и всю сумму сф2?
Не делайте так. Вы повеситесь, а потом ваше бренное дело закоптят на медленном огне и распнут на дверях в назидание преемникам. Сделайте еще одну таблицу связей, или вообще откажитесь от привязки платежей к счетам и анализируйте сальдо на дату.

fowork
> Допустим если у вас 2 счета сч1 и сч2, два счета-фактуры сф1 (закрывающий половину сч1 и половину сч2) и сф2 (закрывающий > вторую половину сч1 и сч2)

Честно говоря затрудняюсь предствить, как это можно корректно хранить...
Попытался представить случай, когда такое может быть: нам выставили счёт на аванс 30%,потом мы забираем товар 50%, потом счёт на доплату 70%, и мы забираем оставшийся товар 50% ... гм, но тогда будет 2 платежа, каждый на свой счёт.
Вот вам пример: в разное время выставлялись 2 независымых счета, затем по этим счетам одним платежем быть выплачен аванс 30%, затем логист поехал и забрал то, что было в наличии, получив сф1, через неделю курьер привез остаток и сф2, после чего был платеж оставшихся 70%. Может такое быть? Если может - тогда отказывайтесь от привязки платежей к счетам, привызывайте их к контрагентам, а счета и счета-фактуры связывайте через номенклатуру. Если нет - тогда сформулируйте требования и ограничения предметной области, иначе итераций будет очень много.

fowork,

1. bank_payment в таком виде не удовлетворяет 3НФ. Насколько это серьезно для вас - решайте сами.
2. Ссылочную целостность можно будет контроллировать только триггерами.
3. Подумайте над тем, какие выборки вам придется делать из таблиц и насколько это будет удобно.
4. У вас еще где-то должна быть номенклатура - как вы ее планируете вписать в эту схему?

foworkto iljy

1. Не был с этим знаком с теоретической стороны. Теперь обязательно ознакомлюсь, спасибо вам огромное! :)

Не за что Нормальные формы знать надо обязательно, хотя бы до 3й.

fowork2. Не очень понимаю, что значит "ссылочная целостность" в данном контексте. Поясните пожалуйста, если не сложно.
Указывать ссылки на опорный документ и основной документ (в bill) планировал при заведении новых записей.

Ссылочная целостность - это корректность связей между объектами. У вас в таком виде ВК не гарантирует, что связываются не 2 счета, а именно счет и счет-фактура. Нужны будут дополнительные телодвижения, типа CHECK CONSTRAINT или триггеров. Можно конечно положиться полностью на клиента, но это выстрел себе в ногу. Ошибка в работе программы, которая обнаружиться к моменту сдачи годового отчета - и вы будете полбазы перелопачивать ручками.
fowork3. Пока в планах реализовать в интерфейсе привязку нескольких счетов (bill) к одной записи в платежах (bank_payment), для неё как раз и нужно будет вынести отдельную таблицу вязки платёж-счёт (bank_payment_link), как вы и говорили. Но т.к. проект развивается при непосредственной эксплуатации, то не могу внести изменения в базу без поддержки в интерфейсе.
Но пока оставлю вязку счетов и счёт-фактур в нутри одной таблицы (bill), может при дальнейшем развитии возникнет смысл вынести связи между ними в отдельную таблицу, но пока мне это кажется не "рентабельным"
Вам виднее. Но выборки у вас в таком виде усложняются. Напишите например запрос, который вытащит все платежки с номерами счетов и счетов фактур, которые есть. Я не говорю, что его нельзя написать, нет, но он будет явно сложнее, чем просто соединение 3х или 4х таблиц. Придумайте еще несколько наиболее актуальных запросов и попробуйте их написать.

fowork4.Номенклатура есть. Она вяжется через отдельную таблицу ссылок. Считаю это обоснованным, т.к. на одн счёт может быть несколько счетов фактур с разной номенклатурой. Хотя сейчас размышляю над тем, как это можно преобразовать, чтобы избегать повторных записей при совпадении номенклатуры для разных документов по одной сделке.

Я думаю у вас очень быстро возникнет, например, такая задача: проверить, вся ли номенклатура по счету получена. Или полностью ли счет оплачен (учитывая, что часть платежей может быть привязана к счетам, а часть - к счетам фактурам). И кстати:
foworkiljyВот вам пример: в разное время выставлялись 2 независымых счета, затем по этим счетам одним платежем быть выплачен аванс 30%, затем логист поехал и забрал то, что было в наличии (а в наличии могли быть позиции из разных счетов!), получив сф1, через неделю курьер привез остаток и сф2, после чего был платеж оставшихся 70%.
.....
А таблица счетов будет выглядеть следующим образом:
№ документа дата тип документа основной документ101.01.2011 счёт 201.01.2011 счёт 107.01.2011 счёт-фактура счёт 1207.01.2011 счёт-фактура счёт 2
Почему так? По сф1 была получена часть товара, выписанная в счете1, и часть , выписанная в счете2. По сф2 - остаток по обоим счетам. На основании чего вы привязали сф1 к счету1?

fowork,

не-а, не выдаст он так - с какого перепугу одно соединение по внешнему ключу даст вам 2 строки для каждой платежки? У вас должно быть что-то типа
При наличии таблицы связей bill_contract(idLink, id_bill, id_contract) будет похоже
А если попробовать горизонтальную выдачу, типа
НомерПлатежки ДатаПлатежки НомерСчета ДатаСчета НомерСчетаФактуры ДатаСчетыФактуры
,тогда в вашем варианте будет как-то так:
а в моем - так:
В приципе близко по сложности. Но в вашем варианте практически нет контроля целостности, о чем я уже писал: ваша база допускает связь счет-счет, либо счет-счет-фактура-счет и т.д.

foworkМожно ещё и так


Можно, но ваш запрос подразумевает, что платежка всегда привязана к опорному документу, а схема базы этого никак не гарантирует.

foworkТакая идея и была. Если нужно выбрать ещё и неоплаченные счета, то запрос конечтно будет другой
Я не про то. Если на момент оплаты были оба счета, то схема базы вам не гарантирует, что платеж будет привязан к опорному документу (а опорным у вас может быть любой). Схема базы вам вообще мало что гарантирует, вот в чем проблема. А про проверки на клиенте я вам уже писал.

foworkВ связи с этим у меня появляется ещё один вопрос, не знаю на сколько он к этой теме, но в контексте обсуждения думую можно затронуть...
Глобально он звучит так: Как определить, какую часть нагрузки возложить на интерфейс, а какую на структуру бызы, так чтобы база не потеряла гибкости, а интерфейс небыл перегружен проверками.

А локально могу сказать: Сейчас проверка вязки платежа к опорному документу осуществляется интерфейсом. Тоесть если есть основной опорный документ (id_parent is NULL), то пользователю в выпадающем списке показывается он, а если нет, то в выпадающем списке показываются все документы.
Определение основного документа возложенно на пользователя при внесении записей в счета (bill)
Тут базовое направление очень простое - чем больше проверок целостности задекларировано в базе - тем лучше. Во-первых - это инкапсуляция, иначе будете где-то что-то дополнять в интерфейсе, забудете проверить - и опаньки. Во-вторых - это может помочь оптимизатору с генерацией планов. В третьих - это обезопасит базу от некорректного изменения мимо вашего клиента (да-да, это тоже может оказаться проблемой, в том числе вы сами можете править данные запросами напрямую и что-то упустить). Это так, навскидку.