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)
Тут базовое направление очень простое - чем больше проверок целостности задекларировано в базе - тем лучше. Во-первых - это инкапсуляция, иначе будете где-то что-то дополнять в интерфейсе, забудете проверить - и опаньки. Во-вторых - это может помочь оптимизатору с генерацией планов. В третьих - это обезопасит базу от некорректного изменения мимо вашего клиента (да-да, это тоже может оказаться проблемой, в том числе вы сами можете править данные запросами напрямую и что-то упустить). Это так, навскидку.