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