|
Моя Киса уже умаялась смотреть концерты, а я спать пока не хочу
==============================
IDDOC, счетчик (код записи)
DOCTYPE, числовой (тип документа)
DOCNUM, текстовый (номер документа)
DOCDATE, дата/время (дата по документу)
FACTDATE, дата/время (дата по факту)
ORG1, числовой (организация, отпускающая товар)
ORG2, числовой (организация-получатель товара)
ORG_PAYER1, числовой (организация-плательщик со стороны продавца)
ORG_PAYER2, числовой (организация-плательщик со стороны покупателя)
DISCOUNT, числовой (скидка)
PKORDERNUM, текстовый (номер приходно-кассового ордера)
OSNOVANIE, текстовый (основание для выписки документа)
PACKAGE, числовой (всего мест по накладной)
SOURCEIDDOC, числовой (код записи парного документа)
DELIVERDATE, дата/время (дата доставки заказа - для заказов)
DELIVERTIME1, дата/время (время1 доставки заказа)
DELIVERTIME2, дата/время (время2 доставки заказа)
VALUTE, числовой (код валюты - рубль default)
ADDRECDATE, дата/время (дата добавления записи)
FORRETAIL, Логический
FORLOOK, Логический
=================
Сначала про индексы. Обычно нужна выборка по типу документа, значит первое поле - DOCTYPE. Потом, обычно, интересует период (год, квартал, месяц) - DOCDATE. Но индекс должен быть уникален. Значит для своих документов нужен DOCNUM. Правда, у входящих документов могут быть совпадающие номера. И их даже может и не быть. И посему, в конце - IDDOC.
Я так понимаю, что для полей ORG* есть справочники. И это правильно.
Я являюсь противником хранения процента скидки. Скидка делается при выписке и лучше просто заносить в документ высчитанную цену. Причем применяемый Вами вариант скидок слишком негибок. Ведь могут быть скидки в абсолютных суммах и скидки на часть товара по одной накладной.
PACKAGE. В данном случае это лишнее. Число мест
(сорри, сбегал выпил 50 грамм) имеет смысл в контексте одной накладной. Типа указания грузчикам, что бы меньше путались. Это всегда можно взять из накладной. В нормализованой базе не должно быть полей, значения которых можно получить на основании других данных из этой базы. И у Вас не тот случай, когда нужна денормализация.
OSNOVANIE - если это номер договора, тогда претензий нет. Но если это in ("Покупка", "Распоряжение директора", ets), то это должно быть вынесено в справочник.
SOURCEIDDOC - не понял, что это, но скорее всего должна быть таблица сопутствующих документов, со связью по IDOC
VALUTE, PKORDERNUM - это должно быть в таблице оплат. Ведь по одному заказу могут оплачивать частями и разными валютами. И не только ПКО может быть. А если по безналу?
DELIVERDATE,DELIVERTIME1,DELIVERTIME2 - это лишнее. Должна быть таблица заказов, со связью по IDOC
===========
Даже если Вы будете (сорри, еще 50 грамм) работать на Access, укорочение длины записей даст некотрый выигрышь в скорости. Но про наилучшее ускорение нужно спросить у профи из Access. Я попробую их позвать. Ноя уверен, что снятие IDOC с первого места из Primary Key увеличит скорость аггрегитирующих запросов. (по крайней мере в SQL-серверах это так, но и Access тоже делает некоторую оптимизацию запросов)
ADDRECDATE - а это очень нужно? Все равно, полный аудит работы юзеров на Access сделать можно, но муторно.
FACTDATE - не понял. Это дата полного выполнения обязательств по договору?
=========
Прошу прошенитя за орфографию. Я уже и в клавиатуру-то непопадаю. Баинки пора. Но еще 50 грамм выпью!
|
