![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Нужна помощь по TQuery. [D6, dBase, FoxPro, Paradox]
DimonS © (2005-08-31 09:16:00)Раньше почти не работал с запросами, поэтому подскажите, плз.
Как организовать в связке Query+DBGrid работу так, чтобы происходила запись в БД в реалтайме? Т.е. при выходе из ячейки происходила запись в БД нового значения. Писать запрос и переписывать всю строчку? Не желательно, в БД ок. 100 полей. Типа как это происходит при работе с TTable.
Sergey13 (2005-08-31 15:45:00) [1]2[26] Ega23 © (31.08.05 15:17)
Да все я понимаю, Олег. 8-)
Везде свои плюсы и минусы. Но ни у одного способа нет такого плюса или минуса, который перевесит все остальное.
>Если бы в своё время я не ввёл ХП, которая этот список выдаёт клиенту, мне бы приходилось каждый раз в каждом Tquery, который обращается к модели менять текст запроса
А этих запросов десятки и сотни? Этот список (сам по себе) - один запрос. Если в других запросах ты подтягиваешь этот список, то их скорее всего тоже надо будет править. Хоть в ХП хоть напрямую. А если список изменился по структуре. Цвет добавился например. Клиент не поймет нового поля в твоем списке без твоего вмешательства.
>при этом не требуется ребилд клиента.
Это самый убойный аргумент. 8-)
>Всё - исключительно ИМХО. Просто привык к такому стилю.
Аналогично. 8-)
Ega23 (2005-08-31 15:17:00) [2]2 Sergey13 © (31.08.05 14:57) [25]
ИМХО. "При изменении структуры таблиц (или при переходе на другую СУБД) можно некисло сесть в лужу" при любом варианте. И не сесть тоже можно при любом.
Была несколько раз следующая ситуация: Есть готовый модуль "Бюро пропусков". Из него можно давать разрешения на проход в разные Зоны и Точки. Но структура таблиц модели охраняемого объекта в процессе часто менялась (а если быть до конца откровенным, то сейчас я как раз занимаюсь тем, что переделываю её в очередной раз :)). Логика работы "Бюро пропусков" при этом не менялась ни разу. Во многих местах требовалось получить список зон и точек. Если бы в своё время я не ввёл ХП, которая этот список выдаёт клиенту, мне бы приходилось каждый раз в каждом Tquery, который обращается к модели менять текст запроса. Сейчас получается, что "Бюро пропусков" обращается к БД со следующим бизнес-требованием "Дай мне список зон и точек". А переписать ХП - это уже не так сложно.
Мне кажется, что это нечто сродни TAction. За одно и то же действие отвечает и пункт Главного меню, и пункт PopUp меню, и кнопка и сочетание горячих клавишей. Но само действие - одно и то же. Надо изменить логику работы действия - переписываешь код в одном месте. Надо изменить логику получения данных - переписываешь ХП, при этом не требуется ребилд клиента.
Всё - исключительно ИМХО. Просто привык к такому стилю.
Sergey13 (2005-08-31 14:57:00) [3]2[24] Ega23 © (31.08.05 14:38)
ИМХО. "При изменении структуры таблиц (или при переходе на другую СУБД) можно некисло сесть в лужу" при любом варианте. И не сесть тоже можно при любом.
>Я говорю, что мой - более гибкий
Не стоит прогибаться под изменчивый мир
Пусть лучше он прогнется под нас.
(с) Пестня
8-)
Ega23 (2005-08-31 14:38:00) [4]Да почему это? Я вот и без этой прокладки спокойно обходился и обхожусь. И никакого дискомфорта - сухо и не пахнет. 8-)
При изменении структуры таблиц (или при переходе на другую СУБД) можно некисло сесть в лужу. А в случае работы с двумя разными СУБД - вообще плохо будет.
Я не говорю, что твой вариант - невозможен и порочен. Я говорю, что мой - более гибкий
Sergey13 (2005-08-31 14:25:00) [5]2[22] Ega23 © (31.08.05 13:52)
>В случае двух-звенной - прослойка их ХП.
Да почему это? Я вот и без этой прокладки спокойно обходился и обхожусь. И никакого дискомфорта - сухо и не пахнет. 8-)
Ega23 (2005-08-31 13:52:00) [6]2 Sergey13 © (31.08.05 13:22) [21]
А какая разница? С ним, без него - запросы к БД всегда идут к таблицам, а не к ХП.
Разница есть, причём огромная.
Таблица - суть просто хранилище данных.
Клиент - общается с хранилищем данных на уровне бизнес-действий - бизнес-логики. Т.е. фактически клиент говорит - "Получить информацию о сотруднике", "Записать информацию о продажах" и т.п.
В случае полноценной трёх-звенной архитектуры роль транслятора бизнес-действий в физические запросы к конкретным таблицам играет сервер приложений. В случае двух-звенной - прослойка их ХП.
Sergey13 (2005-08-31 13:22:00) [7]2[20] Ega23 © (31.08.05 13:11)
>Ха! А с АПП-сервером клиент у тебя как общается?
А какая разница? С ним, без него - запросы к БД всегда идут к таблицам, а не к ХП.
Ega23 (2005-08-31 13:11:00) [8]все на АПП сервере
Ха! А с АПП-сервером клиент у тебя как общается?
Anatoly Podgoretsky (2005-08-31 13:09:00) [9]DimonS © (31.08.05 10:14) [7]
И с TTable у тебя никогда не было такого.
Тебе про целостность данных уже написали, но это не все, а что ты будешь делать с откатом, ну не захотел пользовать редактировать, передумал, а ты уже все закинул в базу.
Sergey13 (2005-08-31 12:06:00) [10]2[17] Ega23 © (31.08.05 11:51)
>У тебя часто в клиент-серверных системах идут прямые запросы к таблицам?
Всегда. 8-)
Щас на работе ХП вообще под запретом (все на АПП сервере). И раньше никогда не использовал. В Оракле (в 8) вообще получать датасет из ХП несколько геморойно. Да и не дает это (ХП на все) никаких особых преимуществ.
Ega23 (2005-08-31 11:51:00) [11]В любом случае ХП на все - лишь один из равноправных вариантов. ИМХО.
У тебя часто в клиент-серверных системах идут прямые запросы к таблицам? У меня - вообще нигде нет. Так, если что-то тестовое по-быстрому требуется накидать - там да, может прямой Select идти (ну или Insert какой-нибудь). А в конечных продуктах - только через ХП
Sergey13 (2005-08-31 11:48:00) [12]2[15] Ega23 © (31.08.05 11:44)
В любом случае ХП на все - лишь один из равноправныхвариантов. ИМХО.
Ega23 (2005-08-31 11:44:00) [13]2 Sergey13 © (31.08.05 11:24) [14]
Как минимум - спорно. Особенно для Парадокса и ДБФ. 8-)
именно поэтому я и написал не совсем правильно, а не нельзя... :о)
Sergey13 (2005-08-31 11:24:00) [14]2[13] Ega23 © (31.08.05 11:16)
>Вообще писать запросы напрямую к БД - не совсем правильно. Надо прослойку в виде хранимых процедур использовать.
Как минимум - спорно. Особенно для Парадокса и ДБФ. 8-)
Ega23 (2005-08-31 11:16:00) [15]Вот именно из-за частого появления таких вопросов я и считаю TTable со всеми клонами очень вредным компонентом.
2 DimonS
Вообще писать запросы напрямую к БД - не совсем правильно. Надо прослойку в виде хранимых процедур использовать.
Плохиш (2005-08-31 11:07:00) [16]
> DimonS © (31.08.05 09:16)
> Раньше почти не работал с запросами, поэтому подскажите,
> плз.
Сначала приведи перечень литературы, которую ты уже проштудировал. Потом спрашивай, что там не понятно.
Халявщики(Партнёры) маст дай.
dolmat (2005-08-31 10:43:00) [17]>Ну а как проще сделать? Типа того, что записывать при выходе из программы или с интервалом?
Зависит от конкретной задачи. Выбирай сам.
>Просто раньше с БД работал через TTable, но по сети сложновато работает, блокировки и т. д. при многопользовательском доступе.
Меняй базы однозначно.
Sergey13 (2005-08-31 10:42:00) [18]2[9] DimonS © (31.08.05 10:31)
>Ну а как проще сделать?
Делать надо не проще, а правильно. Тебе в [3] все уже сказали. Почитай справку по тем словам. Особенно по TQuery и TUpdateSQL.
ЗЫ: Если работаешь по сети, то стОит подумать о смене БД на серверную.
DimonS (2005-08-31 10:31:00) [19]Ну а как проще сделать? Типа того, что записывать при выходе из программы или с интервалом?
Sergey13 (2005-08-31 10:21:00) [20]2DimonS © (31.08.05 09:16)
>Т.е. при выходе из ячейки происходила запись в БД нового значения.
А нафиг вообще это? Особенно если ушел на соседнее поле. При том что иногда (очень часто !!!) только совокупность значений нескольких полей валидна с точки зрения целостности данных.