Не вижу проблемы.
Для каждого клиента создаем уникальный идентификатор (GUID например).
В отдельной таблице для каждого идентификатора клиента заполняем всю его историю паспортов, фамилий и полов.
Там где я работаю (тоже крупная фин организация), клиенты идентифицируются по документу (обычно паспорт, но может быть и что-нибудь другое).
Если документ сменился — то клиент при следующем к нам обращении приносит новый документ и документ подтверждающий смену (нужен не всегда, для паспорта достаточно страницы с предыдущими паспортами). Это записывается в системе и теперь информацию по клиенту можно искать как по старому так и по новому документу, а выполнять операции только по новому.
И вообще, это — проблема в первую очередь юристов, а не программистов.
только на touch-устройствах они мало чем отличаются от MessageBox-ов. Т.к. все равно надо куда-нибудь нажать чтобы сообщение исчезло, просто поводить мышкой не получится.
Разве что (серия + номер) паспорта. Поскольку эти данные однозначно идентифицируют личность в нашей стране.
Паспорт меняется в течении жизни, фамилии и имена тоже, но личность при этом остается той же самой личностью, и должна идентифицироваться в базе однозначно.
Я не вижу ни одного не суррогатного варианта для ключа в таблице Clients
CASCADE UPDATE мы можем сделать в рамках одной базы.
А если нам потребуется идентифицировать пользователя в других базах? Плюс, например, прямого доступа к этим базам нет, а только через web-сервис.
Сразу возникает желание писать так:
MinimumAttribute<T: IComparable> = class(BaseValidationAttribute)
public
constructor Create(MinimumValue: T; const FailureMessage: string);
…
[Minimum(18, 'Must be at least 18 years old')]
property Age: Integer read FAge write FAge;
как вариант использовать generic:
class TreeNodeBase where TEntity: LinqEntityBase
…
class Product: LinqEntityBase
…
class ProductTreeNode: TreeNodeBase
Есть такое.
Для каждой платформы свой View, часто бывает что и свой Controller.
Но если приходится переписывать Model — значит у вас плохо разделена логика и представление.
У Вас "/Generate/Entropy/" = базовый абстрактный класс.
«MonteCarlo.php» = конкретная реализация.
Только в ООП сигнатуры методов задаются жестко, а у Вас только в комментариях.
«Code» = ServiceLocator. Вызывает конкретный «драйвер» (реализацию класса) по его «пространству имен» (абстрактному классу). + AOP-процессор. Навешивает на вызовы методов логирование, кеширование и т.д.
Но смена фамилии или паспорта — обычное событие и происходит в жизни почти каждого человека.
Для каждого клиента создаем уникальный идентификатор (GUID например).
В отдельной таблице для каждого идентификатора клиента заполняем всю его историю паспортов, фамилий и полов.
Если документ сменился — то клиент при следующем к нам обращении приносит новый документ и документ подтверждающий смену (нужен не всегда, для паспорта достаточно страницы с предыдущими паспортами). Это записывается в системе и теперь информацию по клиенту можно искать как по старому так и по новому документу, а выполнять операции только по новому.
И вообще, это — проблема в первую очередь юристов, а не программистов.
Есть варианты без него?
Если только в варианте, что на Win работают все функции, а в остальных не совсем все.
Паспорт меняется в течении жизни, фамилии и имена тоже, но личность при этом остается той же самой личностью, и должна идентифицироваться в базе однозначно.
Я не вижу ни одного не суррогатного варианта для ключа в таблице Clients
А если нам потребуется идентифицировать пользователя в других базах? Плюс, например, прямого доступа к этим базам нет, а только через web-сервис.
MinimumAttribute<T: IComparable> = class(BaseValidationAttribute)
public
constructor Create(MinimumValue: T; const FailureMessage: string);
…
[Minimum(18, 'Must be at least 18 years old')]
property Age: Integer read FAge write FAge;
но как я понимаю — такое в Delphi не получится?
…
class ProductTreeNode: TreeNodeBase[Product]
class TreeNodeBase where TEntity: LinqEntityBase
…
class Product: LinqEntityBase
…
class ProductTreeNode: TreeNodeBase
Для каждой платформы свой View, часто бывает что и свой Controller.
Но если приходится переписывать Model — значит у вас плохо разделена логика и представление.
У Вас "/Generate/Entropy/" = базовый абстрактный класс.
«MonteCarlo.php» = конкретная реализация.
Только в ООП сигнатуры методов задаются жестко, а у Вас только в комментариях.
«Code» = ServiceLocator. Вызывает конкретный «драйвер» (реализацию класса) по его «пространству имен» (абстрактному классу). + AOP-процессор. Навешивает на вызовы методов логирование, кеширование и т.д.