Рассудите нас..

infoteh2003 · Сообщение **infoteh2003** » 28 сен 2005, 21:20

Нас несколько человек решили написать собственную настройку одной бух.программы на FB.Клиент пишется в Москве в одной фирме..База дана нулевая с основными системными и пользовательскими таблицами.Мы можем добавлять новые таблицы,просмотры,процедуры,это все будет доступно в клиенте.Но спор возник в том,что я предлагаю по максимуму описывать обработку на сервере (через IBExpert),тут же вести контроль целостности базы,ссылок..разработку триггеров и генераторов..Другой разработчик в виду не знания работы сервера,утверждает что это ГЛУПО,и все необходимо писать на клиентском приложении..
Второй спор,я предлагаю каждую задачу вести в собственных журналах (таблицах с детализациями-подчиненными табличками)..Это Касса,Банк,ВзаимоЗачеты и Авансовые Отчеты,а также журнал учета операций ТМЦ и услуг,и журнал операций с ОС и НМА.. Согласно нормализации это верно..
Но мой аппанент опять же говорит это все неверно,нужно хранить в одной таблице..
Жду ответа..

_so_ · Сообщение **_so_** » 29 сен 2005, 08:54

На счет второго спора. Исходя из опыта реализации этих задач, я бы сделал в отдельных таблицах, слишком у этих задач разнародная информация. Но возможно объединения (например банк и касса, там очень все похоже; также возможно объединения ОС с НМА).
на счет первого незнаю. У нас работает третий вариант. За это отвечает сервер приложений.

Сообщение **kdv** » 29 сен 2005, 10:29

по первому спору - у вас две крайности. одна крайность - кидать ВСЕ на сервер, вторая крайность - ничего кроме таблиц не держать на сервере. В зависимости от задачи надо выбирать нечто среднее. Второму программисту сунуть под нос какую-нибудь популярную литературу, ибо сочетание крайности с незнанием - это просто глупость.

почти то же самое и по второму спору. если делать все в одной таблице, то зачем тогда сервер ?

судя по спорам я бы вообще предложил может быть резкое решение - избавиться от этого второго разработчика. По скудному описанию споров пока можно только сделать вывод, что он вообще ничего не знает, и кроме как примитивных задач в лучшем случае с dbf не писал.

infoteh2003 · Сообщение **infoteh2003** » 29 сен 2005, 12:23

Ну на сервере не все скажем будет..В клиентском приложении будут обработчики (сумм,количества,вызова расчета остатка,выбора получателя и отправителя и т.п.).Но по максимуму что связано с ссылками и их обработкой то я делаю на сервере..
По поводу второго спора,вы действительно правы,второй разработчик работал только с dbf.

infoteh2003 · Сообщение **infoteh2003** » 29 сен 2005, 12:28

_so_ писал(а):На счет второго спора. Исходя из опыта реализации этих задач, я бы сделал в отдельных таблицах, слишком у этих задач разнародная информация. Но возможно объединения (например банк и касса, там очень все похоже; также возможно объединения ОС с НМА).
на счет первого незнаю. У нас работает третий вариант. За это отвечает сервер приложений.

Кассу и банк объединить можно..Разграничение делается в настройке Клиента,но как вы знаете что Через банк идут налоговые платежи (предпоследняя строчка-колонки в платежке) а это естественно лишние поля..К тому же в Кассовых документах на расход необходимо хранить паспортные данные получателя..Они могут быть разовые поэтому джержать в отдельном справочнике нет смысла.
ОС и НМА это одна тема,т.к имеется начисление износа..
в ТМЦ разделил по детализациям(подчиненным таблицам) услуги и товары..так лучше и нет путаницы,к тому же разная настройка ПРОВОДОК в бухгалтерию
Спасибо за ответ!

MuirsheenDurkin

Четвертый вариант. Хранить общую для всех таблиц часть в одной таблице, остальное - в другой. Завести таблицу документов, хранить в ней номер\дату\сумму и тому подобное. Завести таблицу кассовых документов, ссылаться из нее на документ и создать в ней поля типа фамилилии кассира (не владею предметной областью, sorry).

Предложение kdv (отказаться от второго разработчика) считаю единственно правильным.

Ivan_Pisarevsky

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

Звиняйте коллега, но Вам бы теорию построения БД слехка подучить... Паспортные данные это не атрибут документа, это атрибут контрагента, причем у контрагента может быть несколько паспортых данных (паспорта регулярно меняются, теряются, выходят замуж и тп.). Посему, чтоб потом не геморрой не разгребать, для паспортных данных отдельную табличку которая прицеплена к табличке конрагентов как один-ко-многим, в документе хранить ссылочку на контрагента и ссылочку на паспортные данные.

Четвертый вариант. Хранить общую для всех таблиц часть в одной таблице, остальное - в другой.

Может таки изначально строить БД, чтоб было похоже на НФБК ?

MuirsheenDurkin

Ivan_Pisarevsky писал(а):Может таки изначально строить БД, чтоб было похоже на НФБК ?

BCNF - не догма, а средство передвижения. Строить базу надо так, чтобы сам автор мог потом в ней разобраться.....