select distinct ...

← →
3APA3A © (2004-09-16 20:31) [0]

Есть таблица -
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

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

← →
GanibalLector © (2004-09-16 20:43) [1]

ИМХО,только через ХП получится.

← →
P.N.P. © (2004-09-16 20:47) [2]

select distinct t.id, (select max(REC_COUNT) from TABLE1 t2 where t2.id=t.id) from TABLE1 t

← →
GanibalLector © (2004-09-16 20:53) [3]

2 P.N.P.
Не работает

← →
Zacho © (2004-09-16 20:54) [4]

Не совсем понятно: а какой смысл в получении непонятно какого значения ?
И какой смысл в таблице без ПК ? Может стоит просто перепроектировать БД/задачу и изучить теорию РСУБД ?

← →
GanibalLector © (2004-09-16 21:15) [5]

Довольно криво,но надеюсь смысл понятен...Сам ужО подправишь
CREATE PROCEDURE fuck RETURNS ( V_ID INTEGER, V_REC INTEGER) AS DECLARE VARIABLE OLD_ID INTEGER; begin old_id=999; for select id,rec_count from table1 into :v_id,:v_rec do begin if (v_id<>:old_id) then suspend ; old_id=v_id; end end
select * from fuck => выдаст желаемый результат

← →
P.N.P. © (2004-09-16 21:25) [6]

//GanibalLector © (16.09.04 20:53) [3]

//2 P.N.P.
//Не работает

Что неработает?
Результат какраз такой, какой нужен (только зачем :))

← →
GanibalLector © (2004-09-16 21:28) [7]

Что неработает?
Пардон,все работает...Ошибся,млин.

← →
3APA3A © (2004-09-16 23:47) [8]

to Zacho
Довольно просто отмазаться от ответа отослав к теории. Дело в том, что БД спроектирована правильно и не совсем ясно, что бы дало наличие ПК.

to GannibalLector
Да я и сделал через ХП. Не совсем так правда, но сделал.

to P.N.P.
Да. О таком запросе я не подумал. Но ХП все равно удобнее получилась... Но на будущее буду иметь в виду такую конструкцию.

Всем спасибо.

← →
sniknik © (2004-09-16 23:53) [9]

> Но на будущее буду иметь в виду такую конструкцию.
имей, но только ввиду! ;о))

select id, max(REC_COUNT) AS REC_COUNT from TABLE1 group by id

← →
3APA3A © (2004-09-17 00:03) [10]

to sniknik
Ваш ответ тоже буду иметь "в виду"... =))

← →
Zacho © (2004-09-17 08:32) [11]

> 3APA3A © (16.09.04 23:47) [8] [Новое
>сообщение][Ответить]
>to Zacho
> Довольно просто отмазаться от ответа отослав к
> теории. Дело в том, что БД спроектирована правильно и
> не совсем ясно, что бы дало наличие ПК.

Это не отмазка, а просто намек на то, что с БД спроектированной не по теории ты получишь многочисленные проблемы.
Если в таблице нет ПК - то БД явно спроектирована неправильно, т.к. не удовлетворяет даже 1НФ. Почитай всё-таки теорию, что бы понять чем это грозит.

Для данной выборки наличие ПК ничем не поможет, зато поможет избежать аномалий в работе с данными.

И всё-таки, ответь (мне действительно интересно), зачем нужно значение из неизвестно какой записи ???

← →
Johnmen © (2004-09-17 09:13) [12]

>3APA3A ©

>>Zacho © (17.09.04 08:32) [11]
>>зачем нужно значение из неизвестно какой записи ???

И мне это чрезвычайно интересно !

← →
Rule © (2004-09-17 10:52) [13]

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

← →
Deniz © (2004-09-17 13:44) [14]

Поддерживаю про необходимость ПК, но приведу пример, где действительно необходимо выбрать из таблицы несколько случайных записей:
Есть список вопросов ~1000, студенту надо задать 5 из них!
Автор неполностью рассказал про задачу(возможно в таблице есть ПК), и поэтому возникли неприятности.

← →
Rule © (2004-09-17 14:22) [15]

Deniz © (17.09.04 13:44) [14]
ну в данном случае получается что надо выбрать в случайном порядке ...

← →
3APA3A © (2004-09-17 14:27) [16]

Да, я на самом деле не совсем так, как в реальности сформулировал задачу, но необходимость в выборе "неизвестно" какого поля действительно есть. Поле REC_COUNT на самом деле - время добавления этой записи, тип у него TIMESTAMP и нужно показывать одно любое время добавления этой записи (поскольку разница у них максимум в 5 минут).
С логической точки зрения - смысла в этом не очень много.
С практической - так хочет заказчик, поскольку ему это очень удобно.

Про ПК не рассказал потому, как не видел, чем они могут помочь в этой задаче (и оказался прав)

Я более-менее (скорее - менее) знаю теорию РСУБД, но в этой таблице мне на самом деле не нужен ПК. Я просто не знаю зачем он мне здесь. Эта таблица никак не связана с другими, на нее также никто не ссылается, в ней всего 2 поля (int, timestamp)Если ПК и в этой ситуации нужен - объясните зачем.

← →
Johnmen © (2004-09-17 14:41) [17]

>3APA3A © (17.09.04 14:27) [16]
>С практической - так хочет заказчик, поскольку ему это очень удобно.

А что именно удобно ? Видеть не пойми чего, не несущее никакой информации ? :)))

← →
3APA3A © (2004-09-17 14:43) [18]

Да нет же. Время отличается максимум на 5 минут и тут уже несущественно - 14:09 или 14:12...

← →
Johnmen © (2004-09-17 14:47) [19]

Теперь понятно.
А ответ уже был sniknik © (16.09.04 23:53) [9]

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

а что вы имеете в виду под абревиатурой ПК?
Персональный компьютер? Почтовый клиент? ...?
обьясни, и я тебе скажу для чего оно может пригодится. ;о)

кстати индекс по id он бы пригодился. (проверь время запроса с группировкой на большом обьеме данных с индексом и без)

← →
3APA3A © (2004-09-17 15:23) [21]

Я подразумевал Первичный Ключ, но только под "аббревиатурой"... =)

← →
kaif © (2004-09-18 01:23) [22]

Разделяю недоумение Zacho и Johnmen-а.
Если эта таблица не нуждается в первичном ключе и никакой задаче, кроме той, что ты говоришь не служит, ни с чем не взаимодействует и никто на нее не ссылается, предлагаю сделать следующее:
1. Удалить все записи с дубликатами ID (Johnmen знает, как это сделать - для меня это черная магия)
2. Добавить первичный ключ на ID командой ALTER TABLE
3. Никогда больше не добавлять туда дубликаты. Все равно извлекать их будет нечем.

← →
3APA3A © (2004-09-18 08:43) [23]

Удалить все записи с дубликатими не так уж и сложно. Суть не в этом. Мне просто интересно - почему Вы так прицепились к этому ПК. Теория РСУБД это конечно хорошо, но
1) Мне не нужен ПК для этой таблицы (или теория велит создавать его даже тогда, когда он не нужен, просто чтобы был?)
2) Мне нужны эти дубликаты, т.к. иногда нужно смотреть все эти записи вместе с дубликатами.

← →
сергей1 (2004-09-18 09:23) [24]

зачем что-то удалять, можно ПК создать как (ID и REC_COUNT), распостраненная ситуация. Ну а ключ, батенька, нужен, если ты проектируешь БД, будь добр придерживаться правил. Иначе в какой-нибудь прекрасный (но не для тебя) момент в базе появиться пара одинаковых записей, и будет это уже не БД, а Х...

← →
sniknik © (2004-09-18 09:49) [25]

> или теория велит создавать его даже тогда, когда он не нужен, просто чтобы был?
нафига нам теория? если считаеш что не нужен не делай.
недостаток (если нет связей/обьеденений/самообьеденений, удалений конкретных полей) только один читать можно только либо все сразу либо неизвестно что.
ну вот в твоей таблице
ID REC_COUNT
1 3
1 4
1 6
2 1
2 3
4 2
практически нет доступа ко 2й позиции с ID = 1, вернее пока есть, пока не появится еще одной записи с ID = 1 и REC_COUNT = 4, и поле в общем потеряет уникальность. тогда и изменить и удалить их можно будет только вместе.
не нужно этого значит и ключа не нужно.

а вот простой индекс как уже говорил не помешал бы, да и то если будеш пользоватся запросом из [9] а не процедурой из [5]. скорость больше будет.
кстати запрос более правильный т.к. в процедура закладывается на порядок получаемых значений, считает что все одинаковые ID будут идти по порядку, а это не обязательно даже если они в таком порядке и записаны...
а если поставить ORDER BY ID, и сделать порядок гарантированным, то тоже индекс бы не помешал бы.

> иначе в какой-нибудь прекрасный (но не для тебя) момент в базе появиться пара одинаковых записей
не повериш но есть много БД с множеством повторяющихся значений и ХД они от этого не стали. ;о)

← →
сергей1 (2004-09-18 10:19) [26]

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

← →
-SeM- (2004-09-18 10:34) [27]

sniknik © (18.09.04 09:49) [25]

> тогда и изменить и удалить их можно будет только вместе

Не верю. Есть еще и RDB$DB_KEY

← →
Deniz © (2004-09-18 11:06) [28]

>
> -SeM- (18.09.04 10:34) [27]
> sniknik © (18.09.04 09:49) [25]
>
> > тогда и изменить и удалить их можно будет только вместе
>
> Не верю. Есть еще и RDB$DB_KEY
А расскажи-ка как ты с ним(RDB$DB_KEY) работаешь?
И например как удалить ОДНУ запись запросом, при условии когда " ... еще одной записи с ID = 1 и REC_COUNT = 4 ..."?

← →
-SeM- (2004-09-18 11:33) [29]

Deniz © (18.09.04 11:06)[28]

RDB$DB_KEY - это фактически указатель на физическое расположение записи в базе. Т.о. жестко привязываться к нему не стоит, так как может поменяться при бекап/ресторе. Но вот в запросах (в т.ч. и на удаление) использовать можно. Добавили в запрос RDB$DB_KEY и получили еще одно (уникальное) поле, по которому ты можешь определить какую из двух записей с одинаковым ID и REC_COUNT нужно удалять.

← →
3APA3A © (2004-09-18 12:35) [30]

to сергей1
Да каких, блин, правил. Ситуация такова
1) Эта таблица не имеет связей с другими
2) Удаляется она только целиком (DELETE FROM TABLE1)
3) В ней могут быть одинаковые записи (бизнес-логикой это не запрещено)
4) Мне нужно просматривать либо вообще все записи либо так, как в subj.
Что говорят правила на этот счет? Нельзя тупо следовать правилам, головой иногда думать надо...

← →
сергей1 (2004-09-18 13:32) [31]

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

← →
kaif © (2004-09-18 13:45) [32]

Так или иначе, если задача формулируется так "выбрать по одному значению для каждого ID", придется иметь индекс по ID (пусть это и не ключ). Или же терпеть тормоз (если это устраивает) при попытке ORDER BY, чтобы сгруппировать как-то вокруг одинаковых ID данные. Ну можно еще временную таблицу сделать и туда их вставлять, а уже во временной таблице иметь индекс по ID (скорее всего уже и первичный ключ)...
Вообще мне это все напоминает бутафорию продаж. Имеются все продажи (черные) и из них некоторые нужно сделать белыми - все равно какие. Но рано или поздно приходит заказчик и просит сделать "не все равно какие" и задачу приходится решать с нуля. Если бы не делалось тайны в данном случае из самой задачи, я думаю - все бы сразу друг друга поняли и помирились.

← →
3APA3A © (2004-09-18 23:08) [33]

to сергей1
Ok. Но посчитайте пожалуйста, объем кода, необходимый для
1) Записи, чтения из файла
2) Различного вида выборок (как минимум - 2)
3) Представления информации на экране.

И вдогонку - морочить Вашу, доверху забитую трудами Кодда и Дейта, голову я не собирался. Тем более, что дать ответ именно на subj Вы даже не потрудились.

to All without сергей1
Спасибо за ответы.

← →
Роман Снегирев (2004-09-18 23:33) [34]

ИМХО,только через ХП получится.

а ИМХО через ж... тоже полуыиться

← →
sniknik © (2004-09-19 01:07) [35]

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

-SeM- (18.09.04 10:34) [27]
> Не верю. Есть еще и RDB$DB_KEY
да знаю есть такой в чемто из (IB/Yaffil/Firebird), но как его использовать практически? (запросы что с ним пробовал для тестов не работают (стоит Yaffil), просвети если знаеш).
теоретически его быть не должно (а может и практически скоро не станет), и закладыватся на него я бы не стал, не стал бы может чисто по привычке, работаю в основном с MSSQL/Access там такого нет (и правильно).

← →
Deniz © (2004-09-19 08:26) [36]

> -SeM- (18.09.04 11:33) [29]
> RDB$DB_KEY - это фактически указатель на физическое расположение записи в базе... Добавили в запрос RDB$DB_KEY и получили еще одно (уникальное) поле, по которому ты можешь определить какую из двух записей с одинаковым ID и REC_COUNT нужно удалять.

Теоритически все правильно(и не ново), но я просил повазать "как удалить ОДНУ запись запросом" с использованием RDB$DB_KEY. Покажи, если знаешь, а если на практике не пользовался(или хотя бы на тестах), то и не надо народ в заблуждение вводить.
Все мои попытки с RDB$DB_KEY в запросах оказались неудачными :-(

← →
сергей1 (2004-09-19 09:41) [37]

2 sniknik
я тебе про Фому, ты мне про Ерему. При чем тут OLAP системы с их денормализованной структурой, я в [26]

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

денормализованы

>и их офисы ну хотябы в москве
далековато ехать...

2 зараза

вот требуемая выборка из файла (сам файл - c:\test.txt, на форме лежит ListBox1, в который загоняем
результат)

procedure TForm1.Button2Click(Sender: TObject);
var i,p:integer;
s, f_num, s_num,k:string;
st:tstringlist;
begin
st:=tstringlist.Create;
st.LoadFromFile("c:\test.txt");
k:="";
for i:=0 to st.Count-1 do
begin
s:=st.Strings[i];
p:=pos(" ",s);
f_num:=leftstr(s,p-1);
s_num:=rightstr(s,length(s)-p);
if f_num<>k then
begin
k:=f_num;
form1.ListBox1.Items.Add(f_num+" "+s_num)
end;
end;
end;

запись в сам файл и чтение из него по сложности много превосходят данный код, так что я не стал его тут

приводить

>именно на subj Вы даже не потрудились
тебе ответ по сабжу дали в [9], мне его что, продублировать что-ли ?

← →
sniknik © (2004-09-19 11:35) [38]

> я тебе про Фому, ты мне про Ерему. При чем тут OLAP системы с их денормализованной структурой, я в [26]
я не про олап, я про обычные базы.
вот последнее с чем столкнулся, по системе безопасности, у них прога (сервис) подсчитывает проходы между воротами, туда обратно... данные практически только записываются (чтение нужно но очень и очень редко), и соответственно вся оптимизация на скорость записи. никакого ключа/индекса дата и время прохода сохраняется но в странном таком формате (число-интеджер) время до минут (1-это 12ч 1мин) т.е. внутри минуты куча дублируюшихся записей. и все довольны. просто максимум что нужно по задаче это количество таких проходов поминутно посчитать. этому база полностью удовлетворяет. а делать всякие извраты (для этого извраты) сумировать при записи и вообще както организовывать это только усложнять и замедлять запись. инфа приходит по протоколу UDP, так что такое замедление чревато потерями данных... что наверняка будет если сделать "правильную" базу. а так, как уже сказал никто не жалуется.
хотя можно былобы развести, и протокол неправильно выбрали, и база не так, и машина слабая "правильную" не держит по скорости, и вообше все у вас хреново... прямой путь потерять клиента.

← →
sniknik © (2004-09-19 11:37) [39]

> (1-это 12ч 1мин)
ночи. вернее будет 0ч 1мин

← →
сергей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]
такой вариант тоже был предложен. но, както не "прижился". ;о)
основания - основное, для подсчета придется организовывать массив значений/или потоки для разных ворот и большую часть времени данные будут "висеть" в памяти. т.е. мало того что усложнение так еще и ненадежнее станет. зачем? чтобы немного размер уменьшить?
> время кол-во проходов
в структуре еще дату и номер ворот забыл. и будет полный аналог. почти. ;о))
там идет так
номер, дата, время, событие (проход туда/назад/ошибка)
все поля числовые (инт). в общем как приходит так и ложится без обработок. (хотя понятно можно и дату "собрать", и еще чегонибудь добавить, но смысла нет)

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

> 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;
И ничего в памяти держать не надо ;-)
Да, в принципе, любой вариант из этой статью можно адаптировать под эту структуру
номер, дата, время, событие (проход туда/назад/ошибка), кол-во_проходов

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

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

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

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

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

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

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

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

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

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

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

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

> 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]
... Но вот в запросах (в т.ч. и на удаление) использовать можно...
Вот именно об этом я и спрашивал, как? Если знаешь расскажи.

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

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

> У меня вопрос, этот эмулятор 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...

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

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

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

>> может это описка
Да запросто! 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 ... Найти похожие ветки