GaryaС моей индивидуальной точки зрения с точки зрения систематики невозможно четко идентифицировать понятие "объект" или "субъект" так, чтобы какая-либо автоматизированная система смогла бы отличать его от другого аналогичного объекта без помощи самого человека. Эти в существенной степени философский вопрос, и его рассмотрение обычно решается в ту или иную сторону в зависимости от контекста и на интеллектуальном уровне. Иванов И.И. в возрасте 3-х лет и в возрасте 60 лет - это один объект или разные? В них нет ни одной общей молекулы (которые уже сменились дважды). Он сменил номер паспорта - 5 раз, фамилию - 4 раза, гражданство - 3 раза, пол - один раз. И все-таки это один объект или разные? Если положительно ответить на этот вопрос, то при поиске тех естественных составляющих, которые-таки являются едиными и неизменными для этого объекта-субъекта, можно забраться в мистические и религиозные области, которые пока ( ) не поддаются автоматизации и четкой систематизации
Дело не в философии, но возможно в... мистике. Человек был создан Богом, чтобы всему сущему дать имена. Имя - это не просто идентификатор, а смысловое выжение сущности. При рассмотрении в такой плоскости проблема выглядит иначе: если мы можем понять и передать смысл, то есть шанс воспользоваться естественным ключом, в противном случае неизбежно придется использовать суррогатный ключ.
GaryaПоэтому я являюсь сторонником суррогатных ключей. Пусть пользователь изменяет какие угодно реквизиты. Пока СК остается неизменным, это подразумевает оперирование одним и тем же объектом. С ЕК такое не прокатитВозможно, было бы правильным рассмотреть две стороны первичного ключа. С первой стороны, первичный ключ - это уникальная метка. И нет никакой разницы является ли эта метка внутренней или внешней. Со второй стороны, первичный ключ - это элемент взаимосвязи между сущностями. И порой, лишая смысла первичный ключ, мы лишаем смысла и связи, в которых принимает участие данная сущность. Информация в системе становится недостоверной или система усложняется, поскольку достверность приходится обеспечивать дополнительными средствами.
GaryaЯ уже не говорю о том, что населенный пункт с названием "Москва" в мире далеко не один. Для того, чтобы обозначить ОДНОЗНАЧНО, какой именно имеется в виду, нужно к наименованию прикрутить страну, в которой он находится, вид населенного пункра (поселок городского типа, деревня, аул, кишлак, мегаполис...), географические координаты...
Вполне достаточно координат.
GaryaА через некоторое время выяснится, что нужно еще уточнять, о координатах в системе какой именно планеты идет речь. ВСЕ эти проблемы решаются одним легким движением - введением суррогатного ключа
Если на этапе проектирования нет представления о том, для какого уровня создается система, то здесь никакой суррогатный ключ не спасет...
Кроме того, суррогатный ключ не столько решает проблемы, сколько создает их. Можно, например, пользуясь суррогатным ключем завести 100 раз один и тот же город? Можно. Можно завести два разных города по одним и тем же координатам? Можно. Так чем же помогает суррогатный ключ?
GaryaНо я не настаиваю на своем мнении. Подчеркиваю, это вопрос ФИЛОСОФСКИЙ, а у философских вопросов однозначных ответов никогда не существовало... :)Философия бывает разной...

GaryaВсе меняется... (не помню, кто сказал). Если бы я жил НЕ в России, где все меняется в режиме быстрой перемотки, то, может быть, мое мнение по этому вопросы было менее категоричнымНе очень понятна ссылка на Россию. Древние восточные философы говорили: “Все – есть перемены”. Но как перемены связаны с темой?
GaryaВ свое время мне пришлось решать такую проблему. Изменились НАШИ банковские реквизиты (я уже не говорю о чужих). Нужно сделать так, чтобы старые документы распечатывались со старыми реквизитами, а новые - с новымиИ в чем проблема? По всей видимости в ошибке проектирования. Но эта ошибка легко поправима: надо добавить к таблице поле (ALTER TABLE ADD...), где у старой записи сохранить ссылку на новую запись. Обе записи стали полноправны, для старых документов будет актуальна старая запись, для новых – новая.
GaryaКогда кто-то из сотрудников меняет фамилию или имя, то меня, как "асунизатора", вообще не должно волнововать, по какой причине это произошло. Вышел ли кто-то замуж, или ему опостылело имя "Канализация", которое родители дали, посчитав, что оно красиво звучит (кстати, вполне реальный случай). Для организации, где я работаю, важно, что это один и тот же человек. ПОЧЕМУ мы считаем Настью и Канализацию одним и тем же человеком - это не должно интересовать информационную систему. Эта наша, человеческая область. Если мы посчитаем, что это разные сущности, мы введем их дважды, даже если у них одинаковый номер паспорта. Может быть, мы ХОТИМ видеть одного и того же человека, как двух разных. Это не КИСкино дело! Имхо, конечноС чего Вы решили, что любые атрибуты могут выступать в качестве первичного ключа? Для однозначной идентификации сотрудника организации существует “Табельный номер”. Наверное, надо было познакомиться с предметной областью более глубоко, прежде, чем браться за автоматизацию.
Garya ASUС первой стороны, первичный ключ - это уникальная метка. И нет никакой разницы является ли эта метка внутренней или внешней. Со второй стороны, первичный ключ - это элемент взаимосвязи между сущностями. И порой, лишая смысла первичный ключ, мы лишаем смысла и связи, в которых принимает участие данная сущностьОчень правильные слова! Если мы используем СК, то мы вольны придавать смысл сущности тот, который пожелаем. Когда мы используем ЕК, то у нас уже нет такой свободыН-да... А как же быть с предметной областью? В ней уже дан смысл каждой сущности, в противном случае, этих сущностей просто бы не существовало. С таким подходом к проектированию, придется и предметную область свою придумывать и ее... пользователей.
GaryaЕсть искусствено притянутые за уши ограничения, который, возможно, оправдываются в большинстве ситуаций, но достаточно одной нестандартной ситуации, чтобы оказаться в полному тупике, выяснив, что ЕК совскем не такой уж "естественный", как казалось раньшеМожно пример.
Garya ASUВполне достаточно координат
Увы, не достаточно. Один введет координаты мавзолея Ленина на Красной площади, другой - геометрического центра Москвы (который по мере ее застройки постоянно перемещается)Координаты в терминах долготы и широты образуют уникальное значение для любого предмета на поверхности Земли. Если предметная область требует еще и вертикальной координаты, то ее надо ввести на этапе проектирования.
GaryaИ они окажутся разными. А для ключа это недопустимоНе выдумывайте, пожалуйста.
GaryaКроме того, использование координат с точки зрения соответствия практическим манипулированием информацией НЕЕСТЕСТВЕННО . Эту информацию пользователю-колотильщику по клавиатуре НЕГДЕ ВЗЯТЬ. Конечно, можно заставить вместо наименований населенных пунктов вводить коды ОКАТО. Но пока они научатся в них ориентироваться... И потом, для меня был как гром среди ясного неба, когда я узнал, что для целых регионов в России с некоторого времени коды ОКАТО изменились
И что страшного произошло? Изменились, ну, и что? Два населенных пункта стали иметь один и тот же код?
Garya ASUЕсли на этапе проектирования нет представления о том, для какого уровня создается система, то здесь никакой суррогатный ключ не спасет...Вопрос спорный, определяется степенью предсказуемости изменений. Нас интересует НАСЕЛЕННЫЙ ПУНКТ , в котором находится контрагент, и АРЕАЛ, где он находится. Под словом "АРЕАЛ" можно понимать вещи совершенно разные для разных видов анализа. И заранее трудно сказать, что под ним будет подразумеватьсяНаверное, в этом и проблема - не изученность предметной области. В таком случае невозможно отвечать за достоверность информации в базе данных.
GaryaЕсли мы обозначим населенный пункт ТОЛЬКО наименованием, то попадем в тупик, когда узнаем, что Москва есть еще и в Америке, с поставщиком из которой мы стали работать недавно. Если мы в качестве уточняющей информации добавим понятие "Страна", то попадем в тупик, узнав, что в России Москва далеко не единственная. Какой выход? Создается суррогатный ключ и поле "примечание". Вот в примечании мы и напишем, чем эта Москва отличается от двух остальных, если нам не хватает базовых полей для описания отличий этих сущностей. И наша система будет нормально фунциклировать с треми Москвами, и выдаст корректно информацию о деятельности по странам, когда мы ее запросим. И даже по регионам России, если она естьВы говорите о проблеме изучения предметной области? Или о том, как свои проблемы перекладывать на плечи пользователей? GaryaДалее, встает традиционный ворпос о длине ключа. Для того, чтобы ЕСТЕСТВЕННЫЙ ключ сделать гарантированно уникально описывающим сущность, в идеале в него приходится включать практически все поля-атрибуты сущности (разве не так?). О какой эффективности тут можно говорить, о какой нормализации?Хм... Вы что-то знаете о нормализации? Сомневаюсь. Нормализация не имеет отношения к вопросу выбора ключа по той простой причине, что нормализация проводится после того, как ключ выбран (определены функциональные зависимости, найдены детерминанты и выбран ключи из потенциальных ключей).
Вопрос о длине ключа является надуманным. Естественный ключ может быть больше или меньше суррогатного ключа. Например, для стран и валют есть принятые международным сообществом аббревиатуры размером в 2-3 символа. Суррогатный ключ будет иметь размер принятый в данной СУБД (4-8 байт).
В задачи ключа не входит экономить место, его задача однозначно идентифицировать кортеж.
Garya авторМожно, например, пользуясь суррогатным ключем завести 100 раз один и тот же город? Можно. Можно завести два разных города по одним и тем же координатам? Можно. Так чем же помогает суррогатный ключ?
Имхо, не следует смешивать логику проверки на допустимость операции с логикой отношения между объектамиЧего? Простите, но что такое “допустимость операций”?
GaryaЕсли действительно существуют 100 городо в с одним и тем же наименованиемПростите, но я говорил не о множестве городов с одним именем, а о том, что один и тот же город заводят в БД много раз. Разницу понимаете?
GaryaА что делать, когда ты использовал поле "Name" в качестве ЕК, а через 2 года эксплуатации выяснилось, что нужно ввести записи с повторяющимся значением поля "Name"?Если я использую в качестве ключа набор атрибутов не обеспечивающий уникальности, то мне придется признать, что я напрасно ем хлеб проектировщика БД. Но за всю мою жизнь, ни разу такого не случалось (проектированием БД я занимаюсь порядка 20 лет).
GaryaКроме того, ЕК сам по себе не спасает от дублирования информации (знаю это по богатому опыту)Он так же не спасает ни от лени, ни от глупости, ни от головной боли. А разве должен?

GaryaПо моим подсчетам форма счета-фактуры изменялась на протяжении одного года 5 раз. И это было в РоссииРанее, я уже провел мысль о том, что «все – есть перемены». Вы эту мысль старательно подтвердили. Зачем? Или Вы считаете, что перемены происходят только в России?
GaryaИмеется движение, связанное с этими записями. И это движение ссылается на разные записиЧто ж, давайте по порядку. По всей видимости, рассматривается «движение» по банковским счетам. Для начала должен заметить, что любая организация может иметь произвольно много счетов в одном или разных банках. Сами процедуры открытия или закрытия счетов не являются чем-то из ряда вон выходящим. Следовательно, вести параллельно несколько счетов в финансовой системе должно быть обычным делом, в не зависимости от того, является ли какой-то счет «старым», а какой-то «новым».
Добавив новое поле, можно установить логическую связь между «старым» и новым «счетом». При этом сумма со «старого» счета переводится на «новый» счет, и старый счет помечается, как неиспользуемый с такой-то даты. Аналогичная ситуация возможна во многих других ситуациях, например, при инвентаризации.
Какое же отношение к этой ситуации имеет тип ключа?
GaryaА я не знал А теперь увольте этого сотрудника и через пару месяцев снова примите обратно на работу под новым табельным номером (только не говорите, что отдел кадров где-то принимаемому на работу сотруднику присваивает прежний табельный номер)Хм... Скажите, а Ваши инспектора отдела кадров хорошо знакомы с правилами приема на работу? Смею думать, что нет. Дело в том, что информация о каждом сотруднике должна хранится на предприятии 75 лет. Следовательно, сотрудник должен однозначно идентифицироваться в течение всего этого времени. Именно для этого ему присваивается табельный номер. И при повторном приеме на работу инспектор отдела кадров обязан повторно присвоить сотруднику старый табельный номер.
GaryaА после объясните фискальщикам, почему НДФЛ нарастающим итогом по одному и тому же человеку некорректно рассчитался...[ /quot]Вот пусть несколько раз взыщут НДФЛ с нерадивого инспектора ОК, и все встанет на свои места. Видите, как полезны ЕК...
[qout=Garya]Ну есть сущность "организация". Вне зависимости от существования или НЕ существования ИНН, КПП, кодов ВЭД, ОКПО, ОКОНХ и многих других. Если наши законодатели придумают новый 20-значный или 200-значный код, в котором объединят все эти коды, то что изменится в предметной области, кроме того, что для данной сущности появился новый атрибут, которого раньше не было? Какие кардинальные изменения произошли в отношениях между сущностями?И что же из этого следует? Только то, что не все сущности предметной области имеют естественный ключ? Да, конечно. Но почему надо применять суррогатный ключ, там, где есть естественный. Или может быть из-за отсутствия ЕК в одной сущности, не следует исследовать остальные (а, значит, и не исследовать предметную область)?
GaryaА не могли бы Вы указать конкретные координаты долготы и широты объекта "Москва"? Интересно, сколько времени Вы будете искать ответ на этот вопрос. И еще интереснее, что любые координаты - это положение ТОЧКИ. А Москва - это далеко не точка (это я и пытался объяснить). Из одного конца в другой можно ехать аж полдня. И если два юзера укажут координаты двух РАЗНЫХ точек, которые хоть и находятся в пределах Москвы, но образуют РАЗНЫЕ значения первичного ключаДля начала, давайте научимся не сваливать все в одну кучу. Подобный подход – «смертный» приговор для проектировщика или... для его пользователей.
Итак, первое. Вы, как я понял, не отрицаете, что широта и долгота однозначно идентифицируют положение любого предмета на поверхности Земли. Второе, в каждом городе есть общепринятая точка, относительно которой считаются все относительные расстояния. Как правило, это точка возле центрального почтамта или прямо в нем. Поэтому выдумывать эту точку тоже не надо, достаточно ее знать. И, наконец, третье. Если понятия широты и долготы не входят в предметную область, то, скорее всего, что для них есть адекватная замена, например, административные или почтовые коды, принятые аббревиатуры и пр.
GaryaВообще-то, если в первичный ключ включить вообще все поля вообще всех таблиц, то можно считать, что они уже автоматом нормализованыНу, вот... очередные «откровения», то ЕК нормализацию нарушает, то предлагают в ЕК все атрибуты включить... Хотелось бы заметить, что проектировщик БД не создает предметную область, но моделирует ее. И чем адекватнее модель своему оригиналу, тем она качественнее. Ферштейн? Исходя из сказанного, замечу, что вопрос о том включать или не включать атрибуты в ключ не может быть решен произвольным образом (дорого платить придется за подобное «решение»). Необходимо исследовать атрибуты каждой сущности и зависимости между сущностями, прежде чем принимать решение о том, каким будет ключ.
GaryaТеоретически это так, и спорить я тут не стану. Вопрос только в том, кому нужна такая нормализация. Нормализируют таблицы обычно с определенными целями, которых в данном случае я не наблюдаюНормализация всегда выполняется с одной единственной целью: избежать аномалий. Что значит «такая» и «не такая» нормализации для меня осталось загадкой...
GaryaКроме теории есть еще практика...Если теория противоречит практике, то возможно одно из трех:
1. Неверна теория;
2. Неверно истолкована практика (ошибка в измерениях, например);
3. Практик просто не знает теории.
Выбирайте то, что Вам ближе.
GaryaЕсли мы, например, не хотим допустить появления в БД двух городов с одинаковым именем, то для этого совсем не обязательно имя города превращать в первичный ключ. Это можно сделать множеством иных способов. Совершенно верно. Сказанное означает только то, что название города должно быть признано ключем-кандидатом.
GaryaНеужели ваши пользователи никогда не делают опечаток?Почему же, наверное, делают. Но из этого никоим образом не следует то, что я использую в качестве ключа набор атрибутов не обеспечивающий уникальности.

Уважаемый Garya, постарайтесь понять меня правильно. Ваши реплики свидетельствуют о том, что Вы
- недостаточно хорошо знаете теорию баз данных;
- поверхностно изучаете предметную область и, как следствие, делаете поспешные выводы о сущностях предметной области и их атрибутике;
- недостаточно глубоко просчитываете результаты своих решений.
Думаю, что обсуждать проблему выбора ключей дальше, не имеет смысла, поскольку мы говорим не о ключах, а о «белых пятнах» в Вашем сознании.

Сергей Васкецов ASUне отрицаете, что широта и долгота однозначно идентифицируют положение любого предмета на поверхности Земли
Нет, они могут меняться, хотя бы вследствие движения литосферных плит.Читаем еще раз и внимательно. Широта и долгота однозначно идентифицируют положение любого предмета на поверхности Земли. Широта и долгота не меняются при сдвигах земной коры.

Garya ASUЧто ж, давайте по порядку. По всей видимости, рассматривается «движение» по банковским счетам. Для начала должен заметить, что любая организация может иметь произвольно много счетов в одном или разных банках. Сами процедуры открытия или закрытия счетов не являются чем-то из ряда вон выходящим.
Да, этот пример немного не из той оперы. Под него подходят ЕК. Я же имел в виду немного другую ситуацию. Реально наш банк сменил наименование (а еще он менял корсчет и БИК, но это было позже). Или другой случай. Под оборотами подразумевается движение дебиторской/кредиторской задолженности, а под сменившимися атрибутами - наименование одного из контрагентов (или ИНН, поскольку ДРУГАЯ организация стала правопреемником старой, но с точки зрения взаиморасчетов для нас это одна и та же организация). Необходимо, чтобы система "помнила" и старое наименование, и новое. И чтобы обороты, связанные с организациями с РАЗНЫМИ наименованиями воспринимала как взаиморасчеты с одним и тем же контрагентом, а не с разными. А в документах распечатывалось то наименование, которое было действительно на момент выписки документа. В 1С такие реквизиты называются "периодическими"Дело не в 1С. Задача, о которой Вы говорите, является достаточно распространенной и один из вариантов решения я уже приводил (прочитайте еще раз про ALTER TABLE... в моих предыдущих сообщениях).
Должен заметить, что при тщательном разборе любой ситуации с СК можно показать, что они в лучшем случае неуместны, в худшем случае вредны. Разобранный нами пример просто подтверждение этого положения.

ASCRUS ASUХм... Скажите, а Ваши инспектора отдела кадров хорошо знакомы с правилами приема на работу? Смею думать, что нет. Дело в том, что информация о каждом сотруднике должна хранится на предприятии 75 лет. Следовательно, сотрудник должен однозначно идентифицироваться в течение всего этого времени. Именно для этого ему присваивается табельный номер. И при повторном приеме на работу инспектор отдела кадров обязан повторно присвоить сотруднику старый табельный номер.
Гм, как должно быть и как есть - это абсолютно разные вещи. Вы высказываетесь как должно быть, но пишем то мы программы по тому, что есть. И например, цитированная фраза противоречит тому, что есть в России. Я, как разработчик зп могу очень много страниц исписать того, что написано в ТК и НК РФ и как на самом деле работает у клиентов. И никто не вправе им навязать делать так, как "завещало" государство, они клиенты и это их личное дело, любой тиражный продукт должен поддерживать обе модели работы "Как должно быть" и "Как есть". Если он не будет соотвествовать этому условию, то он просто не будет востребованМне бы не хотелось повторять расхожих фраз об автоматизации бардака. Если Вам нравится делать и переделывать, если у Вас фактически не выбора (либо получить заказ, либо умереть с голода), если Вам безразлично то, что Вы делаете, то... я не вижу темы для обсуждения. Но, если Вы хотите получить красивое и надежное решение, то... перестаньте анализировать требования заказчика и начните осмысливать задачу вне различных точек зрения на нее, то есть, объективно. Даже если Вам удастся собрать воедино точки зрения всех потенциальных пользователей, всех работающих на предприятии, Вы не получите адекватной модели. Сумма частностей не равна целому.
ASCRUSНасчет табельных номеров у меня вопрос решен просто - в течении года табельный номер забронирован за сотрудником и в случае его увольнения он остается висеть до конца года. Если сотрудник обратно принят на работу, то ему разрешается "вернуть" его старый номер, но разрешается и сделать новый. В моей системе сотрудники вынесены в отдельную таблицу от лицевых счетов и связаны через СК, поэтому особой разницы нет, у кого какие аттрибуты были изменены во времени, сколько на сотрудника открыто лицевых счетов и нет проблем с обьединением начислений по множеству лицевых счетов сотрудника. И то - бронь табельного номера в течении года - это дань уважения ТК и обеспечение непротиворечивости годовых отчетов. Если найдется клиент, которому это не понравится, мне недолго будет это вынести в конфигурационную настройку и включать/отключать обеспечение его уникальности (опять же благодаря СК схема БД не нарушится)Это паллиативное решение, так как Ваша схема не дает пользователям возможности однозначно идентифицировать сотрудника.
ASCRUSP.S. Напоследок в эту тему хочу сказать, что лично я и множество коллег, которые еще много лет назад участвовали в подобных спорах, пришли к компромиссному выводу: в качестве первичного ключа использовать СК, в кач-ве уникального ЕК. Тогда первичный ключ однозначно идентифицирует запись и ни от чего не зависит, а уникальный обеспечивает целостность данных на уровне бизнес-логики и может иметь различные виды уникальностиУникальность не имеет “различных видов”.
Использование СК в качестве первичного ключа может привести к недостоверности информации в БД. Посмотрите для примера статью "Ключ или отмычка"
ASCRUSНапример в вышеприведенном мною примере уникальность табельного номера обеспечивается в течении года, однако при необходимости я всегда могу изменить ее условия на полную уникальность в пределах таблицы, в течении полгода и т.д. Все это прекрасно реализуется через UNIQUE CONSTRAINTS или же обычные триггера. По моему прекрасный выход, без лишних напрягов СУБД и риска нарваться на неприятные ситуации с ЕКПроблема в том, что Вы пытаетесь избежать неприятностей, а не следовать логике предметной области. “Тот, кто ищет пути отступления до начала битвы, не достоин быть победителем” (Марк Аврелий). Если Вы добьетесь того, чтобы “табельный номер” был уникален сам по себе, Вы не только упростите свое решение, но убедитесь, насколько проще решаются задачи пользователей. Пользователи не обязаны быть системными аналитиками, но разработчик – обязан.
ASCRUSЕще P.S. Кстати в предыдущих "баталиях" основным аргументом использования ЕК была репликация. Сейчас смотрю этот аргумент в связи с прогрессом механизмов репликаций у всех СУБД не упомянается как главныйНаверное, надо исходить из смыслового содержания ЕК. В любой ситуации, когда ключ используется во вне БД важен его смысл. Репликация – это частный случай использования ключа вне конкретной БД. А разговоры о “прогрессе механизмов репликации” в данном контексте не имеют смысла. СК функционален только в внутри одной БД. При переносе информации в другую БД, СК становится вреден, поскольку
а) утрачивается идентификация;
б) обрываются связи на основе внешних ключей;
ЕК в отличие от СК имеет смысл не в БД, а в предметной области. Поэтому в любом количестве БД одна и та же сущность будет иметь один и тот же идентификатор.

AlTk ASU
И что же из этого следует? Только то, что не все сущности предметной области имеют естественный ключ? Да, конечно
а вот здесь я не совсем согласен с Вашим утверждением. может лучше было сказать так: "на данном этапе развития наших знаний и мощности вычислительной технике не для всех сущностей предметной области возможно использование естественных ключей"?Дело не в мощностях и не в уровне наших знаний. Когда мы говорим о предметной области, то понимаем, что это модель некоторой части окружающего нас мира. И как любой другой модели, предметной области свойственны ограничения. Безусловно, существует масса признаков, по совкупности которых можно однозначно идентифицировать любой болт из нескольких миллионов. Но в предметной области эти признаки отсутствуют (остаются за "кадром") и болты не отличаются друг от друга. Аналогично и с другими сущностями. Безусловно, два человека (даже близнеца) имеют индивидуальные признаки. Но при приеме на работу и при выполнении работы они не важны, важны другие признаки: имя, фамилия, отчество, квалификация, образование, возраст, пол и пр. Но они не образуют уникальных комбинаций. Расширять предметную область (модель) не всегда правильно (зачем исследовать болты или радужную оболочку глаза?).
Но вот если бы мы проектировали мир... :)

ASCRUS авторМне бы не хотелось повторять расхожих фраз об автоматизации бардака. Если Вам нравится делать и переделывать, если у Вас фактически не выбора (либо получить заказ, либо умереть с голода), если Вам безразлично то, что Вы делаете, то... я не вижу темы для обсуждения. Но, если Вы хотите получить красивое и надежное решение, то... перестаньте анализировать требования заказчика и начните осмысливать задачу вне различных точек зрения на нее, то есть, объективно. Даже если Вам удастся собрать воедино точки зрения всех потенциальных пользователей, всех работающих на предприятии, Вы не получите адекватной модели. Сумма частностей не равна целому.
На Ваше высказывание возникает закономерный вопрос - Вы вообще занимались разработкой тиражного ПО ? Наверное ездите по всем клиентам и проникновенно рассказываете о красивом и надежном решении (правда противоречащим их правилам работы) ? Давайте все таки говорить о практике, а не теории и без высоких словА я и говорю о практике. Моя практика не противоречит теории, по всей видимости, в отличие от Вашей. Мы действительно в начале работы с любым предприятием проводим семинар, где рассматриваем "системы управления предприятием". Делается это строго последовательно. Сначала мы рассказываем о том, что такое "система", потом - что такое "управление", далее рассказываем о предприятии. Для нас важно донести до руководства смысл каждого слова. Если смысл слов воспринят, то мы продолжаем говорить о "системе управления", о "предприятии, как системе", и, наконец, об управлении предприятием. Если есть понимание этих терминов, то только тогда мы определяем, что такое "система управления предприятием". Мы не расспрашиваем клиентов о том, как они делают то или иное, но мы позволяем клиентам увидеть истоки их проблем и понять пути их решения. И поверьте, еще не было случая, когда бы клиенты выразили сомнения или неудовлетворение от общения с нами. И не было случая, когда бы теория не подтвердилась практикой.

НепонятливыйМожно есче добавить про табельные номера:
1.Какие номера должниы присваиваться практикантам, сдельщикам, повременщикам. И должны-ли присваивваться вообще?Да, табельные номера должны присваиваться любому сотруднику, внезависимости от условий контракта (договора), продолжительности работы на предприятии и пр.
Непонятливый2. Организация насчитывает общую численность свыше 300 тыс человек, текучесть все-ж кой-какая есть, сколько символов должен содержать табельный номер, и в чем его отличие от сурогатного ключа, длиной 10 символов если рассматривать законадательный срок хранения информации в 75 лет?Табельный номер не является суррогатым ключом (по определению). Тип этого атрибута, как правило целочисленный (32-х разрядное [беззнакое] число). Этого размера хватит для того, чтобы хранить информацию о 4 294 967 296 сотрудниках (половина населения земного шара).