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

IT>А что ты собираешься делать, если у тебя будет два дочерних объекта (транзакцию ты уже закрыл).
IT>Или ни одного (параметры для дочерней записи у тебя не могут быть NULL)?

Таблица Examinations не может содержать поля типа NULL, а также одна запись в таблице Patients c PatientID должен будет говорить о наличие только одной записи в Examinations c ExamID.

Подробнее структура таблицы здесь

Автор: G2
Дата: 14.06.05

IT>В случае с MS SQL можно использовать два способа:

IT>1. Сделать два спрока. Один для добавления мастер-записи, второй для добавления дочерних.
Уже так сделано, если я правильно понял замечание.
IT>Транзакцию в данном случае контролирует BL. Сначала добавляется мастер-рекорд, затем в цикле все дочерние.

IT>Вместо output параметра удобнее использовать SELECT, т.е. в конце спрока нужно было бы сделать

IT>

IT>SELECT @PatientID
IT>

IT>Тогда, например в ADO.NET, это свелось бы к вызову ExecuteScalar, что намного проще обработки output параметра.
Т.е самому считать инкремент или если уже существует запись, то считывать и передавать в ExecuteScalar?

G2>>Я также храню в business entity Patient поле типа DataSet для хранения дочерней таблицы Examination.

IT>Почему не хранить просто коллекцию объектов? Получается несколько нелогично.

Подсмотрел в "Designing Data Tier Components and Passind Data Through Tier".
Глава "How to Represent Collections and Hierarchies of Data in a Business Entity".

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

G2>Таблица Examinations не может содержать поля типа NULL, а также одна запись в таблице Patients c PatientID должен будет говорить о наличие только одной записи в Examinations c ExamID.

Т.е. у тебя связь один-к-одному/

IT>>1. Сделать два спрока. Один для добавления мастер-записи, второй для добавления дочерних.
G2>Уже так сделано, если я правильно понял замечание.

С той лишь разницей, что вызывать спроки и контролировать транзакцию будет BL. Но если у тебя связь 1-1, то можно вообще всё сделать в одной процедуре.

IT>>Тогда, например в ADO.NET, это свелось бы к вызову ExecuteScalar, что намного проще обработки output параметра.
G2>Т.е самому считать инкремент или если уже существует запись, то считывать и передавать в ExecuteScalar?

Что значит "уже существует"? Вообще я здесь меню ввиду output параметр vs. select.

IT>>Почему не хранить просто коллекцию объектов? Получается несколько нелогично.

G2>Подсмотрел в "Designing Data Tier Components and Passind Data Through Tier".
G2>Глава "How to Represent Collections and Hierarchies of Data in a Business Entity".

И что там рекомендуется использовать для каждого объекта DataSet для хранения его дочерних объектов?

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

IT>>1. Сделать два спрока.

_FR>Хранимая процедура?

Да, сори, американизмы, блин. Stored Procedure -> Stored Proc -> sproc -> спрок

IT>>Один для добавления мастер-записи, второй для добавления дочерних. Транзакцию в данном случае контролирует BL. Сначала добавляется мастер-рекорд, затем в цикле все дочерние. Основным недостатком здесь является наличие дополнительных раундтрипов на сервер при добавлении дочерних записей.

_FR>Это означает "обращение к серверу"?

Roundtrip. В данном контексте похождение на севрер и обратно. Опять же... сори

_FR>Ну, если прям из прикладного кода обращаться процедурам, то возможно, а так это прекрасно разруливается уровнем выше и даёт, так же возможность получения некоторой информации о результате работы. У себя в возвращаемом значении везде коды возврата указываю коды возврата.

И как ты их потом используешь?

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

IT>Stored Procedure -> Stored Proc -> sproc -> спрок
IT>Roundtrip. В данном контексте похождение на севрер и обратно. Опять же... сори

Ничего, мне спросить не лень, а узнать не страшно Спасибо. Это интересно.

_FR>>Ну, если прям из прикладного кода обращаться процедурам, то возможно, а так это прекрасно разруливается уровнем выше и даёт, так же возможность получения некоторой информации о результате работы. У себя в возвращаемом значении везде коды возврата указываю коды возврата.

IT>И как ты их потом используешь?

return  0 -- всё в порядке. все SELECT-процедуры имеют только один такой return без вариантов
return -1 -- Не хватило прав для выполнения изменений.
-- Далее, так как есть System.Data.SqlClient.SqlConnection.FireInfoMessageEventOnUserErrors,
-- сразу после raiserror(N'Message', 16, 1)
return -2 -- При логине неверный пароль
return -3 -- Невозможность изменения записи с точки зрения SQL-серверной логики

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

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

_FR>Клиент имеет доступ к данным только через процедуры, их вид (сигнатуры) унифицированны, исполняются через одну "дырку". На клиенте проблематично узнать не в строковом виде причину ошибки (кроме строкового параметра raiseerror, а что-то более-менее понятное юзеру сообщить охота.
_FR>В основном, из-за этого.

Понятно. У тебя навороченная серверная логика. Я стараюсь всячески избегать такого подходя.

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

_FR>>Клиент имеет доступ к данным только через процедуры, их вид (сигнатуры) унифицированны, исполняются через одну "дырку". На клиенте проблематично узнать не в строковом виде причину ошибки (кроме строкового параметра raiseerror, а что-то более-менее понятное юзеру сообщить охота.
_FR>>В основном, из-за этого.

IT>Понятно. У тебя навороченная серверная логика. Я стараюсь всячески избегать такого подходя.

Мы тоже как можем стараемся! Но ссылочная целосность + сложность на клиенте провести какие-то операции над _множеством_ данных... Кое-что, да, каюсь, проверяется и в СУБД

Мы решили, что логикой хранения\целостности данных будет заниматься сервер, а бизнес-логику всю считаем на клиенте. Кесарю-кесарево. Сервер плохо предназначен для расчётов, а известные мне системы представления данных на клиенте — для соблюдения ссылочной целостности в распределённой системе. Трёхзвенка дело конечно хорошее, но хотелось бы уберечься и от "ручной" правки строк в БД.

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

IT>>Понятно. У тебя навороченная серверная логика. Я стараюсь всячески избегать такого подходя.

_FR>Мы тоже как можем стараемся!

Ну да, я вижу. С логикой в БД обычно такая ситуация — либо она есть, либо её нет. Это как нельзя быть немножко беременной, либо да, либо нет. Так и тут.

_FR>Но ссылочная целосность + сложность на клиенте провести какие-то операции над _множеством_ данных... Кое-что, да, каюсь, проверяется и в СУБД

Сылочная целостность, да и вообще вся data integrity делается с помощью FK и constraints. Обычно этого более чем достаточно. Зачем заниматься велосипедным спортом?

_FR>Мы решили, что логикой хранения\целостности данных будет заниматься сервер, а бизнес-логику всю считаем на клиенте. Кесарю-кесарево. Сервер плохо предназначен для расчётов, а известные мне системы представления данных на клиенте — для соблюдения ссылочной целостности в распределённой системе. Трёхзвенка дело конечно хорошее, но хотелось бы уберечься и от "ручной" правки строк в БД.

Что значит уберечься? Если к серверу БД имеют доступ только сервера приложений, то враг мимо не пройдёт. Это вообще примитивная задача для админа.

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

_FR>>Но ссылочная целосность + сложность на клиенте провести какие-то операции над _множеством_ данных... Кое-что, да, каюсь, проверяется и в СУБД

IT>Сылочная целостность, да и вообще вся data integrity делается с помощью FK и constraints. Обычно этого более чем достаточно. Зачем заниматься велосипедным спортом?

Даже без тригеров?

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

_FR>>Мы решили, что логикой хранения\целостности данных будет заниматься сервер, а бизнес-логику всю считаем на клиенте. Кесарю-кесарево. Сервер плохо предназначен для расчётов, а известные мне системы представления данных на клиенте — для соблюдения ссылочной целостности в распределённой системе. Трёхзвенка дело конечно хорошее, но хотелось бы уберечься и от "ручной" правки строк в БД.

IT>Что значит уберечься? Если к серверу БД имеют доступ только сервера приложений, то враг мимо не пройдёт. Это вообще примитивная задача для админа.

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

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

IT>В случае с MS SQL можно использовать два способа:

IT>1. Сделать два спрока. Один для добавления мастер-записи, второй для добавления дочерних. Транзакцию в данном случае контролирует BL. Сначала добавляется мастер-рекорд, затем в цикле все дочерние. Основным недостатком здесь является наличие дополнительных раундтрипов на сервер при добавлении дочерних записей. Поэтому, нужно смотреть как часто выполняется такие операции и не просадит ли это сервер и сетевой трафик. Достоинтсва — относительная простота SQL кода.

Справедливости ради, стоит отметить, что (как минимум для MS SQL) можно обойтись без раундтрипов. Формируем примерно такой батч:

begin tran
declare @masterID int
exec sp_add_master @param1, @param2, ..., @masterID output

exec sp_add_detail @masterID, @param3, @param4, ...
exec sp_add_detail @masterID, @param5, @param6, ...
...
commit tran

Формировать такой батч несколько сложнее, чем XML, но зато упрощается серверная сторона.

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

S>Справедливости ради, стоит отметить, что (как минимум для MS SQL) можно обойтись без раундтрипов. Формируем примерно такой батч:

S>begin tran
S>declare @masterID int
S>exec sp_add_master @param1, @param2, ..., @masterID output

S>exec sp_add_detail @masterID, @param3, @param4, ...
S>exec sp_add_detail @masterID, @param5, @param6, ...
S>...
S>commit tran

"Разименовывая" "@masterID, @param3" ??

Здравствуйте, _FRED_, Вы писали:
_FR>"Разименовывая" "@masterID, @param3" ??
Чо?

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

_FR>>"Разименовывая" "@masterID, @param3" ??
S>Чо?

S>begin tran
S>declare @masterID int
S>exec sp_add_master @param1, @param2, ..., @masterID output

S>exec sp_add_detail @masterID, @param3, @param4, ...
S>exec sp_add_detail @masterID, @param5, @param6, ...
S>...
S>commit tran

Это CommandText одной SqlCommand со множеством параметров?

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


_FR>Это CommandText одной SqlCommand со множеством параметров?
Ага. @masterID — это не параметр.

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

_FR>>Это CommandText одной SqlCommand со множеством параметров?
S>Ага. @masterID — это не параметр.

Угу, спасиба. Остаётся придумать, как такое динамически строить

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

S>Справедливости ради, стоит отметить, что (как минимум для MS SQL) можно обойтись без раундтрипов. Формируем примерно такой батч:

Какое извращение

S>Формировать такой батч несколько сложнее, чем XML, но зато упрощается серверная сторона.

Если и сложнее, то не намного.

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

IT>Если и сложнее, то не намного.
А если учесть, что частенько объект достаточно просто сериализовать, то xml получается проще...
Но на сервере с ним надо будет повозиться.

Здравствуйте, IT, Вы писали:
IT>Какое извращение
Я бы постеснялся называть способ, приводящий для типичных мастер/деталь к 10кратному росту производительности по сравнению с одиночными запросами и к 10кратному снижению потребляемой серверным процессом памяти по сравнению с парсингом XML извращением
IT>Если и сложнее, то не намного.
В принципе да. Слабо изобрести интерфейс StatementBatch с поддержкой зависимостей между стейтментами? Чтобы все не хуже, чем в обычных SqlCommand. Я вот так сходу чтой-то стесняюсь.

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

S> к 10кратному снижению потребляемой серверным процессом памяти по сравнению с парсингом XML извращением
Да ладно к 10 кратному... Не больше пяти..
А если серьезно, то в нормальных условиях это мелочи, плюс-минус 10кб роли не играют...

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

IT>>Какое извращение
S>Я бы постеснялся называть способ, приводящий для типичных мастер/деталь к 10кратному росту производительности по сравнению с одиночными запросами и к 10кратному снижению потребляемой серверным процессом памяти по сравнению с парсингом XML извращением

Так никто и не спорит. Но для того чтобы попасть из разряда извращений в копилку разработчика нужно всё это доказать. Вон Merle уже говорит, что не в 10, а всего лишь в 5
А вообще надо будет нашего DB архитектора попытать на эту тему. Чувак из MS и во всю двигает XML подход, интересно что он на это скажет

IT>>Если и сложнее, то не намного.
S>В принципе да. Слабо изобрести интерфейс StatementBatch с поддержкой зависимостей между стейтментами? Чтобы все не хуже, чем в обычных SqlCommand. Я вот так сходу чтой-то стесняюсь.

Какой ещё интерфейс? Тут надо просто пару хелперов нарисовать.

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

IT>Так никто и не спорит. Но для того чтобы попасть из разряда извращений в копилку разработчика нужно всё это доказать. Вон Merle уже говорит, что не в 10, а всего лишь в 5
IT>А вообще надо будет нашего DB архитектора попытать на эту тему. Чувак из MS и во всю двигает XML подход, интересно что он на это скажет
Расскажи потом — а то самому интересно.
IT>>>Если и сложнее, то не намного.
S>>В принципе да. Слабо изобрести интерфейс StatementBatch с поддержкой зависимостей между стейтментами? Чтобы все не хуже, чем в обычных SqlCommand. Я вот так сходу чтой-то стесняюсь.

IT>Какой ещё интерфейс? Тут надо просто пару хелперов нарисовать.
Может быть. Настораживает изобилие параметров. Ну вот там, для вставки ордера в "обычном" режиме мы
— вызываем SqlCommand для order, дав ему все параметры, и получаем ID order
— готовим SqlCommand для order_item и в цикле:
-- даем ему очередную пачку параметров (@OrderID, @productId, @quantity) и выполняем.
Что хорошо, так это постоянство имен параметров для order_item. "Второе измерение" им выдается при помощи цикла.
А тут нам придется в цикле вместо Execute делать что-то другое, типа "накопить". При этом параметры могут биндиться как на предоставленные константы (@productId, @quantity), так и на результаты предыдущего запроса (@OrderId).