Update/Insert/Delete data of a View

← →
Empleado © (2007-05-15 13:34) [0]

Други мои, вот тут задачка в голову пришла. Хочу поделиться мыслею шаловливой, а покуда нет у меня опыта в подобном, может рассуждений толковых услышать от людей с экспириенсом.

Суть:
На MS SQL"е есть база данных;
по определенным причинам необходимо дать возможность разрабатывать приложения вытаскивая информацию из уже построенных Views (включающие в среднем от 2 до 5 таблиц) в ClientDataSet"ы;
показывать ее (инфу) пользователю, который может добавлять/удалять/редактировать.
Соответственно, надо корректно обрабатывать намерения пользователя и отправлять на сервер его изменения.

Хотелось бы:
автоматизировать/оптимизировать этот процесс.

Где проблема:
Невозможно отправлять на сервер изменения данных из View напрямую.
Сначала их надо разделить на блоки данных для каждой таблицы соответственно, затем определить порядок изменений и, например, засунуть все в одну транзакцию.

Вопрос:
Как вы решаете подобные задачи?

Заранее благодарю,
Empleado

******************************
PS. Мои мысли по этому поводу. Читать необязательно, ибо bla-bla-bla...
Почитал тут книжек толковых, да артиклей заморских, и пока вот такую думку надумал:

После того, как пользователь изменил данные и делает ApplyUpdates

I) Либо самому парсировать все вручную и строить sql queries, а затем отправлять на сервер и ждать ответ;
II) Либо попробовать использовать механизмы Client DataSet"ов и Provider"ов;
III) Либо еще что-то ...

Рассмотрю II).
Рассмотрим простой случай, без учета сложных View, с частичными выборками и другими ограничениями. Рассмотрим принцип.

Шаг 1 - получаем данные из View, например в SimpleDataSet (TSimpleDataSet).
Шаг 2 - пользователь закончил работу с данными, сделал изменения/добавления/удаления и нажимает ApplyUpdates.
Шаг 3 - Берем Delta (от View) и преобразуем его в несколько Delta (что есть по сути dataset"ы), в количестве соответствующим числу таблиц, в которые надо внести изменения, и с количеством столбцов, соответствующим количеству столбцов каждой из таблиц.

Естественно, здесь без определенной ручной работы, задания правил, и др. не обойтись.
Т.е. имеем, например, View, состоящий из join"а таблиц Пользователь, Адрес, Телефон, который показывает данные пользователя.
После изменения одного record"а этого View, имеем Delta, состоящий из столбцов, которые фактически принадлежат различным таблицам.
Теперь надо получить Delta1 для Пользователь, Delta2 для Адрес, Delta3 для Телефон, с соответствующим количеством столбцов и с данными из первоисточника Delta и с соответствующими состояниями UpdateStatus.

Шаг 4 - имеем ADODataSet"ы (TADODataSet) с простым запросом "select * from [tablename]" (closed) и привязанными к ним DataSetProvider"ы (TDataSetProvider).
Шаг 5 - В рамках единой транзакции (по возможности), отправляем новые полученные Delta через каждого провайдера каждой таблицы соответственно, в определенном порядке.

← →
Jan1 (2007-05-15 13:47) [1]

> Невозможно отправлять на сервер изменения данных из View
> напрямую.

это ты тоже в книгах прочитал? А там небыло написано про INSTEAD OF триггера? Выбрось каку тогда...

← →
Empleado © (2007-05-15 13:51) [2]

> Jan1 (15.05.07 13:47) [1]

Триггеры использовать - религия не позволяет ;)

← →
zdm © (2007-05-15 14:06) [3]

> Empleado © (15.05.07 13:51) [2]
> > Jan1 (15.05.07 13:47) [1] Триггеры использовать - религия
> не позволяет ;)

а вот это жесть :)

← →
Jan1 (2007-05-15 14:26) [4]

> Триггеры использовать - религия не позволяет ;)

ну тогда в путь в каске и с битой.

← →
Stanislav © (2007-05-15 14:27) [5]

другими словами вы хотите сделать следующее есть 2 таблицы -
главная и подчиненная, соединить их в view"е и заполнять в 1 -ом гриде часть столбцов главной табл. и часть подчиненной?

← →
Empleado © (2007-05-15 14:33) [6]

> zdm © (15.05.07 14:06) [3]
> Jan1 (15.05.07 14:26) [4]

Ладно, отвлекусь. Истинность религии не в том, насколько она религиозна, а в том, насколько это важно.

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

К тому же, некоторые данные получаются в приложение не только из View, но и из stored procedures.

← →
Empleado © (2007-05-15 14:40) [7]

> Stanislav © (15.05.07 14:27) [5]
> другими словами вы хотите сделать следующее есть 2 таблицы - главная и подчиненная, соединить их в view"е и заполнять
> в 1 -ом гриде часть столбцов главной табл. и часть подчиненной?

По сути, да.
Попробую детализировать твой пост.
Есть две таблицы на сервере.
Мы их связываем в одном View на сервере.
Далее, на клиенте в одном гриде работаем с данными из этого View, не делая различия между таблицами, как с единым куском информации.

← →
Jan1 (2007-05-15 14:43) [8]

> К тому же, некоторые данные получаются в приложение не только
> из View, но и из stored procedures.

и? их что нельзя редактировать?

> Далее, на клиенте в одном гриде работаем с данными из этого
> View, не делая различия между таблицами, как с единым куском
> информации.

батенька, триггер спасет отца русской демократии :)

← →
Stanislav © (2007-05-15 14:44) [9]

Empleado © (15.05.07 14:40) [7]
тогда это не совсем логично.

← →
Jan1 (2007-05-15 14:49) [10]

> тогда это не совсем логично.

это логично в случае секьюрити.

← →
Empleado © (2007-05-15 14:57) [11]

> Empleado © (15.05.07 13:34)

Тут подумалось, как дополнение к варианту II) из PS.

К Шаг 3. Брать Delta как XML и изменять данные/столбцы, тем самым получая новые Delta1, Delta2, Delta3. Но что-то мне подсказывает, что это будет работать медленнее...

← →
Jan1 (2007-05-15 15:05) [12]

2 Empleado ©
мне вот интересно, если я подключусь к Вашей базе не Вашим приложением. которое логику реализует, то в каком будут состоянии данные, когда я там поработаю через QA?

← →
Stanislav © (2007-05-15 15:26) [13]

А то что не логично, обычно работает неправильно.
Ну, сами посудите есть 2 таблицы поставщики и продукция.
Заводим первую сторчку
1. ОАО ЗВЕЗДОЧКА конфеты
2. ОАО ЗВЕЗДОЧКА мороженое
Мне что нужно на 2 строчке заводить нового поставщика?
Или я ч ето не понял :-)

← →
Jan1 (2007-05-15 15:43) [14]

> Stanislav ©

смотря как Вы это реализуете. или ручками вводить или выбор из справочника. А вьюха как правило нужна для сокрытия информации о метаданных...

← →
Stanislav © (2007-05-15 15:46) [15]

Ну можно в вьюхе не объединять несколько таблиц.

← →
Anatoly Podgoretsky © (2007-05-15 23:32) [16]

Триггера, триггера, триггера
BOL, BOL, BOL
Не Дельфи, Не Дельфи, Не Дельфи

данные клиенту из VIEW
INSERT, UPDATE, DELETE через хранимые процедуры.

← →
Sergey Masloff (2007-05-20 14:33) [18]

Empleado © (15.05.07 14:33) [6]
Гланды будем (в силу не зависящих от нас причин) вырезать через задний проход. Уважаемы профессионалы подскажите как это делается наиболее оптимально. Традиционный способ не предлагать.

Хе-хе.

>К тому же, некоторые данные получаются в приложение не только из View, но и из stored procedures.
Это абсолютно ничего не меняет.

Вобщем с триггером это самый безграбельный способ. Избавляет от массы проблем (даже если пока эти проблемы не осознаются авторами)

Второй способ - апдейт всего через хранимые процедуры.

Все остальное уже криво с разной степенью кривизны.

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

+1.

Для МС СКЛ я бы объединил оба способа (написать вызов из триггера хранимки довольно просто, к тому же можно было бы поставить процесс написания тригерров на автомат).
В качестве достоинства МС СКЛ (в отличие от столь любимого мной оракла) я бы указал безопасную работу с триггерами (при условии верного их написания, а то даже в родных книжках по мс скл примеры их с ошибками).

>Sergey Masloff (20.05.07 14:33) [18]
Знаю, что через задницу, но обсуждению не подлежит.
Не то, чтобы это мои капризы "я не хочу/не буду", а нельзя - по независящим от меня причинам сверху.
Почитав немного, действительно осознаю, что с триггерами легче. Но - исхожу из поставленной задачи и требований.

Пока придерживаюсь версии делать updates через SPs, без мороки на клиенте.
Большое спасибо всем!

PS.
>ANB © (21.05.07 11:56) [19]
> к тому же можно было бы поставить процесс написания тригерров на автомат
Можно немного подробнее? Мне не совсем понятна фраза.
Спасибо

> Можно немного подробнее? Мне не совсем понятна фраза.
> Спасибо

Триггера можно писать не ручками, написать простенькую програмку (можно и хранимку), которая по информации в словаре этот триггер и сгенерит. А всю хитрую логику уже в хранимке ручками. Подобные технологии я уже видел в куче проектов да и сам применял.
ЗЫ. Хороший программист - ленивый программист.

← →
Jan1 (2007-05-21 12:33) [22]

>ANB © (21.05.07 11:56) [19]
> к тому же можно было бы поставить процесс написания тригерров
> на автомат

Так делает репликация на MS SQL. Очень удобно. Сам так делаю. Советую глянуть системные хранимки, которые написал мелкософт для создания схемы репликации для Мерж-реплики, там многому научитесь.

Update/Insert/Delete data of a View Найти похожие ветки