Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

select distinct ... [D7, IB6.x]

Страницы: 1 2 3 4 >
3APA3A © (2004-09-16 20:31:00)
Есть таблица -
CREATE TABLE (ID INTEGER, REC_COUNT INTEGER);

Если я пишу просто SELECT DISTINCT ID, REC_COUNT FROM TABLE1, то он выбирает мне (для примера) такую таблицу
ID REC_COUNT
1 3
1 4
1 6
2 1
2 3
4 2

А мне надо
ID REC_COUNT
1 3, 4, 6 (любое из этих значений)
2 1, 3 (то же самое)
4 2

Каким запросом можно это сделать?

sniknik (2004-09-21 10:51:00) [1]
> Без PK все решения - кривые
да нет же! опять по новой ;(. достаточно знать чем "грозит" его отсутствие, плюсы, минусы (фактически только один, небольшое замедление добавлений к таблице (увеличение размера на одно поле при нынешних дисках считать недостатком смешно ;)), характер данных (что с ними будут делать).
и можно использовать (вернее не использовать PK), если так лучше.

согласен, в основномон нужен, даже если поначалу кажется что нет, но при четком ТЗ и явном перевесе минусов перед плюсами в конкретной задаче, почему нельзя не использовать? пример такого приводил.

-SeM- (2004-09-21 10:34:00) [2]
сергей1 (19.09.04 11:58) [40]

> что базы, которым лучше без ключа, есть, но очень мало

Ой ли ;) А посмотреть в системные таблицы любойбазы

sniknik © (20.09.04 14:41) [51]

> товарищ видать "отключился"

Ага, так и есть.

Deniz © (20.09.04 14:11) [49]

> Вот именно об этом я и спрашивал, как? Если знаешь расскажи

На уровне базы скажу честно - не знаю. А вот в приложении с использованием FIBPlus 5.3 работает.

Johnmen (2004-09-21 09:48:00) [3]
>xmrz (21.09.04 09:39) [59]
>...
>наиболее красивое "решение".

А это красивей sniknik © (16.09.04 23:53) [9]
:)))

xmrz (2004-09-21 09:39:00) [4]
sniknik © (20.09.04 20:17) [53]
Вопрос стоял именно о выборке, по этому
SELECT MAX(REC_COUNT), ID FROM TABLE1 GROUP BY ID
наиболее красивое "решение". Удаление, как писал автор вопроса будет происходить как DELETE FROM TABLE1.

>>как удалить 2-е и 3-е из 4х повторяющихся,
если такая потребность возникнет, то это уже, согласен, ошибка проектирования. Без PK все решения - кривые

sniknik (2004-09-20 23:56:00) [5]
> Хотелось бы вернуться к исходному вопросу, что бы кто-нибудь разъяснил, почему не отработал DISTINCT?
почему не отработал? отработал, и отбирает уникальность он по всем указаным в запросе полям.
но если действительно вернутся к вопросу то нужна уникальность по одному полю, значение же по второму получается неопределенным. (критерий отбора)
частично решается (граничные min/max, и это подошло т.к. указано что ему все равно какое), а вот значения между ними, в середине получаются неотбираемы (значение второго поля как бы неизвестно), опять таки с оговоркой, можно выбрать если все скопом а вот позиционно неполучается (по определению в SQL серверах позиция записи неопределена).
но это если в общем о серверах, а в конкретике есть разные документированные или нет особенности конкретного sql сервера которые вроде бы позволяют аресоваться к позиции но..., в данном конкретном случае нет возможности работать с этой позицией как с числом (у меня не получается) и насколько понимаю это не автоинкремент (необязательно возрастает) поэтому данная возможность адресоваться к позиции только кажующаяся, на самом деле она только усложняет все... (в этом конкретном случае, т.к. для связок/самообьеденений вполне подходит)
ну вот в общемто и все, по вопросу. ;о))

Igor_P (2004-09-20 23:06:00) [6]
Хотелось бы вернуться к исходному вопросу, что бы кто-нибудь разъяснил, почему не отработал DISTINCT? Или DISTINCT применяется только если в операторе SELECT указывается одно поле?

Fay (2004-09-20 22:42:00) [7]
>> может это описка
Да запросто! 8) Просто не ожидал.

З.Ы.
jack128 только что в "Проблема с ReadDirectoryChangesW" написал "лудше" 8)

sniknik (2004-09-20 22:20:00) [8]
нет я един ;). и я действительно плохо знаю русский язык. (курсов "врожденной" грамотности не заканчивал, и иногда меня "пробивает", хотя стараюсь конечно писать правильно)
а чего придираешся? один случай, может это описка?

Fay (2004-09-20 21:34:00) [9]
2 [53] sniknik © (20.09.04 20:17)
>> лутше
Вы издеваетесь. Или sniknik- псевдоним группы лиц, часть из плохо знает русский язык? 8)

sniknik (2004-09-20 20:17:00) [10]
xmrz (20.09.04 19:12) [52]
это кому? нет ты покажи как удалить 2-е и 3-е из 4х повторяющихся, как было обещано. а лутше из 5 (потому как из четырех всетаки можно думается) или из четырех только одно 3-е к примеру.

xmrz (2004-09-20 19:12:00) [11]
А по-моему тебе поможет и

SELECT MAX(REC_COUNT), ID FROM TABLE1 GROUP BY ID

вместо MAX можно и MIN...

sniknik (2004-09-20 14:41:00) [12]
> У меня вопрос, этот эмулятор 13 тыс посылает за какой период времени? Я так понял в секунду? В твоей же постановке было:
не в секунду но достаточно быстро (читает из текстового файла), и посылает по мере чтения (в 2-3 управляется)

> с лихвой окупает 170. Сам же говорил надо думать про [41]
ну так думай, в тесте имеем один источник в реальности 18, теоретически все 18 могут прийти одновременно, по условию должно записатся максимально возможное число т.е. все 18.
и естественно тест с запасом делается, не может система запаса не иметь. и делался только для того чтобы определить какой метод больше запишет.

> Все. Больше по этому поводу ничего не говорю.
и правильно. переубедить не удастся.

> ... Но вот в запросах (в т.ч. и на удаление) использовать можно...
> Вот именно об этом я и спрашивал, как? Если знаешь расскажи.
товарищ видать "отключился"
использовать не проблема, к примеру
DELETE FROM TODOS b WHERE b.RDB$DB_KEY = (SELECT Max(a.RDB$DB_KEY) FROM TODOS a)
мне не удалось получить его нормальное представление (число вроде бы должно быть, 16байтное (GUID ?)), а как работать если только коственно можно обращатся.
как тогда сделать как описывалось, из четырех повторяющихся к примеру удалить 2 в середине?, понятно глупость раз они повторяются но именно в этом контексте RDB$DB_KEY и возник. что можно так.
и потом нужно ли? оно недокументировано.

Johnmen (2004-09-20 14:29:00) [13]
>Deniz © (20.09.04 14:11) [49]

По поводу RDB$DB_KEY
http://www.ibase.ru/v6/ib6faq.htm
http://www.ibase.ru/devinfo/deldupes.htm

Deniz (2004-09-20 14:11:00) [14]
> sniknik © (20.09.04 10:53) [47]
И зачем так горячится, задел за живое? Извини.
Программку высылать некуда, т.к. почему-то моя анкета грохнулась, но это к делу не относится.
У меня вопрос, этот эмулятор 13 тыс посылает за какой период времени? Я так понял в секунду? В твоей же постановке было:
[41]
всего 18 ворот. можеш посчитать. теоретически количество проходов в минуту очень большое (гдето 120 от одних если идут без задержки)итого 36 в секунду(кто это так шастает), с лихвой окупает 170. Сам же говорил надо думать про [41]
> ... моих местных локальных задачь....
Все. Больше по этому поводу ничего не говорю.

> Johnmen © (20.09.04 12:02) [48]
> Даже не используя RDB$DB_KEY можно удалить все дубликаты и оставить по одному экземпляру записи.
Согласен.
Ключевое слово в моем вопросе с использованием RDB$DB_KEY
-SeM- (18.09.04 11:33) [29]
... Но вот в запросах (в т.ч. и на удаление) использовать можно...
Вот именно об этом я и спрашивал, как? Если знаешь расскажи.

Johnmen (2004-09-20 12:02:00) [15]
>Deniz © (19.09.04 08:26) [36]

Даже не используя RDB$DB_KEY можно удалить все дубликаты и оставить по одному экземпляру записи.

sniknik (2004-09-20 10:53:00) [16]
> Конечно, но по мне, лучше при вставке небольшие тормоза, чем при анализе оооогромные.
анализа как такового нет и не будет(!!!) описывал же условия ;(, в этой базе по крайней мере, чтение редкое (уже писал) даже очень редкое (прим 1раз в месяц, вместе обрезкой паковкой и т.д., делается во время технического перерыва когда основной работе не мешает)

>> ... он идеален для того случая ...
> Не нравятся мне такие выражения.
предложи лутше, в данном случае проще. я тебе даже програмку тест пришлю (эмулятор посылок, просто шлет без паузы пакеты)
так в описаном случае с эмулятора из 13тыс записываются около 1.1тыс записей, а в случае с индексом и минимальным расчетом 170. (это на моей машине которая в 10 раз круче того что там стоит)

> Я просто хотел показать(наверно зря), что не обязательно хранить в памяти и скидывать раз в минуту, но раз ты не хочешь слушать, то и я не
> буду упираться.
я тебя об этом просил? что вообще за манера цеплятся к усеченному данному для примераи негодному для всех остальных случаев, и начинать учить как надо и как не надо в общем?
про обшее то я ничего не говорил, и вовсе не против индексов/ключей в этих случаях.

> ЗЫЖ Думаю на этом наш личный разговор надо прекратить, пока модераторы терпят.
модераторам пофигу пока обсуждается тема, хотя и таким извращенным способом.

Deniz (2004-09-20 09:39:00) [17]
> sniknik © (20.09.04 08:15) [45]
> Deniz © (20.09.04 07:39) [44]
> ты прочитай все, а не последние 2 поста.
Если уж на то пошло, посчитай кол-во моих постов в этом топике, но это уже для основной темы роли не играет.

> ты например знаеш что любой индекс тормозит добавление данных? немного но тормозит.
Конечно, но по мне, лучше при вставке небольшие тормоза, чем при анализе оооогромные.

> ... он идеален для того случая ...
Не нравятся мне такие выражения.

Я просто хотел показать(наверно зря), что не обязательно хранить в памяти и скидывать раз в минуту, но раз ты не хочешь слушать, то и я не буду упираться.
ЗЫЖ Думаю на этом наш личный разговор надо прекратить, пока модераторы терпят.

sniknik (2004-09-20 08:15:00) [18]
Deniz © (20.09.04 07:39) [44]
ты прочитай все, а не последние 2 поста. я там обьяснял что почему и по какой причине выбрано. и выбрано вовсе не причине моей неспособности (вернее того кто писал) написать процедуру...

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

Deniz (2004-09-20 07:39:00) [19]
> sniknik
ПК все равно нужен, и запихать его в тригере перед вставкой нет никаких проблем, а вот по поводу:
> для подсчета придется организовывать массив значений/или потоки для разных ворот и большую часть времени данные будут "висеть" в памяти. т.е. мало того что усложнение так еще и ненадежнее станет.
не согласен(не очень удачный выбор), посмотри http://www.ibase.ru/devinfo/testiu.htmвариант 2 рулит.
В частности можно реализовать типа:
CREATE PROCEDURE SP_INS( номер, дата, время, событие ) AS DECLARE VARIABLE ID INTEGER; DECLARE VARIABLE K INTEGER; BEGIN K=NULL; FOR SELECT ID FROM TABLE_TO_INSERT WHERE (номер, дата, время, событие) INTO :K AS CURSOR TMPCURSOR DO UPDATE TABLE_TO_INSERT T SET T.КОЛ-ВО_ПРОХОДОВ=T.КОЛ-ВО_ПРОХОДОВ + 1 WHERE CURRENT OF TMPCURSOR; IF (K IS NULL) THEN INSERT INTO TABLE_TO_INSERT(ПК, номер, дата, время, событие, КОЛ-ВО_ПРОХОДОВ) VALUES(gen_id(...), номер, дата, время, событие, 1); END;
И ничего в памяти держать не надо ;-)
Да, в принципе, любой вариант из этой статью можно адаптировать под эту структуру
номер, дата, время, событие (проход туда/назад/ошибка), кол-во_проходов

sniknik (2004-09-19 19:49:00) [20]
> сергей1 (19.09.04 12:51) [42]
такой вариант тоже был предложен. но, както не "прижился". ;о)
основания - основное, для подсчета придется организовывать массив значений/или потоки для разных ворот и большую часть времени данные будут "висеть" в памяти. т.е. мало того что усложнение так еще и ненадежнее станет. зачем? чтобы немного размер уменьшить?
> время кол-во проходов
в структуре еще дату и номер ворот забыл. и будет полный аналог. почти. ;о))
там идет так
номер, дата, время, событие (проход туда/назад/ошибка)
все поля числовые (инт). в общем как приходит так и ложится без обработок. (хотя понятно можно и дату "собрать", и еще чегонибудь добавить, но смысла нет)

> уволят, если придя проектировать базу ты заявишь, что обладаешь более лучшей теорией БД ...
я такого не скажу никогда, просто из уважения к чужой работе. но фанатеть от какогото одного метода/теории и поклонятся комулибо тоже не намерен. по моему, если задача только выигрывает от того что отступиш от постулатов то надо их "отодвигать" и делать как надо а не как все считают правильно.

Страницы: 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »