Форум: "Базы";
Текущий архив: 2003.08.28;
Скачать: [xml.tar.bz2];
ВнизОбновление нескольких таблиц одним SQL-запросом Найти похожие ветки
← →
dmtr (2003-08-02 13:00) [0]Подскажите можно ли реализовать сабж?
Ситуация следующая: есть IBDataSet, в который подгружаются данные из трех связных таблиц. Данные отображаются в грид. Я хочу осуществить возможность модификации данных. Если создаю запрос на модификацию полей только одной таблицы, то все нормально, нескольких-соответственно не могу. Может кто подскажет способ осуществить задуманное?
← →
Desdechado (2003-08-02 16:24) [1]напиши ХП, в которую будешь передавать как параметры данные строки из своего Dataset. ХП должна их рассовать в нужные таблицы со всеми взаимосвязями.
← →
dmtr (2003-08-04 10:51) [2]А можно ли определить какие записи в датасете были изменены или придется в ХП передовать все записи набора данных?
← →
Sergey13 (2003-08-04 10:58) [3]2dmtr © (02.08.03 13:00)
>Ситуация следующая: есть IBDataSet, в который подгружаются данные из трех связных таблиц.
ИМХО, редактировать "связанные таблицы" имеет смысл только тогда, когда связь 1:1. Иначе можно нарваться на ситуацию...
← →
Жук (2003-08-04 11:03) [4]Я делаю в Modify обновление "основной таблицы", а связанные через Query. Потом просто Refresh. Но это такой геморой, ИМХО. Вариант с ХП поинтереснее будет.
← →
MsGuns (2003-08-04 11:31) [5]Подобную траблу решал таким образом:
Компонент для визуализации данных - TIBQuery
Все изменения-вставки через открываемую поверх грида панель с контролами типа TEdit, TComboBox, etc
Собственно изменения в таблицах делаются через отдельную транзакцию компонентой TIBSQL (последовательными запусками на каждую изменяемую таблу сверху вниз при вставке и снизу вверх при удалении)
Затем переоткрытие TIBQuery с позиционированием.
Как правильно сказал Жук © (04.08.03 11:03),- достаточно геморно. Но все работает очень даже кучно и шустро. Просто я не сторонник для каждого зевка лезть на сервер. Доводилось видеть БД с десятком таблиц и более сотни ХП. Что-либо изменить в такой базе (структурно) невозможно. Хотя все это ИМХО
← →
Соловьев (2003-08-04 11:39) [6]
> не сторонник для каждого зевка лезть на сервер.
но может прийти такой момент, когда прийдется переписывать приложения, а если их много(видов) и стоят у разных клиентов, где-то что упустил и все - траблы. В книгах по проектированию БД, все время говорят о том, что нужно максимально насытить сервак: он и быстрее клиента, и памяти у него бльше и редактирование структуры и логики БД всегда происходит централизовано.
← →
Sergey13 (2003-08-04 11:45) [7]2Соловьев © (04.08.03 11:39)
Спорно все это.
1. Сервер не обязательно мощнее клиента.
2. Может у него памяти и больше, но и клиентов у него много
3. При изменении логики работы менять придется и на сервере и на клиенте (в программе) - как правило.
← →
MsGuns (2003-08-04 11:46) [8]>Соловьев © (04.08.03 11:39)
Да ведь никто не спорит. Но все зависит от ситуации. Если проект сделан по принципу "Одна прога - одна БД", то вне всяких сомнений. Если же одна БД обслуживает кучу разных функционально приложений, которые к тому же пишутся разными программерами или даже подразделениями, то тут надо 77 раз омерять прежде чем лезть на сервер.
Хотя это вопрос вообще достаточно тонкий.
ЗЫ. Книжки - вещь чрезвычайно полезная и поучительная. Но ведь они тоже пишутся людьми и не могут к тому же описать ВСЕ ситуации.
← →
Danilka (2003-08-04 13:18) [9]А мне привычнее запрос оформить вьюхой а добавление/изменение/удаление записей сделать триггерами.
Очень удобно, думаю, для того вьюхи и существуют.
MsGuns © (04.08.03 11:46)
>ЗЫ. Книжки - вещь чрезвычайно полезная и поучительная. Но ведь
>они тоже пишутся людьми и не могут к тому же описать ВСЕ
>ситуации.
Все - немогут, большинство - могут. :))
Вообще-то легче добавить мощностей в один сервак, чем каждому клиенту все раздать. Вон, есть великолепный пример, когда думает клиент, а сервак бамбук курит: 1С на SQL. :))
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.08.28;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.006 c