:: Visual Foxpro, Foxpro for DOS
Re: SQL-UPDATE "первой" записи
sphinx

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
pasha_usue
С точностью до наоборот. ID это суррогатный ключ, он вводится в модель только потому, что оперировать естественным ключом не всегда удобно.С точностью до наоборот. ID это суррогатный ключ, он вводится в модель только потому, что оперировать естественным ключом не всегда удобно.

Пашк, ты авторитетный товарищ, тебя он должен услышать. Я пытался, хоть и не гуру..

p.s. Так-то это зло работать с ненормированными таблицами, да еще с "ограничением", что суррогатный ключ не нужен.


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
of63
Элементарный вопрос вроде задал... Приведите пример кода UPDATE одной записи из двух "одинаковых" (определение одинаковости придумайте сами, раз это слово вызывает затруднения в интерпретации). Я привел, с RECNO() (или с ID вместо него). Лулгу привел примеры... и всё. Остальные посты - убеждения меня в моей непроходимой тупости
Можно привести постановку задачи, когда сама структура хранения не нарушает принципов реляционной БД. А тем не менее, необходимость в таком вопросе возникает.

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

Ну, а в процессе решения мы встречаем документ с двумя одинаковыми по размеру максимальными суммами. И да, записи в таблице прекрасно друг-от-друга отличаются. А с точки зрения постановки задачи, без разницы, куда сносить, но на одну строку.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
sphinx

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
akvvohinc
По-моему, TOP без ORDER работать не будет.По-моему, TOP без ORDER работать не будет.

Думаю да (не проверял). Но что мешает упорядочить? К тому же по критерию, который автор задачи знает?


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
sphinx

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Пашк, привет!
Да я тот же самый вопрос Олегу задавал (ну право, даже не потерли, повода нет)... Задачи с его данными нет. Мое решение (его и другие участники поддержали, короче/проще вроде нет). Ан нет - ему хочется и без уникальных ключей, и формировать их не хочет, и антиреляционное использование номера записи - не подходит.
Работает с ненормализованными данными, без уникального ключа записи... А еще что-то требует и обвиняет коллег в тупизне. Пфффф...


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
sphinx

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Да и то выберут ему нужное. ;)

Ну ведь прошу - ну кинь сюда такой супер-пупер набор записей , посмотрим.


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
of63
Вопрос был "нет ли в UPDATE такой же опции как TOP N в SELECT"
Нет, и не нужно.
of63
Ведь в SELECT присобачили возврат TOP N - N записей, отобранных произвольно, или в порядке ORDER...
"Отобранных произвольно" - это ошибка использования опции. СУБД может и не позволить такой "произвольности". Для варианта "выбора" имеет смысл упорядочение, и имеет некоторый смысл ограничение "по количеству/объёму отобранных записей". Это (ограничение по "количеству записей") отход от реляционного принципа - но он вполне удобен, так же как и некоторым образом связанный механизм "пейджинга" - т.е. отбора "первые 20", потом "следующие 20" и т.д.

Update в отличие от Select не "возвращает записи пользователю" - и работает над ВСЕМ массивом записей подходящих под условие. Более того, в нормальной СУБД он ещё и атомарно выполняется - т.е. обновит либо ВСЕ подходящие, либо ни одной. На "полпути" он никогда не остановится (увы, фоксу тут жирный минус - даже его транзакция не даёт гарантии).
Потому для update не имеют смысла ни "ограничение количества обрабатываемых записей" ни "порядок обработки".

of63
Или интересно как это делают тру-дбашники, когда им надо изменить одну запись в группе неразличимых (кроме ID) записей.
По id - это же очевидно Или по одному из его суррогатов (типа recno(), rowid), если создатель таблицы был настолько неадекватен, что иных "различий" в записях нет.
Как они "выберут" этот самый id - это вопрос личных предпочтений, и наличия в БД связей (т.к. может уже на "накладную" повешено 100500 документов, проводок, да и собственно "строк" с товарами - это ограничивает возможности по изменению записи - не физически, а "логически", чтобы не сделать ещё хуже). Для "несвязанных" элементов лично я удалил бы запись с большим id - т.к. обычно id наращиваются, а значит запись с "большим id" была создана позже - тогда как надо было бы вместо создания эту раннюю использовать.

А чтобы этого (возникновения "двух одинаковых накладных") не происходило, то в БД добавляют ключи-кандидаты (они же уникальные индексы) - они как раз и не дадут ввести ещё одну накладную с тем же "номером", решая проблему ДО её возникновения с БД


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
Ответ я уже получил, очевидный, что TOP 1 опции нет, я и сам видел, что ее нет, в хелпе на UPDATE.

Но все же, чтобы удостовериться в своей тупизне и продвинутости дба-шников, нарисовал пример, похожий на мою задачу. Как бы вы записали UPDATE в этом примере, чтобы он обновлял единственную любую запись среди группы "неразличимых"? (структуру выходного файла не менять, идей по его более правильному устройству не предлагать, ID я приделал по вашим настойчивым просьбам, теперь она стала тру-базой, реально ID нет, да он и не нужен в данном случае)
CLOSE ALL
SELECT 0
CREATE CURSOR tovar (ID I, nam C(20), op C(20), datap D) && список товаров в магазине
INSERT INTO tovar (ID, nam, op, datap) VALUES (1, "огурец", "мелкий", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (2, "огурец", "крупный", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (3, "огурец", "зеленый", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (4, "помидор", "красный", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (5, "помидор", "на веточке", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (6, "помидор", "битый", DATE())
SELECT 0
CREATE CURSOR kol (ID I, nam C(20), ITOGO I) && количества товаров в магазине, без учета подробностей товара (без поля tovar.op)
INSERT INTO kol (ID, nam, itogo) VALUES (1, "огурец", 100)
INSERT INTO kol (ID, nam, itogo) VALUES (2, "помидор", 200)
* Нужна такая же таблица tovar, но с дополнительной колонкой ITOGO, проставленной в любой строке соответствующего товара
* (в одной строке "огурец", и в одной строке "помидор"), * чтобы сумма по полю ITOGO таблицы давала ITOGO = 100 + 200
SELECT 0
* сейчас сделано так: изготовляем заготовку выходной таблицы (с полем ITOGO, пока оно пустое)
SELECT *, CAST(0 AS I) AS itogo FROM tovar INTO CURSOR titogo READWRITE && добавляем поле ITOGO к tovar
SELECT kol
SCAN && перебираем записи kol, переносим поле kol.itogo в выборку titogo
UPDATE titogo SET itogo=kol.itogo WHERE nam=kol.nam
* это неверно, т.к. заполняются все записи "огурец" полем itogo=100.
* Как записать UPDATE, чтобы он обновлял только единственную запись "огурец" или "помидор" ?
* В реальном примере удавалось усложнением WHERE находить единственную запись, но теперь эта возможность исчезла...
ENDSCAN
SELECT titogo
BROWSE
CLOSE ALL
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
of63
Ответ я уже получил, очевидный, что TOP 1 опции нет, я и сам видел, что ее нет, в хелпе на UPDATE.
Но все равно, с упорством, достойным лучшего применения, будем упираться именно в UPDATE?
Цитата:

Но все же, чтобы удостовериться в своей тупизне и продвинутости дба-шников, нарисовал пример, похожий на мою задачу. Как бы вы записали UPDATE в этом примере, чтобы он обновлял единственную любую запись среди группы "неразличимых"? (структуру выходного файла не менять, идей по его более правильному устройству не предлагать, ID я приделал по вашим настойчивым просьбам, теперь она стала тру-базой, реально ID нет, да он и не нужен в данном случае)
Ппц.. Ты еще только формируешь условия задачи, но уже знаешь что нужно/не нужно для её решения?
Далее твой слегка переделанный код. Оцени сколько в нем совершенно ненужного. MAX(ID), при желании, можешь заменить на свою любую.
*ssa* Close All
*ssa* Select 0
Create Cursor tovar (Id I, nam C(20), op C(20), datap D) && список товаров в магазине
Insert Into tovar (Id, nam, op, datap) Values (1, "огурец", "мелкий", Date())
Insert Into tovar (Id, nam, op, datap) Values (2, "огурец", "крупный", Date())
Insert Into tovar (Id, nam, op, datap) Values (3, "огурец", "зеленый", Date())
Insert Into tovar (Id, nam, op, datap) Values (4, "помидор", "красный", Date())
Insert Into tovar (Id, nam, op, datap) Values (5, "помидор", "на веточке", Date())
Insert Into tovar (Id, nam, op, datap) Values (6, "помидор", "битый", Date())
*ssa* Select 0
Create Cursor kol (Id I, nam C(20), ITOGO I) && количества товаров в магазине, без учета подробностей товара (без поля tovar.op)
Insert Into kol (Id, nam, ITOGO) Values (1, "огурец", 100)
Insert Into kol (Id, nam, ITOGO) Values (2, "помидор", 200)
* Нужна такая же таблица tovar, но с дополнительной колонкой ITOGO, проставленной в любой строке соответствующего товара
* (в одной строке "огурец", и в одной строке "помидор"), * чтобы сумма по полю ITOGO таблицы давала ITOGO = 100 + 200
*ssa* Select 0
*ssa* * сейчас сделано так: изготовляем заготовку выходной таблицы (с полем ITOGO, пока оно пустое)
*ssa* Cast(0 As I) As ITOGO From tovar Into Cursor titogo Readwrite && добавляем поле ITOGO к tovar
*ssa* Select kol
*ssa* Scan && перебираем записи kol, переносим поле kol.itogo в выборку titogo
*ssa* Update titogo Set ITOGO=kol.ITOGO Where nam=kol.nam
*ssa* * это неверно, т.к. заполняются все записи "огурец" полем itogo=100.
*ssa* * Как записать UPDATE, чтобы он обновлял только единственную запись "огурец" или "помидор" ?
*ssa* * В реальном примере удавалось усложнением WHERE находить единственную запись, но теперь эта возможность исчезла...
*ssa* Endscan
*ssa* Select titogo
select tovar.*, Cast(Nvl(Itogo, 0) as int) as ITOGO ;
from tovar ;
left join ;
(select kol.*, t.id as tovar_id ;
from kol inner join ;
(select Max(id) as id, nam ;
from tovar group by nam ;
) t on kol.nam = t.nam ;
) t2 on tovar.id = tovar_id ;
into Cursor titog
Browse
*ssa* Close All


------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
> Но все равно, с упорством, достойным лучшего применения, будем упираться именно в UPDATE?
Мы не упираемся, просто хотим посмотреть, как этот UPDATE (или в хитром SELECT-е), но не фоксовыми операторами LOCATE, RELATION...) делают серьезные бородатые админы БД.

> Оцени сколько в нем совершенно ненужного
Оценил Позволил себе переформатировать, вынести за скобки части выражения, иначе вообще не могу прочитать. Идея-то понятная "в группе 'одинаковых' записей выберем ее единственный ID по признаку MAX(ID)", но многоуровневость, два join-а, промежуточная выборка t2, изложения в твоем SELECT "убивает". Неужели проще на SQL не выражается, этот заменитель "UPDATE TOP 1"...

* T - выбираем bp tovar по одной строке {ID,nam} по каждой группе товаров
#DEFINE groupTovar select Max(id) as id, nam from tovar group by nam
* T2 - из kol извлекаем {nam, itogo, T.ID), где T.ID и есть ЕДИНСТВЕННАЯ запись из tovar
#DEFINE kol_tovar_1 select kol.*, t.id as tovar_id from kol inner JOIN (groupTovar) t on kol.nam = t.nam
select tovar.*, Cast(Nvl(Itogo, 0) as int) as ITOGO ;
from tovar ;
left join (kol_tovar_1) t2 on tovar.id = tovar_id ;
into Cursor titogo
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Серьёзные постановщики просто не делают неподходящих под задачу структур данных - а если по недостатку информации сначала и делают, то потом при помощи перепроектирования, т.е. рафакторинга этот недостаток устраняют. И им попросту никогда не требуется "обновить одну запись из кучи почти одинаковых".
of63
вынести за скобки части выражения, иначе вообще не могу прочитать
В принципе в новых диалектах SQL есть синтаксис с факторизацией подзапросов (как раз для улучшения "понимания" многоуровневого кода - иногда и для улучшения его работы). Примерно это будет выглядеть так:
WITH groupTovar as
(select Max(id) id, nam from tovar group by nam),
kol_tovar_1 as
(select kol.*, t.id tovar_id from kol inner JOIN groupTovar t on kol.nam = t.nam)
select tovar.*, Cast(Nvl(Itogo, 0) as int) ITOGO
from tovar left join kol_tovar_1 t2 on tovar.id = tovar_id


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
of63
> Но все равно, с упорством, достойным лучшего применения, будем упираться именно в UPDATE?
Мы не упираемся, просто хотим посмотреть, как этот UPDATE (или в хитром SELECT-е), но не фоксовыми операторами LOCATE, RELATION...) делают серьезные бородатые админы БД.
Тебе уже не раз написали - твой вопрос некорректен и в такой постановке никак он не решается. Какое слово непонятно?
Цитата:

> Оцени сколько в нем совершенно ненужного
Оценил Позволил себе переформатировать, вынести за скобки части выражения, иначе вообще не могу прочитать. Идея-то понятная "в группе 'одинаковых' записей выберем ее единственный ID по признаку MAX(ID)", но многоуровневость, два join-а, промежуточная выборка t2, изложения в твоем SELECT "убивает". Неужели проще на SQL не выражается, этот заменитель "UPDATE TOP 1"...
Во-первых, ты опять со своим идиотским UPDATE TOP 1.
Во-вторых, это не сложный запрос, а всего лишь твое слабое кун-фу в части запросов.
В-третьих, код конкретно под предоставленные тобой код и данные. И сформулирован так, чтобы ты мог понять его. Хотя все можно было сделать и без подзапросов.
И в-четвертых, тебе приводили более простые варианты. Но, похоже, ты так их и не понял. Как и то, что зациклившись на своих таких привычных еще доFPD-шных подходах к работе с данными ты сам себя загнал в тупик и вынужден теперь задавать идиотские вопросы.


------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
Думаешь, что я задаю идиотские вопросы, потому что идиот, или потому, что не решил, или потому что зациклилcя на FPD, или потому что поленился прочитать ваши простые решения, или не в курсе про ID и зачем оно... Просто хотел поделиться с коллегами интересной деталькой в SQL (что "не может запросто сделать элементарное"), да и на людей посмотреть, как они выглядят для спрашивающего, на форуме друзей
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
lulgu

Сообщений: 1838
Дата регистрации: 30.11.2016
of63
Ответ я уже получил, очевидный, что TOP 1 опции нет, я и сам видел, что ее нет, в хелпе на UPDATE.
Но все же, чтобы удостовериться в своей тупизне и продвинутости дба-шников, нарисовал пример, похожий на мою задачу. Как бы вы записали UPDATE в этом примере, чтобы он обновлял единственную любую запись среди группы "неразличимых"? (структуру выходного файла не менять, идей по его более правильному устройству не предлагать, ID я приделал по вашим настойчивым просьбам, теперь она стала тру-базой, реально ID нет, да он и не нужен в данном случае)
CLOSE ALL
SELECT 0
CREATE CURSOR tovar (ID I, nam C(20), op C(20), datap D) && список товаров в магазине
INSERT INTO tovar (ID, nam, op, datap) VALUES (1, "огурец", "мелкий", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (2, "огурец", "крупный", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (3, "огурец", "зеленый", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (4, "помидор", "красный", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (5, "помидор", "на веточке", DATE())
INSERT INTO tovar (ID, nam, op, datap) VALUES (6, "помидор", "битый", DATE())
SELECT 0
CREATE CURSOR kol (ID I, nam C(20), ITOGO I) && количества товаров в магазине, без учета подробностей товара (без поля tovar.op)
INSERT INTO kol (ID, nam, itogo) VALUES (1, "огурец", 100)
INSERT INTO kol (ID, nam, itogo) VALUES (2, "помидор", 200)
* Нужна такая же таблица tovar, но с дополнительной колонкой ITOGO, проставленной в любой строке соответствующего товара
* (в одной строке "огурец", и в одной строке "помидор"), * чтобы сумма по полю ITOGO таблицы давала ITOGO = 100 + 200
SELECT 0
* сейчас сделано так: изготовляем заготовку выходной таблицы (с полем ITOGO, пока оно пустое)
SELECT *, CAST(0 AS I) AS itogo FROM tovar INTO CURSOR titogo READWRITE && добавляем поле ITOGO к tovar
SELECT kol
SCAN && перебираем записи kol, переносим поле kol.itogo в выборку titogo
UPDATE titogo SET itogo=kol.itogo WHERE nam=kol.nam
* это неверно, т.к. заполняются все записи "огурец" полем itogo=100.
* Как записать UPDATE, чтобы он обновлял только единственную запись "огурец" или "помидор" ?
* В реальном примере удавалось усложнением WHERE находить единственную запись, но теперь эта возможность исчезла...
ENDSCAN
SELECT titogo
BROWSE
CLOSE ALL

Может проще будет объединить таблицы:
CREATE CURSOR tovar (ID I,ID1 I,nam C(20),op C(20),datap D,itogo I)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (1,1,"огурец","мелкий",DATE(),0)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (2,1,"огурец","крупный",DATE(),0)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (3,1,"огурец","зеленый",DATE(),0)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (4,2,"Огурцы, всего","",DATE(),100)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (5,1,"помидор","красный",DATE(),0)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (6,1,"помидор","на веточке",DATE(),0)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (7,1,"помидор","битый",DATE(),0)
INSERT INTO tovar (ID,ID1,nam,op,datap,ITOGO) VALUES (8,2,"Помидоры, всего","",DATE(),200)
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
> Серьёзные постановщики просто не делают неподходящих под задачу структур данных - а если по недостатку информации сначала и делают, то потом при помощи перепроектирования, т.е. рафакторинга этот недостаток устраняют. И им попросту никогда не требуется "обновить одну запись из кучи почти одинаковых".

Мы не серьезные постановщики (постановщиков у нас нет), структуры данных сложились давно, менять их малореально, тем не менее "рефакторинг" идет мелкой сапой (иначе бы сидели вобще на FPD, до сих пор ). Структура данного выходного файла (с одной заполненной записью из нескольких) сложилась именно такая, и пока не до ее "рефакторинга". Пока надо удовлетворить ЦБ, лучше бы ЦБ порефакторить, а то занимаюсь только внешней отчетностью (а не реалиями конторы) уже под 100 проц времени. И не овощи считаю, дело шкурное...
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
Лулгу, "обьединить данные" - это как раз цель, то, что и сделал Сергей (ssa). А рождаются данные именно в виде, в котором приведены в моем примере - в двух табличках, рождаемых в разных несвязанных местах.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
of63
Думаешь, что я задаю идиотские вопросы, потому что идиот, или потому, что не решил, или потому что зациклилcя на FPD, или потому что поленился прочитать ваши простые решения, или не в курсе про ID и зачем оно...
Я ничего не думаю, я констатирую факт.
Цитата:
Просто хотел поделиться с коллегами интересной деталькой в SQL (что "не может запросто сделать элементарное"),
Элементарное - это решить за тебя как разрушить базу? А не в SQL как это ЭЛЕМЕНТАРНО делается? ГДЕ и КАК не в SQL делается обновление одной случайной записи и при этом не ты решаешь какую именно менять?
Цитата:
да и на людей посмотреть, как они выглядят для спрашивающего, на форуме друзей
То есть еще и поиздеваться на отвечающими? Хорош друг на форуме друзей...

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
of63
Мы не серьезные постановщики (постановщиков у нас нет), структуры данных сложились давно, менять их малореально, тем не менее "рефакторинг" идет мелкой сапой (иначе бы сидели вобще на FPD, до сих пор ). Структура данного выходного файла (с одной заполненной записью из нескольких) сложилась именно такая, и пока не до ее "рефакторинга". Пока надо удовлетворить ЦБ, лучше бы ЦБ порефакторить, а то занимаюсь только внешней отчетностью (а не реалиями конторы) уже под 100 проц времени. И не овощи считаю, дело шкурное...
И, как обычно, пошли отмазы одна за другой... Может потому и так много занимает отчетность, что все держишь в том виде, при котором приготовление отчетности превращается в сплошной геморрой? Ведь и твой изначальный вопрос возник из приготовления отчетности, не так ли? И приготовление её в твоем виде и есть большой геморрой и тормоза. Заметь, это уже не вопрос, а утверждение. Ибо даже на таком небольшом куске кода сколько было выкинуто ненужного и тормозящего. И показан один из вариантов ускорения и упрощения. Но воз и ныне там...

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
> Я ничего не думаю, я констатирую факт.
Факт какой именно? ) А констатировать - это всем можно, я тоже констатирую, что местный народ не равнодушен друг к другу, отвечают, советуют, убеждают и убеждаются. А какой именно факт фиксирует каждый - это не самое главное.

> Элементарное - это решить за тебя как разрушить базу? А не в SQL как это ЭЛЕМЕНТАРНО делается? ГДЕ и КАК не в SQL делается обновление одной случайной записи и при этом не ты решаешь какую именно менять?
"База" не разрушается. Цель - получить файл в том формате, в котором заказано (в произвольной похожей записи заполнить поле "итого"), отдать этот файл на сторону, и забыть про него, главное, чтобы сумма в поле ИТОГО сошлась, в т.ч. по огрубленной категории (по огурцам и по помидорам)

> То есть еще и поиздеваться на отвечающими? Хорош друг на форуме друзей...
В первом посте, собственно в вопросе, я и не думал издеваться, но и ответ был не особо нужен, и нужную выборку я могу получить далеко не одним способом, в т.ч. и твоим (но, вру, SELECT внутри SELECT, промежуточные таблички, не применял, это как программу писать не в нескольких строках, а в одной строке... возьму на вооружение, что не надо стесняться вместо реальных Алисов применять промежуточные SELECT-ы же. Кстати, ИК обьяснил, на моем примере, про WITH, это дорогого стОит, а то пишут на других форумах форумах SQL-WITH, я не понимаю).
Да. Так издеваться и и не думал, и не издевался в ходе процесса выяснения (назначения ID и кто дурак), но на простой вопрос я понял, что вопрос не понят. Без простого рабочего примера нефик соваться сюда с вопросами. Это мне урок

Доб.
> И, как обычно, пошли отмазы одна за другой... Может потому и так много занимает отчетность, что все держишь в том виде, при котором приготовление отчетности превращается в сплошной геморрой? Ведь и твой изначальный вопрос возник из приготовления отчетности, не так ли? И приготовление её в твоем виде и есть большой геморрой и тормоза. Заметь, это уже не вопрос, а утверждение. Ибо даже на таком небольшом куске кода сколько было выкинуто ненужного и тормозящего. И показан один из вариантов ускорения и упрощения. Но воз и ныне там...

Не грузи перегружай. Делаю как могу, не домысливай, "каждая семья несчастна по-своему"



Исправлено 1 раз(а). Последнее : of63, 24.03.18 14:40
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
of63
Элементарное - это решить за тебя как разрушить базу? А не в SQL как это ЭЛЕМЕНТАРНО делается? ГДЕ и КАК не в SQL делается обновление одной случайной записи и при этом не ты решаешь какую именно менять?
"База" не разрушается. Цель - получить файл в том формате, в котором заказано (в произвольной похожей записи заполнить поле "итого"), отдать этот файл на сторону, и забыть про него, главное, чтобы сумма в поле ИТОГО сошлась, в т.ч. по огрубленной категории (по огурцам и по помидорам)
"Получить файл в нужном формате" и "в произвольной похожей записи заполнить поле "итого" - это разные задачи. Как решить первую тебе показали. Вторая - один из способов решения первой задачи. И вот как раз этот способ ты назвал элементарным. Вот и покажи как не в SQL это элементарно делается.

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: SQL-UPDATE "первой" записи
of63
Автор

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
заменяем это
SELECT kol
SCAN && перебираем записи kol, переносим поле kol.itogo в выборку titogo
UPDATE titogo SET itogo=kol.itogo WHERE nam=kol.nam
* это неверно, т.к. заполняются все записи "огурец" полем itogo=100.
* Как записать UPDATE, чтобы он обновлял только единственную запись "огурец" или "помидор" ?
* В реальном примере удавалось усложнением WHERE находить единственную запись, но теперь эта возможность исчезла...
ENDSCAN

на это
SELECT kol
SCAN && перебираем записи kol, переносим поле kol.itogo в выборку titogo
* UPDATE titogo SET itogo=kol.itogo WHERE nam=kol.nam && это заменяем на:
SELECT titogo
LOCATE FOR nam=kol.nam && не проверяем на наличие запись (все записи есть в моем случае), в твоем случае надо посмотреть, не потеряются ли записи
IF FOUND()
REPLACE itogo WITH kol.itogo
ELSE
* тут приходится добавлять в выходнй файл эмулированную запись,
* чтобы не напугать прверяющи, но в это место программа попадать не должна
* и это место тоже надо бы включать в код (в данном случае в ваш SELECT, в виде UDF чтоли... в фоксовом способе общения с БД все просто...)
ENDIF
SELECT kol
ENDSCAN
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 22 (Гостей: 22)

© 2000-2024 Fox Club 
Яндекс.Метрика