| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
select distinct ... [D7, IB6.x]
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
Каким запросом можно это сделать?
сергей1 (2004-09-19 12:51:00) [21]любые задачи имеют множество решений, работает данный вариант - отлично, я что, против ?
просто может в данном случае, если надо всего-лишь посчитать количество проходов за минуту, я бы сделал например так : программа ловит пакеты udp, сама считает время, и по окончании минуты заносит в БД единственную запись - т.е. напр. 13.45 м. - 87 проходов. получилась бы такая таблица :
время кол-во проходов
12.30 45
12.31 88
12.32 0
и т.д.
вот здесь-бы уже мой любимый PK пригодился-бы :)
наверняка есть и другие решения,гораздо лучше, тут и спорить бесполезно
>да меня уволят сразу же после такого заявления)
уволят, если придя проектировать базу ты заявишь, что обладаешь более лучшей теорией БД, а Кодд - ну кто он такой, подумаешь жалкий америкашка, они там вообще негров линчуют !
sniknik (2004-09-19 12:19:00) [22]> если запись производится не чаще, чем раз в минуту ?
чаще, гораздо чаще, представь очередь в магазине, на кассе стоят ворота, и если кассовая очередь както задерживается кассиром, то свободный проход (без покупок) никак.
всего 18 ворот. можеш посчитать. теоретически количество проходов в минуту очень большое (гдето 120 от одних если идут без задержки)
> и udp зачем тогда, ...
вот, именно про это и говорил... ;о) поругать все можно. но первое протокол невыбираем, посылают события сами ворота без участия какихто наших программ и только в этом протоколе. (кстати писал эту систему не я, но со мной консультировались и я ее полностью одобряю, это так к слову)
и второе, протокол оправдан и с точки зрения производителя ворот. он не задерживает процесс как tcp-ip, нет подтверждений и ожиданий. а у них собственные счетчики крутятся (которые тоже можно считать после для проверки, но общие) если делать tcp-ip значит либо вставлять какието очереди на отправку/паралельный процесс и т.д. жуткое усложнение и соответственно удорожание (комп внутрь это черезчур ;о)) с udp просто, послали забыли, не приняли сами выноваты.
> так по правилам, Кодд и др. не зря являются мировыми авторитетами, и считать себя умнее его просто смешно
маленькая поправка. мировые авторитеты не знают моих местных локальных задачь. и пищут они в общем о том "как должно быть", а работаем мы обычно с тем "что уже есть и переделке не подлежит".
(смешно было бы, пришол на работу и говориш "работать не буду, авторитеты не позволяют, т.к. входные данные не по их правилам построены" ;о), да меня уволят сразу же после такого заявления)
сергей1 (2004-09-19 11:58:00) [23]а что, программа считает проходы между воротами в гонках Формула1 ? какой смысл оптимизировать на скорость записи, если запись производится не чаще, чем раз в минуту ? (если я правильно понял задачу). и udp зачем тогда, tcp-ip здесь явно лучше. а вдруг в течении минуты 2 машины заедет ? по ходу дела, твоя программа нарисует 2 одинаковые строчки, все по-прежнему будут счастливы ?
а вообще, я-же писал, что базы, которым лучше без ключа, есть, но очень мало, и если-уж делать РСУБД, так по правилам, Кодд и др. не зря являются мировыми авторитетами, и считать себя умнее его просто смешно
sniknik (2004-09-19 11:37:00) [24]> (1-это 12ч 1мин)
ночи. вернее будет 0ч 1мин
sniknik (2004-09-19 11:35:00) [25]> я тебе про Фому, ты мне про Ерему. При чем тут OLAP системы с их денормализованной структурой, я в [26]
я не про олап, я про обычные базы.
вот последнее с чем столкнулся, по системе безопасности, у них прога (сервис) подсчитывает проходы между воротами, туда обратно... данные практически только записываются (чтение нужно но очень и очень редко), и соответственно вся оптимизация на скорость записи. никакого ключа/индекса дата и время прохода сохраняется но в странном таком формате (число-интеджер) время до минут (1-это 12ч 1мин) т.е. внутри минуты куча дублируюшихся записей. и все довольны. просто максимум что нужно по задаче это количество таких проходов поминутно посчитать. этому база полностью удовлетворяет. а делать всякие извраты (для этого извраты) сумировать при записи и вообще както организовывать это только усложнять и замедлять запись. инфа приходит по протоколу UDP, так что такое замедление чревато потерями данных... что наверняка будет если сделать "правильную" базу. а так, как уже сказал никто не жалуется.
хотя можно былобы развести, и протокол неправильно выбрали, и база не так, и машина слабая "правильную" не держит по скорости, и вообше все у вас хреново... прямой путь потерять клиента.
сергей1 (2004-09-19 09:41:00) [26]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], мне его что, продублировать что-ли ?
Deniz (2004-09-19 08:26:00) [27]> -SeM- (18.09.04 11:33) [29]
> RDB$DB_KEY - это фактически указатель на физическое расположение записи в базе... Добавили в запрос RDB$DB_KEY и получили еще одно (уникальное) поле, по которому ты можешь определить какую из двух записей с одинаковым ID и REC_COUNT нужно удалять.
Теоритически все правильно(и не ново), но я просил повазать "как удалить ОДНУ запись запросом"с использованием RDB$DB_KEY. Покажи, если знаешь, а если на практике не пользовался(или хотя бы на тестах), то и не надо народ в заблуждение вводить.
Все мои попытки с RDB$DB_KEY в запросах оказались неудачными :-(
sniknik (2004-09-19 01:07:00) [28]> конечно не поверю, отсутствие РК серьезно нарушает саму идею реляционных баз данных ...
тогда для тебя будет шоком данная информация. любая кассовая программа (они тоже работают с базами ;) держит свою базу в прямой противоположности "идее реляционных баз". информация в них дублируется многократно, связи почти не используются, и т.д.
причем (лично мое мнение) чем больше "отступов" от учебника тем надежнее программа.
а после эти данные с том же виде кочуют в офисные проги, и вот с ними я и работаю (т.что знаю что говорю).
> В принципе, базы без ключа бывают, но в очень редких исключениях
можеш зайти в первый попавшийся магазин и поубеждать их в том что у них база "неправильная". ;о) и пересчитай магазины и их офисы ну хотябы в москве, а после говори о "редкости". я бы наоборот сказал, очень частое явление.
-SeM- (18.09.04 10:34) [27]
> Не верю. Есть еще и RDB$DB_KEY
да знаю есть такой в чемто из (IB/Yaffil/Firebird), но как его использовать практически? (запросы что с ним пробовал для тестов не работают (стоит Yaffil), просвети если знаеш).
теоретически его быть не должно (а может и практически скоро не станет), и закладыватся на него я бы не стал, не стал бы может чисто по привычке, работаю в основном с MSSQL/Access там такого нет (и правильно).
Роман Снегирев (2004-09-18 23:33:00) [29]ИМХО,только через ХП получится.
а ИМХО через ж... тоже полуыиться
3APA3A (2004-09-18 23:08:00) [30]to сергей1
Ok. Но посчитайте пожалуйста, объем кода, необходимый для
1) Записи, чтения из файла
2) Различного вида выборок (как минимум - 2)
3) Представления информации на экране.
И вдогонку - морочить Вашу, доверху забитую трудами Кодда и Дейта, голову я не собирался. Тем более, что дать ответ именно на subj Вы даже не потрудились.
to All without сергей1
Спасибо за ответы.
kaif (2004-09-18 13:45:00) [31]Так или иначе, если задача формулируется так "выбрать по одному значению для каждого ID", придется иметь индекс по ID (пусть это и не ключ). Или же терпеть тормоз (если это устраивает) при попытке ORDER BY, чтобы сгруппировать как-то вокруг одинаковых ID данные. Ну можно еще временную таблицу сделать и туда их вставлять, а уже во временной таблице иметь индекс по ID (скорее всего уже и первичный ключ)...
Вообще мне это все напоминает бутафорию продаж. Имеются все продажи (черные) и из них некоторые нужно сделать белыми - все равно какие. Но рано или поздно приходит заказчик и просит сделать "не все равно какие" и задачу приходится решать с нуля. Если бы не делалось тайны в данном случае из самой задачи, я думаю - все бы сразу друг друга поняли и помирились.
сергей1 (2004-09-18 13:32:00) [32]если таблица ни с чем не связана, удаляется целиком, в ней может быть произвольное число одинаковых записей и всех это устраивает - база данных тут вообще не нужна, пиши напрямую в файл (текстовый например), и так-же напрямую из него читай, и не морочь больше людям голову.
3APA3A (2004-09-18 12:35:00) [33]to сергей1
Да каких, блин, правил. Ситуация такова
1) Эта таблица не имеет связей с другими
2) Удаляется она только целиком (DELETE FROM TABLE1)
3) В ней могут быть одинаковые записи (бизнес-логикой это не запрещено)
4) Мне нужно просматривать либо вообще все записи либо так, как в subj.
Что говорят правила на этот счет? Нельзя тупо следовать правилам, головой иногда думать надо...
-SeM- (2004-09-18 11:33:00) [34]Deniz © (18.09.04 11:06)[28]
RDB$DB_KEY - это фактически указатель на физическое расположение записи в базе. Т.о. жестко привязываться к нему не стоит, так как может поменяться при бекап/ресторе. Но вот в запросах (в т.ч. и на удаление) использовать можно. Добавили в запрос RDB$DB_KEY и получили еще одно (уникальное) поле, по которому ты можешь определить какую из двух записей с одинаковым ID и REC_COUNT нужно удалять.
Deniz (2004-09-18 11:06:00) [35]>
> -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 10:34:00) [36]sniknik © (18.09.04 09:49) [25]
> тогда и изменить и удалить их можно будет только вместе
Не верю. Есть еще и RDB$DB_KEY
сергей1 (2004-09-18 10:19:00) [37]>не повериш но есть много БД с множеством повторяющихся ...
конечно не поверю, отсутствие РК серьезно нарушает саму идею реляционных баз данных, в случаях, когда надо иметь несколько логически одинаковых записей - РК фабрикуется искуственно. В принципе, базы без ключа бывают, но в оченьредких исключениях, и я никогда не поверю, что данный топик и есть это самое исключение, так что не путай человека, а то он еще начнет направо и налево говорить, что это дело вкуса - хочешь делай ключ, нехочешь - не делай ...
sniknik (2004-09-18 09:49:00) [38]> или теория велит создавать его даже тогда, когда он не нужен, просто чтобы был?
нафига нам теория? если считаеш что не нужен не делай.
недостаток (если нет связей/обьеденений/самообьеденений, удалений конкретных полей) только один читать можно только либо все сразу либо неизвестно что.
ну вот в твоей таблице
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 09:23:00) [39]зачем что-то удалять, можно ПК создать как (ID и REC_COUNT), распостраненная ситуация. Ну а ключ, батенька, нужен, если ты проектируешь БД, будь добр придерживаться правил. Иначе в какой-нибудь прекрасный (но не для тебя) момент в базе появиться пара одинаковых записей, и будет это уже не БД, а Х...
3APA3A (2004-09-18 08:43:00) [40]Удалить все записи с дубликатими не так уж и сложно. Суть не в этом. Мне просто интересно - почему Вы так прицепились к этому ПК. Теория РСУБД это конечно хорошо, но
1) Мне не нужен ПК для этой таблицы (или теория велит создавать его даже тогда, когда он не нужен, просто чтобы был?)
2) Мне нужны эти дубликаты, т.к. иногда нужно смотреть все эти записи вместе с дубликатами.
| |
Страницы: 