Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Так вот, собственно проблема. До какой степени оправданно (меня интересует мнение публики по опыту успешного внедрения своих проектов) идти навстречу заказчикам в такой ситуации? Вот два конкретных случая.
Ну, по идее это вообще замечательно! Чем больше фидбека, тем больше поводов построить адекватную модель, которая учитывает реальные абстракции, а не только свойственные ровно одной ситуации.
SM>В одном заказчик говорит: "В той табличке, которую мы зашлем в вашу программу, будут не только корректные данные, но и некорректные. Если для какой-то из записей вы не найдете соответствующую ей запись в своей мастер-таблице, просто пропускайте ее." В таком случае, даже если у них самих в таблице полный ералаш, мы радостно скушаем все то, что не сможем точно определить как некорректные данные. Сначала я думал отменять все импортирование при обнаружении некорректности, сейчас предлагается делать вид, что ничего не было. Вариантом было бы потребовать от заказчика сливать нам не все подряд, а фильтровать на их стороне, но тогда они говорят "Мы хотим просто слать вам подряд все из нашей собственной таблички, и не напрягать мозги какой-то фильтрацией". И как же лучше поступить — пойти навстречу или стоять на своем?
Я может чего-то непонимаю, но такие вещи, как интеграция, делаются одним из двух способов:
1. Есть некоторый внутренний АПИ, и для каждого конкретного случая пишется заказная заплатка-плугин, которая и занимается сращиванием данных. Ну и тут уже вопросов не возникает — внешний интерфейс к ней формулируется заказчиком и является частью ТЗ.
2. Есть некоторый стандартный интерфейс взаимодействия, доступный для понужания IT-отделом заказчика. В таком случае как правило пишется PDF страниц на шестьдесят, и на все вопросы типа "а можно мы вместо данных сюда какое-нть г-цо засунем?" отвечается "можно, но в соответствии с PDF". В самом крайнем случае можно позволить некоторую настройку этого интерфейса, типа реакция на неконсистентные данные — игнор/мэйл-ворнинг/роллбэк.

SM>Другой случай. У каждой организации, прописанной в БД, может быть несколько торговых точек. Но может быть и всего одна. В последнем случае заказчик не желает возиться с торговыми точками для данной организации, и говорит "сделайте так, чтобы, если у данной организации нет торговых точек, считается, что есть всего одна". То есть в каждой аналитической процедуре тогда придется рассматривать два варианта: если точки есть, то импортированные данные привязаны к точкам, в противном случае — прямо к организациям. Это притом, что на самом деле данные всегда определяются в точках, а вот если она всего одна, то вместо номера точки указывается NULL. Теряется логика кода, размывается структура БД, и все из-за того, что отделу программистов у заказчика лень написать маленькую формочку для одновременного редактирования данных об организации и ее торговых точках (ну, чтобы не заставлять оператора лазить по разным таблицам, что, собственно, его и раздражает, если точка всего одна). Опять же вопрос — требовать у них привести базу в логичное состояние или соглашаться на такой бред? Есть и еще один вариант, но в данной ситуации он недоступен. Можно было бы при импортировании их данных самостоятельно вводить недостающие точки и привязывать к ним "по умолчанию" данные без номера точки. Но если считать, что такое невозможно, то какую позицию лучше занять, имея альтернативу "или-или"?

Ну, издалека сложно судить. Все зависит от того, разделены ли в вашей программе сущность "организация" и сущность "торговая точка". Если они разные, то, соответственно, тот код, который написан с учетом торговых точек, требует именно торговую точку. Это означает, что надо сконфигурировать как минимум одну торговую точку для работы (а иначе, например, кассовый аппарат будет не к чему привязать, ну или еще там что).

В любом случае, если так оказалось, что предприятия с единственной торговой точкой (она же офис она же склад) существуют в природе достаточно часто, то имеет смысл хотя бы в пользовательском интерфейсе выполнить декомпозицию по границе частоты встречаемости, а не по типу объекта. Т.е. вместо набора диалогов

===== редактируем организацию 1 =====        ===== Торговые точки для организации 1 =====   
Свойство организации 1:[       ]             |Точка 1    [редактировать >>] [удалить >>]|    
Свойство организации 2:[       ]             |Точка 2    [редактировать >>] [удалить >>]|
Свойство организации 3:[       ]             |[добавить точку >>]                       |
[Торговые точки >>]

который требует много лишних действий, сделать вот так:

===== редактируем организацию 1 =====        
Свойство организации 1:[       ]             
Свойство организации 2:[       ]             
Свойство организации 3:[       ]             
Свойство торговой точки 1:[       ]
Свойство торговой точки 2:[       ]
Свойство торговой точки 3:[       ]
[Торговые точки>>]

Пусть даже там показывается тот же диалог 2. Но, во-первых, требуется меньше нажатий на кнопки для ввода основной торговой точки, а во-вторых, теперь придется сделать поддержку "основной" торговой точки для организации, а это улучшит также работу пользователя в тех случаях, когда вторичные точки используются реже. То есть достаточно будет выбрать организацию, а торговая точка подставится сама.
SM>Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось ради этого жертвовать надежностью или внутренней (а она обязательно влияет на внешнюю, видимую!) логичностью продукта.
Нужно помнить, что логика модели не всегда совпадает с логикой пользователя.