Имеется система управления пользователями. Заказчик хочет предусмотреть возможность создания пустого договора, т.е. договора, который имеет только пару-тройку заполненных аттрибутов, таких как номер договора (генерируется БД) пароль и логин. Остальные аттрибуты (ФИО, паспорт и пр.) будут заполнены в договоре вручную менеджером, когда он приедет лично к пользователю и позднее внесены в базу.
Я так понимаю, что есть два способа - создавать фиктивного пользователя (например автоматически вбивать в поля что-то типа ФиктивныйПользователь1) или разрешать nullable поля с добавлением аттрибута "Пустой".
Может есть какие-то стандартные методы решения такой задачи ?

gardenman
Дефолтные значения задавать пробовали?

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

softwarer
Я не знаю случая, при котором автора подобной идеи не следовало бы убить во младенчестве.

спасибо, понятно

softwarer
В принципе можно. Если лучше, то надо сделать check constraints вида "Статус = фиктивный or field is not null" либо зашить подобные проверки в хранимки. На что нужно обратить внимание - незаполненный договор ни в коем случае не должен пойти "в работу".
...
Кроме этого, стоит рассмотреть вариант, при котором полувведенный договор будет лежать в отдельной табличке - типа ФиктивныеДоговора - или даже в универсальном буфере, скажем xml-ном. Суть в том, что "сохранить черновик, ни фига не проверяя, а потом прийти и продолжить работу" - довольно типичная задача, и выделив такой буфер, мы одновременно даем возможность делать так в любом документе и надежно уберегаем "нормальные проверенные данные" от смешивания с "пока мусором".

тут видите какая хитрость - на самом деле договор не совсем "мусор".
"Пустой" договор (на подключение к сети) уже будет иметь такие параметры как IP-адреса, имя компьютера и логин. Все эти параметры являются уникальными для системы. Т.е. нельзя написать в договоре IP = 192.168.1.32, и отложить на потом, так как иначе этот адрес случайно может быть присвоен кому-то еще (это-же касается имени компьютера и логина). Кроме того, ID договора является Identity-полем и соответственно тоже должен быть сгенерирован сразу и навсегда.
Так что к сожалению, отдельная табличка не подойдет. Придеться видимо null-столбцы разрешать. Просто это сплошная головная боль - ведь на самом деле из-за нормализации, договор не одна таблица, а несколько.
Например Договор имеет ссылку на Клиента, которая в пустом договоре должна будет быть null.
Таблица с местом подключения (улица, дом, квартира ...) сама имеет ссылку на таблицу с акаунтами, а раз такой информации нету, то и записи нету, а ведь например запрос, который у меня выводит список аккаунтов джойнится на нее, т.е. запись с неполным аккаунтом в резалтсет не попадет, а она там нужна, т.к. там IP-адреса, значит надо запрос (и вообще много других запросо) изменять с учетом этого.
Кроме того, надо как-то целостность гарантировать между всеми этими таблицами, Ужос вообщем :(
Я потому и думал, что может таблицы как-то фиктивными данными забивать ...

softwarer
Не совсем, конечно, хотя именно такие параметры удивляют. Вот не очень представляю, зачем заранее выделять адрес.

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

softwarer
Вот это как раз странно. "Договор неизвестно с кем" - сильный ход с точки зрения бизнеса. Я пойму, если останутся незаполненными второстепенные реквизиты клиента - адрес итп - но информации должно быть достаточно для того, чтобы я через полгода пришел к вам и сказал "я Иванов, где мой договор?"

вообще конечно логично :) Пожалуй действительно ФИО следует сделать обязательным для пустого договора, ведь его вполне можно узнать по телефону. Тогда у сущности Клиент будет только один null-параметр - его паспорт.

softwarer
Не, не ужас. Поверьте: "записи нет там, где она нужна" - на порядок меньшее зло, нежели "запись вылезла там, где она не нужна". Поэтому расставить в нужных местах outer joins - гораздо лучше, нежели отфильтровывать "почти всюду" фиктивные значения.

просто тут 2 проблемы, первая - необходимо всегда помнить, что некоторые данные могут быть null, и вторая - как-то гарантировать целостность, т.е. например раз договор имеет статус "Пустой", то паспорт у клиента должен быть null, и запись в таблице места подключения должна отсутствовать.

ModelR
однако обычно это оставляют прикладному коду чтобы не размазывать логику статусов по разным частям системы.
Т.е в базе остается чисто nullable Клиент.

логика ограничений-то так и так будет дублироваться - и в domain-model, и в БД. Иначе вдруг какой-нибудь сильно умный админ руками в БД полезет чего-нибудь подправить, или кто-то напишет еще одного клиента к БД.

shelsoft
4) Определяется временной промежуток резерва, зарезервированные договора не учитываются в качестве критерия эффективности работы манагера
5) Необходимо решить вопрос с нумерацией договором (можно ли согласно вашим правилам вести нумерацию с разрывами, или не использованные номера надо возвращать)

пустой договор обязательно получает номер, ну а временной резерв к счастью не ограничен. Хоть через полгода заполнят до конца

Сергей Васкецов
Налицо кривой БП. Может IP-адрес у клиента смениться? Тут все то же самое. Как и в случаем физического адреса оконечного оборудования клиента. По сути - адрес не является параметром договора и может быть утвержден, например, доп. соглашением.

softwarer
Я таки сомневаюсь в разумности такого подхода. Во-первых, я вообще не понимаю, зачем выделять адреса и почему бы не использовать dhcp. Во-вторых, я уверен в том, что клиент через полгода не найдет эту бумажку. Ну а в-третьих, я не очень понимаю, кто мешает послать ему емейл с новыми реквизитами.

ну что я могу сказать - не я придумывал бизнес-правила. Насколько знаю, ситуация такая - все подключенные к сети дома имеют выделенные им диапазоны IP-адресов. Так что каждый пользователь может иметь адрес только из тех диапазонов, которые закреплены за домом. Адрес внутри сети, и внешний IP-адрес нужны для того, что-бы настроить подключение к локальной сети и Интернету (там есть авторизатор, который требует эти данные, так что динамически адреса вроде как не выделить, хотя я вообще-то не специалист по сетям :)
Вот вы приехали к человеку, дали памятку, начинаете настраивать и обнаруживаете что указанный адрес уже занят. Ну можно наверно позвонить в офис, назначить новый адрес и исправить памятку, просто нафига :) Если адрес сразу зарезервирован, проблем имхо куда меньше.
А так да, IP не относиться к договору как таковому и может в дальнейшем меняться. Он поэтому и написан на памятке, а не в договоре

softwarer
И в чем проблема?

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

softwarer
Нафига?

а как вы собираетесь обеспечивать целостность данных между двумя таблицами ? К примеру в данном случае, требуется обеспечить что-бы поле "Пустой" было null только в том случае, если запись об адресе на данный контракт в другой таблице отсутствует. Т.е. например нельзя взять и просто "вручную" поставить true в таблице с контрактами. Как вы это будете делать без триггера ?

softwarer
Хм. Времени, которого мы потратили на этот разговор, хватило бы на наиболее трудоемкую реализацию нескольких таких проверок :)

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