> >Кщд   (29.11.10 08:46) [14]>пора бы задуматься об уникальном
> идентификаторе записи или - как >минимум - сменить тип поля
> на timestampв конце концов, если добавить/сменить тип поля
> в исходной таблице нет возможности, повесить триггер, котором
> писать сумму остатка с уникальным идентификатором в свою
> таблицу

я не разработчик этой системы, я не имею право вносить в нее изменения, такие изменения вообще мало кто имеет право вносить, каждое вносимое изменение производится по приказу, и принимается по протоколу приемо-сдаточных испытаний, кому нить вы думаете нужен такой головяк из-за моей локальной задачки?


> >Понимаю, поэтому буду выполнять 1 рази получать случайное
> значение из таблицыбессмысленная работа

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

> [18] xmen   (29.11.10 12:43)
> Понимаю, поэтому буду выполнять 1 раз :-)

Глупость, хоть и смайлик.

Уникальность записи скорее всего есть, только как она реализована и возможно ли определить временнУю последовательность этих проводок == записей.
> [11] xmen   (26.11.10 10:22)
> Дата и время проводки

А это не таймштамп, только показаный в таком виде?

> Глупость, хоть и смайлик.

человеку свойственно совершать глупости, более того иногда чтобы совершать глупости он пьет и курит :-)


> А это не таймштамп, только показаный в таком виде?

Не в курсе.
У меня есть клиентский модуль, я также знаю, что где-то далеко (в Ростове-на-Дону) есть сервер, где замещена база.
Для подключения к базе чере клиентский модуль есть имя пользователя и пароль.
Вся моя работа и работа моего подразделения связана с выборкой данных и их анализом, поэтому у меня есть доступ только к представлениям и отчетам.
Разработчики клиентского модуля сделали очень хорошую кнопочку позволяющую посмотреть текст sql запроса направляемого в БД, все запросы обращаются к представлениям, ни один напрямую к таблице не обращается.

Исходный запрос формирующий выборку имеет следующий вид:



Какие там поля я не в курсе, я впринципе не очень селен в Oracle, когда я изучал запросы мы почему-то это делали на Paradox, с тех пор много воды утекло, и по жизни я занимаюсь немного другой работой.

Какой-то ID есть, но что в нём и какое отношение к данным имеет, сурогат наверно, хоть может быть целым и последовательно возрастать, например, тогда можно и, то может быть, к нему привязаться MIN(id).

Если непонятна последовательность, то, в свете "такую работу нужно делать либо вручную, либо как-то ее автоматизировать", правильно будет выбирать не какую попало, а все записи с одинаковым наименьшим временем и смотреть глазами какие там лишние. А вот как смотреть, кстати? Тут вдруг окажется, что есть таки некий критерий выбора правильной записи.

Вот, сейчас обратил внимание, на поле C_12, в системе оно обозначено как "Н.п.п.", я так понимаю - это Номер по порядку, соответственно получается можно это поле использовать для определения первой операции.

>xmen   (30.11.10 12:29) [24]

если это ДЕЙСТВИТЕЛЬНО порядковый номер, то
>Кщд   (25.11.10 10:34) [5]

Я взял


> Кщд   (25.11.10 11:16) [6]


вроде бы работает правильно

>xmen   (30.11.10 13:36) [26]
т.е. всё же на каждую строку нужен остаток...

А что нить вроде такого можно:

SELECT
SUBSTRING(  MIN(CONCAT(`datetime`, `rem`))   FROM 19)
FROM `table`
GROUP BY TO_DAYS(`datetime`)

Прошу прощения за синтаксис mysql, других не знаю.

>Дмитрий С ©   (07.12.10 07:18) [28]
простите, но это ахинея
1. этот запрос не имеет отношения к Oracle;
2. работа с датой как со строкой чревата известным удивлением в случае со сменой локали;
3. минимальный остаток на дату - не то, что нужно автору. ему нужен ПЕРВЫЙ - что явствует из ветки обсуждения;
4. первый остаток на дату необходимо выводить для КАЖДОЙ записи.

> 3. минимальный остаток на дату - не то, что нужно автору.
>  ему нужен ПЕРВЫЙ - что явствует из ветки обсуждения;

Мой запрос это и выводит.


> 1. этот запрос не имеет отношения к Oracle;
> 2. работа с датой как со строкой чревата известным удивлением
> в случае со сменой локали;

Про mysql предупредил. Там с локалью проблем не будет. К тому же их можно заменить полем id, если оно одновременно возрастает с датой.


> 4. первый остаток на дату необходимо выводить для КАЖДОЙ
> записи.

Уж это доделать не так сложно, я просто известный принцип выразил.

>Дмитрий С ©   (07.12.10 09:21) [30]
>Мой запрос это и выводит.
разницу между минимальным на дату и первым во времени на дату представляете?

>К тому же их можно заменить полем id, если оно одновременно возрастает с датой.
никогда нельзя закладываться на порядок следования id(если мы про PK)
ID - это уникальный идентификатор, необходимый для поддержания ссылочной целостности
он нужен только(!) для этого

>Про mysql предупредил.
а смысл, если речь про Oracle и всеми участниками ветки даны исчерпывающие ответы, притом для Oracle?

>Там с локалью проблем не будет.
ничем не отличается от других СУБД
google: mysql locale date
подобная небрежность в обращении с локалезависимыми сущностями выходит "боком"
всегда

>Уж это доделать не так сложно, я просто известный принцип выразил.
здесь нечего доделывать
Ваш запрос не соответствует условиям автора и не вернет нужного результата ни в MySQL, ни - тем более - в Oracle

> разницу между минимальным на дату и первым во времени на
> дату представляете?

А вы? Проанализируйте еще раз запрос.


> никогда нельзя закладываться на порядок следования id(если
> мы про PK)
> ID - это уникальный идентификатор, необходимый для поддержания
> ссылочной целостности
> он нужен только(!) для этого

Я же уточнил "если оно одновременно возрастает с датой". Почему этим нельзя пользоваться? Кто решает что можно или нельзя?


> а смысл, если речь про Oracle и всеми участниками ветки
> даны исчерпывающие ответы, притом для Oracle?

Места на форуме что-ли жалко? Ответы даны, я рад, почему бы не внести разнообразия. Форум ведь и в поиске находят, мало ли полезно кому будет.


> ничем не отличается от других СУБД
> google: mysql locale date
> подобная небрежность в обращении с локалезависимыми сущностями
> выходит "боком"
> всегда

В MySQL даты (время), когда используются в строковом контексте, приводятся к виду гггг-мм-дд чч:мм:сс. Что и позволяет сортировать по ним.


> Ваш запрос не соответствует условиям автора и не вернет
> нужного результата ни в MySQL, ни - тем более - в Oracle

Ну это вам так кажется..., что вы умнее всех.
Прошу прощения за переход на личности.

>Дмитрий С ©   (07.12.10 10:25) [32]
>А вы? Проанализируйте еще раз запрос.
согласен, поторопился

>Я же уточнил "если оно одновременно возрастает с датой". Почему этим нельзя пользоваться? Кто решает что можно или нельзя?
перед тем, как работать с базой, рекомендую как минимум К. Дж. Дейт "Введение в системы баз данных". Объяснять азы - занятие кропотливое и ответственное. Чувства ответственности перед Вами не питаю.
Для примера поразмышляйте о ситуации:
1. стартует транзакция А;
2. А вставляет строку - отщелкнули ID;
3. стартует транзакция Б;
4. Б вставляет строку - отщелкнули ID2 (ID2 > ID, если автоинкремент);
5. транзакция Б подтверждается(commit);
6. транзакция А подтверждается;
какую запись считать первой?
та, которая была раньше вставлена(А) или подтверждена(Б)?

кроме прочего, существует такие вещи как кэширование sequence(что актуально как раз для Oracle).

>Ответы даны, я рад, почему бы не внести разнообразия.
разнообразие - это просто отлично
но только тогда, когда качественно
Ваш код не отвечает условиям автора и неэффективен для решения его задачи
если покажете решение, на основе Вашего запроса, которое выдает результат за один проход по таблице - принесу извинения и покаюсь

>Ну это вам так кажется..., что вы умнее всех.
покажите вывод консоли MySQL по Вашему запросу на данных автора
запрос прост. то, что он выдает чепуху, очевидно
из этого не следует, что я умнее всех - лишь то, что Вы некомпетентны в данном вопросе

Лан. прекращаем.