Re: SQL-UPDATE "первой" записи | |
---|---|
sphinx Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Пашк, ты авторитетный товарищ, тебя он должен услышать. Я пытался, хоть и не гуру.. p.s. Так-то это зло работать с ненормированными таблицами, да еще с "ограничением", что суррогатный ключ не нужен. ------------------ "Veni, vidi, vici!"(с) |
Re: SQL-UPDATE "первой" записи | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
Можно привести постановку задачи, когда сама структура хранения не нарушает принципов реляционной БД. А тем не менее, необходимость в таком вопросе возникает. Бухгалтер поставила задачу: в документе счёт необходимо сумму, введённую в шапке документа распределить пропорционально себестоимости (количеству, без разницы) продаваемого товара. При этом, в каждой строке сумма должна быть округлена до двух знаков. Накопленную ошибку округления необходимо отнести на самую большую сумму. Ну, а в процессе решения мы встречаем документ с двумя одинаковыми по размеру максимальными суммами. И да, записи в таблице прекрасно друг-от-друга отличаются. А с точки зрения постановки задачи, без разницы, куда сносить, но на одну строку. |
Re: SQL-UPDATE "первой" записи | |
---|---|
sphinx Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Думаю да (не проверял). Но что мешает упорядочить? К тому же по критерию, который автор задачи знает? ------------------ "Veni, vidi, vici!"(с) |
Re: SQL-UPDATE "первой" записи | |
---|---|
sphinx Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Пашк, привет!
Да я тот же самый вопрос Олегу задавал (ну право, даже не потерли, повода нет)... Задачи с его данными нет. Мое решение (его и другие участники поддержали, короче/проще вроде нет). Ан нет - ему хочется и без уникальных ключей, и формировать их не хочет, и антиреляционное использование номера записи - не подходит. Работает с ненормализованными данными, без уникального ключа записи... А еще что-то требует и обвиняет коллег в тупизне. Пфффф... ------------------ "Veni, vidi, vici!"(с) |
Re: SQL-UPDATE "первой" записи | |
---|---|
sphinx Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Да и то выберут ему нужное. ;)
Ну ведь прошу - ну кинь сюда такой супер-пупер набор записей , посмотрим. ------------------ "Veni, vidi, vici!"(с) |
Re: SQL-UPDATE "первой" записи | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Нет, и не нужно. "Отобранных произвольно" - это ошибка использования опции. СУБД может и не позволить такой "произвольности". Для варианта "выбора" имеет смысл упорядочение, и имеет некоторый смысл ограничение "по количеству/объёму отобранных записей". Это (ограничение по "количеству записей") отход от реляционного принципа - но он вполне удобен, так же как и некоторым образом связанный механизм "пейджинга" - т.е. отбора "первые 20", потом "следующие 20" и т.д. Update в отличие от Select не "возвращает записи пользователю" - и работает над ВСЕМ массивом записей подходящих под условие. Более того, в нормальной СУБД он ещё и атомарно выполняется - т.е. обновит либо ВСЕ подходящие, либо ни одной. На "полпути" он никогда не остановится (увы, фоксу тут жирный минус - даже его транзакция не даёт гарантии). Потому для update не имеют смысла ни "ограничение количества обрабатываемых записей" ни "порядок обработки". По id - это же очевидно Или по одному из его суррогатов (типа recno(), rowid), если создатель таблицы был настолько неадекватен, что иных "различий" в записях нет. Как они "выберут" этот самый id - это вопрос личных предпочтений, и наличия в БД связей (т.к. может уже на "накладную" повешено 100500 документов, проводок, да и собственно "строк" с товарами - это ограничивает возможности по изменению записи - не физически, а "логически", чтобы не сделать ещё хуже). Для "несвязанных" элементов лично я удалил бы запись с большим id - т.к. обычно id наращиваются, а значит запись с "большим id" была создана позже - тогда как надо было бы вместо создания эту раннюю использовать. А чтобы этого (возникновения "двух одинаковых накладных") не происходило, то в БД добавляют ключи-кандидаты (они же уникальные индексы) - они как раз и не дадут ввести ещё одну накладную с тем же "номером", решая проблему ДО её возникновения с БД ------------------ WBR, Igor |
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Ответ я уже получил, очевидный, что TOP 1 опции нет, я и сам видел, что ее нет, в хелпе на UPDATE.
Но все же, чтобы удостовериться в своей тупизне и продвинутости дба-шников, нарисовал пример, похожий на мою задачу. Как бы вы записали UPDATE в этом примере, чтобы он обновлял единственную любую запись среди группы "неразличимых"? (структуру выходного файла не менять, идей по его более правильному устройству не предлагать, ID я приделал по вашим настойчивым просьбам, теперь она стала тру-базой, реально ID нет, да он и не нужен в данном случае)
|
Re: SQL-UPDATE "первой" записи | |
---|---|
ssa Сообщений: 12999 Откуда: Москва Дата регистрации: 23.03.2005 |
Но все равно, с упорством, достойным лучшего применения, будем упираться именно в UPDATE? Цитата:Ппц.. Ты еще только формируешь условия задачи, но уже знаешь что нужно/не нужно для её решения? Далее твой слегка переделанный код. Оцени сколько в нем совершенно ненужного. MAX(ID), при желании, можешь заменить на свою любую.
------------------ Лень - это неосознанная мудрость. |
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
> Но все равно, с упорством, достойным лучшего применения, будем упираться именно в UPDATE?
Мы не упираемся, просто хотим посмотреть, как этот UPDATE (или в хитром SELECT-е), но не фоксовыми операторами LOCATE, RELATION...) делают серьезные бородатые админы БД. > Оцени сколько в нем совершенно ненужного Оценил Позволил себе переформатировать, вынести за скобки части выражения, иначе вообще не могу прочитать. Идея-то понятная "в группе 'одинаковых' записей выберем ее единственный ID по признаку MAX(ID)", но многоуровневость, два join-а, промежуточная выборка t2, изложения в твоем SELECT "убивает". Неужели проще на SQL не выражается, этот заменитель "UPDATE TOP 1"...
|
Re: SQL-UPDATE "первой" записи | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Серьёзные постановщики просто не делают неподходящих под задачу структур данных - а если по недостатку информации сначала и делают, то потом при помощи перепроектирования, т.е. рафакторинга этот недостаток устраняют. И им попросту никогда не требуется "обновить одну запись из кучи почти одинаковых".
В принципе в новых диалектах SQL есть синтаксис с факторизацией подзапросов (как раз для улучшения "понимания" многоуровневого кода - иногда и для улучшения его работы). Примерно это будет выглядеть так:
------------------ WBR, Igor |
Re: SQL-UPDATE "первой" записи | |
---|---|
ssa Сообщений: 12999 Откуда: Москва Дата регистрации: 23.03.2005 |
Тебе уже не раз написали - твой вопрос некорректен и в такой постановке никак он не решается. Какое слово непонятно? Цитата:Во-первых, ты опять со своим идиотским UPDATE TOP 1. Во-вторых, это не сложный запрос, а всего лишь твое слабое кун-фу в части запросов. В-третьих, код конкретно под предоставленные тобой код и данные. И сформулирован так, чтобы ты мог понять его. Хотя все можно было сделать и без подзапросов. И в-четвертых, тебе приводили более простые варианты. Но, похоже, ты так их и не понял. Как и то, что зациклившись на своих таких привычных еще доFPD-шных подходах к работе с данными ты сам себя загнал в тупик и вынужден теперь задавать идиотские вопросы. ------------------ Лень - это неосознанная мудрость. |
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Думаешь, что я задаю идиотские вопросы, потому что идиот, или потому, что не решил, или потому что зациклилcя на FPD, или потому что поленился прочитать ваши простые решения, или не в курсе про ID и зачем оно... Просто хотел поделиться с коллегами интересной деталькой в SQL (что "не может запросто сделать элементарное"), да и на людей посмотреть, как они выглядят для спрашивающего, на форуме друзей
|
Re: SQL-UPDATE "первой" записи | |
---|---|
lulgu Сообщений: 1838 Дата регистрации: 30.11.2016 |
Может проще будет объединить таблицы:
|
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
> Серьёзные постановщики просто не делают неподходящих под задачу структур данных - а если по недостатку информации сначала и делают, то потом при помощи перепроектирования, т.е. рафакторинга этот недостаток устраняют. И им попросту никогда не требуется "обновить одну запись из кучи почти одинаковых".
Мы не серьезные постановщики (постановщиков у нас нет), структуры данных сложились давно, менять их малореально, тем не менее "рефакторинг" идет мелкой сапой (иначе бы сидели вобще на FPD, до сих пор ). Структура данного выходного файла (с одной заполненной записью из нескольких) сложилась именно такая, и пока не до ее "рефакторинга". Пока надо удовлетворить ЦБ, лучше бы ЦБ порефакторить, а то занимаюсь только внешней отчетностью (а не реалиями конторы) уже под 100 проц времени. И не овощи считаю, дело шкурное... |
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Лулгу, "обьединить данные" - это как раз цель, то, что и сделал Сергей (ssa). А рождаются данные именно в виде, в котором приведены в моем примере - в двух табличках, рождаемых в разных несвязанных местах.
|
Re: SQL-UPDATE "первой" записи | |
---|---|
ssa Сообщений: 12999 Откуда: Москва Дата регистрации: 23.03.2005 |
Я ничего не думаю, я констатирую факт. Цитата:Элементарное - это решить за тебя как разрушить базу? А не в SQL как это ЭЛЕМЕНТАРНО делается? ГДЕ и КАК не в SQL делается обновление одной случайной записи и при этом не ты решаешь какую именно менять? Цитата:То есть еще и поиздеваться на отвечающими? Хорош друг на форуме друзей... ------------------ Лень - это неосознанная мудрость. |
Re: SQL-UPDATE "первой" записи | |
---|---|
ssa Сообщений: 12999 Откуда: Москва Дата регистрации: 23.03.2005 |
И, как обычно, пошли отмазы одна за другой... Может потому и так много занимает отчетность, что все держишь в том виде, при котором приготовление отчетности превращается в сплошной геморрой? Ведь и твой изначальный вопрос возник из приготовления отчетности, не так ли? И приготовление её в твоем виде и есть большой геморрой и тормоза. Заметь, это уже не вопрос, а утверждение. Ибо даже на таком небольшом куске кода сколько было выкинуто ненужного и тормозящего. И показан один из вариантов ускорения и упрощения. Но воз и ныне там... ------------------ Лень - это неосознанная мудрость. |
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
> Я ничего не думаю, я констатирую факт.
Факт какой именно? ) А констатировать - это всем можно, я тоже констатирую, что местный народ не равнодушен друг к другу, отвечают, советуют, убеждают и убеждаются. А какой именно факт фиксирует каждый - это не самое главное. > Элементарное - это решить за тебя как разрушить базу? А не в SQL как это ЭЛЕМЕНТАРНО делается? ГДЕ и КАК не в SQL делается обновление одной случайной записи и при этом не ты решаешь какую именно менять? "База" не разрушается. Цель - получить файл в том формате, в котором заказано (в произвольной похожей записи заполнить поле "итого"), отдать этот файл на сторону, и забыть про него, главное, чтобы сумма в поле ИТОГО сошлась, в т.ч. по огрубленной категории (по огурцам и по помидорам) > То есть еще и поиздеваться на отвечающими? Хорош друг на форуме друзей... В первом посте, собственно в вопросе, я и не думал издеваться, но и ответ был не особо нужен, и нужную выборку я могу получить далеко не одним способом, в т.ч. и твоим (но, вру, SELECT внутри SELECT, промежуточные таблички, не применял, это как программу писать не в нескольких строках, а в одной строке... возьму на вооружение, что не надо стесняться вместо реальных Алисов применять промежуточные SELECT-ы же. Кстати, ИК обьяснил, на моем примере, про WITH, это дорогого стОит, а то пишут на других форумах форумах SQL-WITH, я не понимаю). Да. Так издеваться и и не думал, и не издевался в ходе процесса выяснения (назначения ID и кто дурак), но на простой вопрос я понял, что вопрос не понят. Без простого рабочего примера нефик соваться сюда с вопросами. Это мне урок Доб. > И, как обычно, пошли отмазы одна за другой... Может потому и так много занимает отчетность, что все держишь в том виде, при котором приготовление отчетности превращается в сплошной геморрой? Ведь и твой изначальный вопрос возник из приготовления отчетности, не так ли? И приготовление её в твоем виде и есть большой геморрой и тормоза. Заметь, это уже не вопрос, а утверждение. Ибо даже на таком небольшом куске кода сколько было выкинуто ненужного и тормозящего. И показан один из вариантов ускорения и упрощения. Но воз и ныне там... Не Исправлено 1 раз(а). Последнее : of63, 24.03.18 14:40 |
Re: SQL-UPDATE "первой" записи | |
---|---|
ssa Сообщений: 12999 Откуда: Москва Дата регистрации: 23.03.2005 |
"Получить файл в нужном формате" и "в произвольной похожей записи заполнить поле "итого" - это разные задачи. Как решить первую тебе показали. Вторая - один из способов решения первой задачи. И вот как раз этот способ ты назвал элементарным. Вот и покажи как не в SQL это элементарно делается. ------------------ Лень - это неосознанная мудрость. |
Re: SQL-UPDATE "первой" записи | |
---|---|
of63 Автор Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
заменяем это
на это
|
© 2000-2024 Fox Club  |