Привет.

Нужна помощь по ряду вопросов.
Есть программа. Первоначально она была реализована мной на Dataset'ах. В последствии из-за усложняющейся бизнес-логики и чтения(и наконец-то понимания!) Фаулера я переделал ее на объектную модель (Domain Model).
С самого начала проекта добавление и обновление записей производилось в хранимых процедурах: в них производились определенные проверки и непосредственно сохранение всех полей. Таблицы доступны только на SELECT. При переходе на Domain Model я оставил способ сохранения через хранимки, т.к. их было уже большое кол-во и проверки которые они содержат выкидывать нельзя.

Сейчас возможен контракт с крупным предприятием. Одно из требований: реализовать консолидированный сбор данных. Т.е. все данные из отделений попадают в филиал. В филиале их могут изменять и исправления должны попадать обратно в отделения.

Проблемы:
1. Если поднимать репликацию, то способ сохранения через хранимки, в которой обновляются ВСЕ поля, даже которые не изменились, плохой, из-за возникновения большого кол-во коллизий при изменении одной и той же записи. Гораздо грамотнее делать UPDATE только тех полей, которые реально изменит пользователь. Т.е. по любому придется отказываться от хранимок?

2. Вытекает из предыдущего. Если делать UPDATE только измененных полей, то как это реализовать. Способ хранить в каждом классе признак измененности для каждого поля мне не нравится. Слишком много кода добавлять придется. Фаулер предлагает хранить в UnitOfWork копии "чистых" объектов и перед сохранением сравнивать все поля. Читал документацию по Хибернейту, но так и не понял, как она сохраняет поля. Какие еще есть варианты?

3. Ключи в таблицах у меня IDENTITY. Придется от них отказываться и переделывать на GUID'ы или делать составные (например с префиксом номера отделения)? Как проще и выходнее? Хотя и так ясно, что на GUID'ах проще, а вот выгоднее ли?

4. И вообще насчет проверок на SQL сервере, если я отказываюсь от хранимок. Переносить мне проверки в триггеры или все проверки реализовать на клиенте, а SQL сервер использовать только для хранения?

Очень надеюсь на вашу помощь!

Здравствуйте, shev, Вы писали:

S>3. Ключи в таблицах у меня IDENTITY. Придется от них отказываться и переделывать на GUID'ы или делать составные (например с префиксом номера отделения)? Как проще и выходнее? Хотя и так ясно, что на GUID'ах проще, а вот выгоднее ли?
Выгоднее — вряд ли. GUID — довольно большая (сравнительно) штука, которая будет долго сравниваться/переиндексироваться и искаться. Причем заметь, что реально тебе это нужно только при задачах репликации. Можно оставить IDENTITY, просто добавив GUID'ы как дополнительное поле данных. Работаешь в пределах локальной базы по IDENTITY (быстро), а когда нужно реплицировать — передаешь и обновляешь GUID'ы (не будет коллизий).

Есть еще извратные варианты только с IDENTITY — сделать так, чтобы на каждом филиате ключи генерились с неким сдвигом. Другими словами в одной базе 0, 1, 2... а в другой 10001, 10002, 10003 и так далее. Тогда они точно не пересекутся и можно совершенно спокойно использовать их уникальность даже между базами.
Но имхо — это все же изврат и такого лучше не делать — разве что как временную полумеру.

S>4. И вообще насчет проверок на SQL сервере, если я отказываюсь от хранимок. Переносить мне проверки в триггеры или все проверки реализовать на клиенте, а SQL сервер использовать только для хранения?

Хранимки хороши, когда бизнес-логика не очень сложная. Триггеры тоже со временем начинают сильно мешать пониманию. Потому мне кажется, что лучше от них отказаться сейчас — чем позже — тем больше будет головной боли, т.к. тем больше кода придется переделывать. К тому же, сосредоточив всю логику в сервере приложений — ты получишь более понятную и читабельную программу. А с хранимками приходится периодически писать комментарии типа "вот эта проверка реализована на сервере в виде SP", что не есть гуд.
Если информация не критична и используется просто как контроль за невнимательным пользователем — то можно ограничиться проверками на клиенте. Если же это обязательно — то сделай проверки непосредственно на сервере (не SQL) перед передачей данных в Business Entities.

S>С самого начала проекта добавление и обновление записей производилось в хранимых процедурах: в них производились определенные проверки и непосредственно сохранение всех полей.

СУБД какая?

S>1. Если поднимать репликацию, то способ сохранения через хранимки, в которой обновляются ВСЕ поля, даже которые не изменились, плохой, из-за возникновения большого кол-во коллизий при изменении одной и той же записи.

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

S>2. Вытекает из предыдущего. Если делать UPDATE только измененных полей, то как это реализовать. Способ хранить в каждом классе признак измененности для каждого поля мне не нравится. Слишком много кода добавлять придется. Фаулер предлагает хранить в UnitOfWork копии "чистых" объектов и перед сохранением сравнивать все поля. Читал документацию по Хибернейту, но так и не понял, как она сохраняет
поля. Какие еще есть варианты?

Поздравляю. Поддавшись на уговоры делать DomainModel по Фаулеру, ты приобрел много, а заодно еще потерял один уровень абстракции, на котором можно было манипулировать прикладными данными в общем виде (например, универсальным образом перебрать все свойства бизнес-объекта, сравнить их попарно с другим и т.д.). Хибернейт решает это за счет введения метаданных (это очень полезная и мощная возможность, которой Фаулер касается непростительно мало) и механизмов общего доступа (Reflection, proxy).

Хибернейт хранит копию данных в виде набора значений (не копию объекта), если не ошибаюсь.

Здравствуйте, shev, Вы писали:

Вот с этими товарищами поговори (http://www.smart-ex.kz/product/de/), они уже лет 10 занимаются такими вещами. Если согласятся могут много интересного рассказать.

Здравствуйте, Igor Trofimov, Вы писали:

iT>СУБД какая?
MSSQL; Приложение клиент/сервер; создается на Delphi

iT>Уточни, будут ли реально по бизнес-процессам изменения одних и тех же данных в разных местах. Если действительно будут, то тут и изменения по отдельным полям мало помогут.
Пока не знаю. Надеюсь, что не будет, но кто знает

iT>Поздравляю. Поддавшись на уговоры делать DomainModel по Фаулеру, ты приобрел много, а заодно еще потерял один уровень абстракции, на котором можно было манипулировать прикладными данными в общем виде (например, универсальным образом перебрать все свойства бизнес-объекта, сравнить их попарно с другим и т.д.). Хибернейт решает это за счет введения метаданных (это очень полезная и мощная возможность, которой Фаулер касается непростительно мало) и механизмов общего доступа (Reflection, proxy).
Переход на DomainModel это полностью моя идея, о которой я ничуть не сожалею. В программе много расчетов и другой бизнес-логики.

iT>Хибернейт хранит копию данных в виде набора значений (не копию объекта), если не ошибаюсь.
Для себя я пока вижу только один выход: хранить копии объектов, но это сколько же кода в DAL объектах писать придется!

ID>Хранимки хороши, когда бизнес-логика не очень сложная. Триггеры тоже со временем начинают сильно мешать пониманию. Потому мне кажется, что лучше от них отказаться сейчас — чем позже — тем больше будет головной боли, т.к. тем больше кода придется переделывать. К тому же, сосредоточив всю логику в сервере приложений — ты получишь более понятную и читабельную программу. А с хранимками приходится периодически писать комментарии типа "вот эта проверка реализована на сервере в виде SP", что не есть гуд.

Из-за чего иногда оставляют SP — это эффективность. К примеру, если в БД есть иерархия — то рекурсивный обход всего поддерева может очень дорого обойтись, если выполнять передачу данных между SQL-сервером и сервером приложения после каждого запроса.

Здравствуйте, shev, Вы писали:



S>3. Ключи в таблицах у меня IDENTITY. Придется от них отказываться и переделывать на GUID'ы или делать составные (например с префиксом номера отделения)?
Нет не придется. http://msdn2.microsoft.com/ru-ru/library/ms152543.aspx