поиск в БД

← →
Scot Storch (2010-06-04 14:02) [0]

в определенные моменты в программе нужно проверять есть ли в таблице БД запись (по логике может быть только одна либо вообще не быть) со значением X в поле A и значением Y в поле B. Как лучше сделать поиск и проверку: запросом или Locate"ом?

← →
Ega23 © (2010-06-04 14:07) [1]

select exists + F1

← →
aka (2010-06-04 14:07) [2]

> со значением X в поле A и значением Y в поле B.

В ХП с возвратом

← →
test © (2010-06-04 14:38) [3]

БД какая?

← →
Sergey13 © (2010-06-04 14:48) [4]

> [1] Ega23 © (04.06.10 14:07)

Exists тут имхо ни к чему.
Просто select и проверка вернуло ли что нибудь или select count(id) и анализ результата.

> [2] aka (04.06.10 14:07)

На каждый чих, ИМХО, никакого смысла ХП создавать нет.

← →
Медвежонок Пятачок © (2010-06-04 14:52) [5]

Как лучше сделать поиск и проверку

Лучше сделать констрейнт.
тогда проверять не потребуется, так как будет либо одна, либо не будет

← →
oldman © (2010-06-04 16:17) [6]

> со значением X в поле A и значением Y в поле B

Вычисляемое поле A+B и индекс по нему.

← →
Игорь Шевченко © (2010-06-04 17:46) [7]

> Как лучше сделать поиск и проверку: запросом или Locate"ом?

запросом

← →
Псалтырь © (2010-06-04 23:24) [8]

SELECT 1 FROM table WHERE x = A AND y = B LIMIT 1

← →
Sergey13 © (2010-06-07 10:03) [9]

> [0] Scot Storch (04.06.10 14:02)

Строго говоря для однозначного ответа на твой вопрос мало информации.
Если прога однопользовательская и таблица небольшая (+ постоянно вся находится в памяти, типа справочник), то Locate проще и, наверное, быстрее. Если эти условия не соблюдены, то отдельный запрос - более предпочтительное средство узнать правду.

← →
12 © (2010-06-07 10:57) [10]

Имхо, все на хп надо
потом захочется на VС, на web-лицо перевести

Кстати, покритикуйте метод
...
if Exists(select ObjectsId from rnrRequest where ObjectsId = @Id)
begin
Select 1 as Result, "Невозможно удалить - имеются заявки с этим объектом" as Becouse;
Return;
end
else begin
delete from rnrObject where IdObject = @Id;
Select 0 as Result, "Ok" as Becouse;
end;

или вот как добавить.

ALTER PROCEDURE [dbo].[rnrAddObject]
@Name_IN varchar(50),
@Address_IN varchar(50),
@Id_IN int
AS
BEGIN
declare @Id int; Set @Id = @Id_IN; -- сохраним входные
declare @Name varchar(50); SET @Name = @Name_IN;
declare @Address varchar(50); SET @Address = @Address_IN;

SET NOCOUNT ON;
IF @Id = -999
BEGIN
IF (@Address = "") OR (@Address is null)
INSERT INTO rnrObject (ObjectName) values (@Name);
ELSE
INSERT INTO rnrObject (ObjectName, AddressObject) values (@Name, @Address);
SELECT SCOPE_IDENTITY() as Result, "Ok" as Becouse FROM rnrObject;
END
ELSE
BEGIN
IF (@Address = "") OR (@Address is null)
INSERT INTO rnrObject (IdObject, ObjectName) values (@Id, @Name)
ELSE
INSERT INTO rnrObject (IdObject, ObjectName, AddressObject) values (@Id, @Name, @Address);
SELECT SCOPE_IDENTITY() as Result, "Ok" as Becouse FROM rnrObject;
END;
END

смысл - Любая процедурка после своего испонения вернет Result и Becouse, для расшифровки и показа юзеру, почему не сделано.
Для перевода остается только на соотв.языке переписать внешний вид

← →
Sergey13 © (2010-06-07 12:03) [11]

> [10] 12 © (07.06.10 10:57)
> Кстати, покритикуйте метод
> ...
> if Exists(select ObjectsId from rnrRequest where ObjectsId
> = @Id)
> begin
> Select 1 as Result, "Невозможно удалить - имеются заявки
> с этим объектом" as Becouse;

Почему нельзя просто констрейнт (FK) поставить?

← →
Sergey13 © (2010-06-07 12:06) [12]

> [10] 12 © (07.06.10 10:57)
> Имхо, все на хп надо

Во первых, не везде есть ХП.
Во вторых, какой смысл на каждый чих создавать объект, за которым надо следить и сопровождать?

← →
12 © (2010-06-07 12:24) [13]

> Во первых, не везде есть ХП.

ок, правда, где есть - там.

> Во вторых, какой смысл на каждый чих создавать объект,

не известно, что захотят потом. На всякий.
А если не объект в БД, то код в программе - все равно поддерживать

> Почему нельзя просто констрейнт (FK) поставить?

можно, не пробовал, надо попробовать/посмотреть
так просто мне понятно, заодно все делаю однообразно exec БЛАБЛА :параметр
и поля результата понятные - Result и becouse.
все это в отдельной процедуре, в отдельном модуле

← →
Petr V. Abramov © (2010-06-07 13:23) [14]

> 12 © (07.06.10 12:24) [13]
> можно, не пробовал, надо попробовать/посмотреть

if exists и delete выполняются неатомарно, между ними вполне может влезьть insert в rnrRequest из другой транзакции, и ты приплыл. Вероятность этого маленькая вроде бы, но законы Мэрфи имеют приоритет над законами больших чисел, проверено.
А констрейнт все эти гадкие ситуации гарантированно разруливает.

← →
Sergey13 © (2010-06-07 14:39) [15]

> [13] 12 © (07.06.10 12:24)
> А если не объект в БД, то код в программе - все равно поддерживать

Так код программы по любому сопровождать. Я понимаю когда ХП что-то делает независимо от клиента (типа запускает расчет отдающий клиенту одно число), тогда конечно оправдано ее использование. Вот добавилось поле в таблице - клиента практически по любому надо править, а при твоем подходе еще и хрен знает сколько процедур, который связаны с другими процедурами. Легко нарваться на не валидность какой нибудь (например твоей проверочной) и получить гемороя по полной программе.

> можно, не пробовал
Как же ты с БД то работаешь? 8-)

← →
Petr V. Abramov © (2010-06-07 15:01) [16]

> Sergey13 © (07.06.10 14:39) [15]
> Вот добавилось поле в таблице - клиента практически по любому
> надо править

добавилось поле в таблице - по зависимостям словарь запросил, и более-менее понятно, что надо править. А какие формы от таблицы зависят - ищи-свищи.

> > можно, не пробовал
> Как же ты с БД то работаешь? 8-)

медленно..
Есть у меня их (FK) - но прежде чем написать что-то сидю, думаю :)
Начальник съест скоро - производительность малая

зато сообщения типа "Невозможно удалить - имеются заявки с этим объектом"
намного лучше для пользователя(он и заявки удалит или откажется удалять объект), чем нарушение какого-то констрейта

Select 1 as Result, "Невозможно удалить - имеются заявки с этим объектом" as Becouse;

Я бы в случае ошибки взводил исключение, так проще для клиентской части. она получает не нормально отработанную ХП, а ошибку с текстом, даже если у клиента нет обработки ошибок в принципе работать дальше с ошибочными данными он не будет.

declare @Id int; Set @Id = @Id_IN; -- сохраним входные
declare @Name varchar(50); SET @Name = @Name_IN;
declare @Address varchar(50); SET @Address = @Address_IN;

В куда и зачем? У тебя есть доступ к переменным, которые передаются при вызове ХП, зачем их дублировать?

> [16] Petr V. Abramov © (07.06.10 15:01)
> А какие формы от таблицы зависят - ищи-свищи.

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

> Кроме того, как правило, от таблицы напрямую только датамодуль
> зависит.

Где б найти такое правило...

> В куда и зачем? У тебя есть доступ к переменным, которые
> передаются при вызове ХП, зачем их дублировать?

давно кто-то так посоветовал, при отладке смотреть что вошло и что сейчас удобно. И, если процедура, как думаю, будет потом расти - всегда так делаю.

Насчет исключения - в принципе, можно..
Я просто к чему - когда все ХП заканчиваются так
Select ХХХ as Result, "ННННН" as Becouse; - бывает удобно писать общие вещи для всех

12 © (07.06.10 17:06) [22]

Точно так же ты можешь просмотреть и состояние переменных которые передаются, если у тебя несколько дублированных вариантов, сам потом в них путаться будешь. Каким то присвоил новые значения каким то нет.

Если ХП отработала, клиент не знает на сколько корректно были выполнены запросы, чтобы остановить работу или явно указать об ошибке используют исключения.

Допустим отработала ХП запись в бд новых значений, в becouse ошибка, но ее не проверили, программа работает дальше, записывает выполняет какие то действия и собирает вместо 1 уже целый ворох ошибок, никто не гарантирует что в ситуации с прочтением becouse(*словарь и распозновалка?*) такое не случиться. Просто ИМХО надежнее.

Сам просил покритиковать, тут это легко ))

поиск в БД Найти похожие ветки