Проблема частичного совпадения реквизитов объектов «сотрудники» и «контрагенты».
Множество реквизитов «контрагентов» и «сотрудников» имеют весьма схожие цели и идентификаторы. Это, например, РНН (ИН), телефон, фактический адрес, email (и другие веб-адреса), банковский счет (IBAN) и т.д. Во-1-х, это просто неудобно и контрпродуктивно. У лиц, постоянно работающих с базой данных, неизбежно возникали трудности в работе, потому что нужно было различать «адрес контрагента» и «адрес сотрудника», «телефон контрагента» и «телефон сотрудника», и т.д. Программистам такое разделение тоже доставляет неудобства в работе по добавлению новых возможностей и поддержке старых. Во-2-х, такое значительное совпадение реквизитов этих видов сущностей, согласно теории, говорит об том, что, скорее всего, эти виды сущностей являются подвидами (подклассами) другой, более высокой обобщающей сущности. И это действительно так, и мы эту сущность увидим, покажем и опишем, но это будет чуть позже. В-3-х, дальше, например, появилась и все более росла потребность в объектах, не являющихся ни «контрагентами», ни «сотрудниками». Например, в программе нужно отразить водителя грузовика, заехавшего на территорию нашего предприятия под разгрузку-погрузку. Водитель не является ни нашим сотрудником, ни сторонним контрагентом, имеет РНН, адрес проживания, и прочие реквизиты, которые нужно записать в базе. Приходилось записывать водителя в «контрагенты», либо в «сотрудники», притом, что ни то и ни другое не соответствовали действительности и только лишь загрязняли базу данных, и таких не укладывающихся в теорию случаев становилось все больше. Подобные задачи привели к созданию категории объектов «физические лица», по мнению автора, не добавившей ясности и четкости в сложившуюся ситуацию.
Совершенно ненужное разделение самого предприятия как «организации» и его «контрагентов» как разных типов.
Категория «организации» (т.е. наше предприятие и его филиалы), на взгляд автора, из, казалось бы, логичного и правильного объекта, со временем превратилась только в большую помеху для развития программ и баз данных. Благодаря наличию «организаций» как отдельного класса объектов приходилось создавать много дублирующих типов объектов документов, например, «Счет-фактура исходящий», «Счет-фактура входящий», и т.д. Не говоря уже о постоянном обыгрывании в коде двух разных типов – «контрагенты» и «организации». Хотя, в принципе можно было бы признать «наше предприятие» точно-таким же «контрагентом» и точно таким же образом пользоваться одними и теми же типами объектов вроде «Счет-фактура», просто в роли поставщика были бы разные контрагенты – или же наша организация, или же сторонние контрагенты. Но - что сделано, то сделано. Из-за наличия этого излишнего, на взгляд автора, класса объектов, исходная модель усложнилась, разбухла, и стала выглядеть так – «контрагенты», «организации», «сотрудники», «физические лица». Отдельной проблемой было отражение «учредителей» в программах, которых подразумевали опять же обособленной отдельной сущностью, и в связи с этим требовалось налаживать взаимосвязи «учредителей» с «контрагентами», «физическими лицами» или «сотрудниками». Хорошо хоть, что операций с «учредителями» обычно не так много.
|