Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Приветствую тебя, мудрый ALL! Столкнулся тут, сижу - туплю... может кто подскажет? Есть запрос типа Select table1.un,Sum(table2.m),table1.prim from бла-бла-бла Group by un, prim где поле prim - BLOB Если его включать в Group by - ругается что Blob мол cannot be used as grouping field. Если не включать - ругается что every simple field must be in Group by... поле в запросе нужное, печататься будет, очень хочется его там оставить... Что делать-то? Заранее благодарю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 12:25 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
BLOB поля действительно нельзя включать в GROUP BY. Если мое предположение о твоей схеме данных верно, то можно сделать так (для MS SQL) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 12:59 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Все бы хорошо (идея хороша), но в INNER JOIN вставить select ну никак не выходит... Возможно из-за корявой реализации SQL в BDE, а может с руками что-то не то. :-( В общем вопрос остается открытым... Да, структура таблиц: table1: table2: un (integer) un (integer) prim (blob) money ($) Наверняка ведь все просто... Это-то и обидно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 14:11 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
С какой базой то работаешь? Я был лучшего представления о схеме данных. Ну ты подумай, проссумировал ты money с группировкой по un по таблице table2. Из 10 записей у тебя получилась одна. Так какое примечание из этих 10 записей тебе прицепить к 1 результирующей записи, а? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 14:22 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
База - парадоксовская. Полей в таблицах - несколько больше чем два, но к существу вопроса это не относилось, поэтому я и не стал расписывать... А чем тебе не нравится структура? table1 (заказы) un - номер заказа (уникальный) prim - примечания к заказу table2 (оплаты) un2 - номер оплаты (уникальный), в запросе неважен un - номер заказа money - сумма оплаты отношение один ко многим (одному table1.un соответствует много table2.un) Задача: выбрать из table1 заказы и примечания к ним, и из table2 сумму оплат по каждому из заказов Просто как мычание... Но одним запросом почему-то я это сделать не могу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 14:52 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
2 Mikena Извиняюсь. :-) Мой последний пост был навеян неправильной трактовкой местонахождения поля коментарий. Еще, раз извиняюсь. Так что, мой первый запрос, то что доктор прописал. Вот тока не поддерживает BDE такие запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 15:01 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
2 pkarklin Да ничего... :-) Однако, неужели такую простую задачу через BDE не решить?!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 15:16 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
>Однако, неужели такую простую задачу через BDE не решить?!!! Ну не знаю я, что поддерживает, а что не поддерживает Local SQL от BDE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 17:46 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Plankin - просто для лучшего разития, вдруг понадобится BDE - localsql.hlp ===================== Боюсь, меня скоро бить будут за ответ "Базы надо правильно проектировать!" Что есть Ваше поле "примечание"? Это то место, куда любой юзер может записать все что ему захочется. Типа - "Хороший договор!", "Тут мы заработаем кучу денег", "Исполнено", "К исполнению до...". Любопытен будет отбор по значению prim="Насрать" Нормальный отбор может вестись только по формализованым параметрам. Вы должны формализовать все. Поле "Примечание" у меня вызывает жуткую озлобленность. Это значит, что задачедатель даже примерно не представляет, что ему надо. И тут уже дело постановщика задач выявит действительно необходимые критерии отбора. А поскольку в нашей реальности, в 90% случаев, Постановщик задач=Программер=Архитектор, то Архитектор не должен слушать лепет "Сделайте нам Примечание, а мы будем туда писать, что хочем". Он ОБЯЗАН паратмеризировать критерии отбора. Поле "Прим." не имеет право на существование в базах данных! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2003, 21:07 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
2 Cat2 Спасибо, но я знаю, где можно почитать справку по локал SQL. :-) Вот тока не читал и читать не буду читать. Мне хватит моих скромных знаний синтаксиса TSQL. А на счет примечание, полностью с тобой согласен. Своим разработчикам не даю такие поля создавать. Разберись, что за аттрибуты должны быть, вместо того, что бы ляпать поле примечание. А то потом еще и полнотекстовый поиск по этим полям придеться вводить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 07:58 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Не согласен Примечание или правильнее комментарий, на мой взгляд имеет право на существование. Я не утверждаю что по нему нужно вести поиск, оно разумеется необязательно к заполнению, но оно должно быть. Все предусмотреть невозможно, да и не нужно. А некоторый комментарий к тем цифрам что в базе есть, очень часто необходим. Там скажем может быть объяснено, откуда такие цифры, в другом случае там вписано что-то другое. Но разумеется по этому полю поиск идти не должен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 08:10 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
pkarklin> Ну и ладушки . StarWind> Может быть... На этапе проектирования. Если какая-то информация важна - ее надо формализовать. Ссылкой на документ, фамилией исполнителя, датой заполнения, отметкой о выполнении - в жизни критериев множество. Но возможности записывать анекдоты давать не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 08:36 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Ну вот например ситуация. Сдается оборудование на ремонт. Есть, скажем так, стандартные причины отказа. (Оборудование довольно специфично). Но иногда хочется что-то дополнить, чтоб была понятна причина. Например, кто-то уронил комок снега в электролизер. (кто знаком с технологией производства алюминия, меня поймет :)) ) И это нужно указать на тему того что случилось. Куда его писать? Вот и есть ситуация где нужен комментарий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 08:54 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
2 Cat2 & pkarklin Уважая ваш проффесионализм в проектировании баз данных, а также внимание к существу моего вопроса :-), все-таки позволю себе с вами не согласиться. Существует куча ситуаций когда поле "примечание" (или, действительно, правильнее "комментарий") необходимо. Искать по этому полю естественно никто не собирается. Например в данном случае это примечания к заказу в рекламное агентство. Для менеджера необходима распечатка заказов в которой наряду с информацией кто заказчик, полностью-ли оплачен заказ и пр. будет комментарий типа "поставить среди телепрограммы", "на первой полосе", "заказано 2 блока, но если мало места согласны на 1", "За прошлую рекламу они расплачивались полгода...". На основании этого он будет решать какую рекламу ставить, какую снимать, какую переносить... Вот попробуйте формализовать эти комментарии, хотя они важны... И никакая жуткая озлобленность не поможет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 10:34 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 10:37 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
а по твоему существу, можно предложить следующую конструкцию (для строк подходит по крайней мере) select table1.un,Sum(table2.m), min (table1.prim ) ... и далее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 10:39 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
еще вариант ) Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 10:42 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
К автору топика, так всеж, поделись секретом, что за СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 10:46 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Не успел прочитать, что было написано за 16 апреля. Весь день думал над ответом Звездному Урагану StarWind> Я бы все же сделал пополняемый юзерами справочник причин отказа. Конечно, тут будут проблемы. См. лучший (на мой взгляд) топик прошлого года. MS SQL-форум - "Убей двойника". ======== А как им удалось донести снег до электролизера? Бегом бежали? ======= Вот еще. На заявление "У нас своя специфика", я всегда отвечаю. - Она заключается в том, что присутствуют не все возможные случаи, а только некоторые из них ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 17:14 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Mikena Формализовать можно все! Я не специалист по управлению рекламой, но я бы выжал все соки из задачедателей и построил формализованую систему. Итак. "За прошлую рекламу они расплачивались полгода..." Делаем поле "Надежность клиента" В это поле менеджер среднего (а может быть высшего) звена ставит градации надежности. 1. Надежен 2. Не совсем надежен 3. Не надежен Это только пример. Градации могут быть любые. Но при обработке заказа оператор, увидев рядом с наименованием клиента что-то кроме "Надежен" обязан связаться с менеджером. "полностью-ли оплачен заказ" - Должник должен быть выделен в списке клиентов - цветом, галкой, суммой задолжности - не важно. И для этого не нужно "прим". Нужен суммарный результат взаиморасчетов. Должны быть поля "Разместить в TВ" и подключенный к нему список каналов "Разместить в радио" и подключенный к нему список станций "Разместить в газету" и подключенный к нему список газет Хотя нет, лучше так - список типов средств МИ и подключаемый к ним список наименований. Для каждого вида МИ должна быть категория типа 1. лучшее место/время ... N. Худшее место/время И т.д. и т.п. Разумеется, это только рыба. Я бы вытряс из задачедателя все требования и формализовал их. ================= Не... Конечно, если все это в лом проектировать, то "прим" - рулез, однозначно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 20:10 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Cat2 Так само собой он пополняем, но не всегда возможно да и не нужно туда писать абсолютно все. Те более что по этому полю поиска не будет , это просто некоторое уточнение, которое как есть будет перепечатано в отчет, в некоторый бланк заявки на ремонт. А снег донести можно. Зимой в корпусах не жарко... А сколь поподет в ванну снега... комок или только половина... эффект будет одинаковый... Будет такая небольшая воронка :) Хотя предметно не изучал :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 04:03 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Задолбало меня пытаться сделать все одним запросом. Ну не понимает меня локалБДЕ и все тут... Сделал приблизительно как советовал LexusR. 2 Cat2 Cat2>Не... Конечно, если все это в лом проектировать, то "прим" - рулез, однозначно. Ну наконец-то ты меня понял... :-) И проблема в общем-то не в том, что лень проектировать, а в том, что с периодичностью раз в месяц заказчик говорит: "А вот хотелось-бы мне ..." %$!!! Поэтому пускай будет "прим". Да, насколько я понял ты тоже из Петрозаводска? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 09:22 |
|
||
|
Blob & Group by
|
|||
|---|---|---|---|
|
#18+
Mikena. Это ты "тоже из Петрозаводска" Где трудишься? Чо ваяешь? У меня тоже есть база, где постоянно появляются новые требования. Я завел текстовое поле, в которое юзеры быстро пишут новые показатели, а я быстро делаю соответствующие алгоритмы. Потом создаю нормальное поле и переношу в него данные. Только вот не пойму. Зачем для "прим" использовать BLOB? Тебе что, базу арабы заказали? Это у них "жирность" шрифта несет важную смысловую и религиозную нагрузку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 19:51 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=32143622&tid=2118535]: |
0ms |
get settings: |
10ms |
get forum list: |
25ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 261ms |
| total: | 413ms |

| 0 / 0 |
