select distinct ...

← →
сергей1 (2004-09-19 11:58) [40]

а что, программа считает проходы между воротами в гонках Формула1 ? какой смысл оптимизировать на скорость записи, если запись производится не чаще, чем раз в минуту ? (если я правильно понял задачу). и udp зачем тогда, tcp-ip здесь явно лучше. а вдруг в течении минуты 2 машины заедет ? по ходу дела, твоя программа нарисует 2 одинаковые строчки, все по-прежнему будут счастливы ?

а вообще, я-же писал, что базы, которым лучше без ключа, есть, но очень мало, и если-уж делать РСУБД, так по правилам, Кодд и др. не зря являются мировыми авторитетами, и считать себя умнее его просто смешно

← →
sniknik © (2004-09-19 12:19) [41]

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

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

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

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

← →
сергей1 (2004-09-19 12:51) [42]

любые задачи имеют множество решений, работает данный вариант - отлично, я что, против ?
просто может в данном случае, если надо всего-лишь посчитать количество проходов за минуту, я бы сделал например так : программа ловит пакеты udp, сама считает время, и по окончании минуты заносит в БД единственную запись - т.е. напр. 13.45 м. - 87 проходов. получилась бы такая таблица :

время кол-во проходов
12.30 45
12.31 88
12.32 0

и т.д.
вот здесь-бы уже мой любимый PK пригодился-бы :)

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

>да меня уволят сразу же после такого заявления)

уволят, если придя проектировать базу ты заявишь, что обладаешь более лучшей теорией БД, а Кодд - ну кто он такой, подумаешь жалкий америкашка, они там вообще негров линчуют !

← →
sniknik © (2004-09-19 19:49) [43]

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

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

← →
Deniz © (2004-09-20 07:39) [44]

> 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-20 08:15) [45]

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

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

← →
Deniz © (2004-09-20 09:39) [46]

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

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

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

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

← →
sniknik © (2004-09-20 10:53) [47]

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

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

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

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

← →
Johnmen © (2004-09-20 12:02) [48]

>Deniz © (19.09.04 08:26) [36]

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

← →
Deniz © (2004-09-20 14:11) [49]

> 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 14:29) [50]

>Deniz © (20.09.04 14:11) [49]

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

← →
sniknik © (2004-09-20 14:41) [51]

> У меня вопрос, этот эмулятор 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 и возник. что можно так.
и потом нужно ли? оно недокументировано.

← →
xmrz (2004-09-20 19:12) [52]

А по-моему тебе поможет и

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

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

← →
sniknik © (2004-09-20 20:17) [53]

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

← →
Fay © (2004-09-20 21:34) [54]

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

← →
sniknik © (2004-09-20 22:20) [55]

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

>> может это описка
Да запросто! 8) Просто не ожидал.

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

← →
Igor_P (2004-09-20 23:06) [57]

Хотелось бы вернуться к исходному вопросу, что бы кто-нибудь разъяснил, почему не отработал DISTINCT? Или DISTINCT применяется только если в операторе SELECT указывается одно поле?

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

← →
xmrz (2004-09-21 09:39) [59]

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

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

← →
-SeM- (2004-09-21 10:34) [61]

сергей1 (19.09.04 11:58) [40]

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

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

sniknik © (20.09.04 14:41) [51]

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

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

Deniz © (20.09.04 14:11) [49]

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

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

> Без PK все решения - кривые
да нет же! опять по новой ;(. достаточно знать чем "грозит" его отсутствие, плюсы, минусы (фактически только один, небольшое замедление добавлений к таблице (увеличение размера на одно поле при нынешних дисках считать недостатком смешно ;)), характер данных (что с ними будут делать).
и можно использовать (вернее не использовать PK), если так лучше.

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

select distinct ... Найти похожие ветки