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 нужно удалять.

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

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

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

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

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

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

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

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

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

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

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

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

> -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], мне его что, продублировать что-ли ?

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

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

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

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

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

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