Вопросик по SQL
7623
41
Fender
guru
Может кто подскажет.
Есть таблица, типа:
name type sum
Вася болт 1
Петя гайка 1
Коля болт 2
Катя гвоздь 10
Вася шуруп 4
Коля гайка 5
Света шуруп 1
Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложился и получился вывод типа:
name sum
Вася 5
Петя 1
Коля 7
Катя 10
Света 1
type выводить ненадо, только name и sum. При этом сами данные менять нельзя, работаем только с выводом. Возможно ли такое сделать с помощью SELECT? Может кто подскажет вариант?
Есть таблица, типа:
name type sum
Вася болт 1
Петя гайка 1
Коля болт 2
Катя гвоздь 10
Вася шуруп 4
Коля гайка 5
Света шуруп 1
Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложился и получился вывод типа:
name sum
Вася 5
Петя 1
Коля 7
Катя 10
Света 1
type выводить ненадо, только name и sum. При этом сами данные менять нельзя, работаем только с выводом. Возможно ли такое сделать с помощью SELECT? Может кто подскажет вариант?
Чего ж тут хитрого?
SELECT name, SUM(sum)
FROM table
GROUP BY name
SELECT name, SUM(sum)
FROM table
GROUP BY name
jack_solovey
v.i.p.
Чтобы такие селекты не казались хитрыми, почитайте небольшую книжицу http://www.sql.ru/docs/sql/u_sql/
IEEE
experienced
Чтобы такие селекты не казались хитрыми, почитайте небольшую книжицу http://www.sql.ru/docs/sql/u_sql"Предположим что вы хотите знать какие продавцы в настоящее время имеют свои порядки в таблице Порядков."
...
...
"SELECT snum FROM Orders; "
АААА!!!!
Сибиряк
old hamster
Чтобы такие селекты не казались хитрыми, почитайте небольшую книжицу http://www.sql.ru/docs/sql/u_sql/Лучше вот это:
sql-ex.ru
Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложился и получился выводТакой таблицы быть не может. Потому что не может быть одинаковых уникальных имен/наименований в базе данных.
"Предположим что вы хотите знать какие продавцы в настоящее время имеют свои порядки в таблице Порядков.""Переводчик не известен."
Известен. Это компьютер перевел.
Сейчас читают
что такое Эзотерика (часть 2)
329318
1000
КОФЕЙНЯ
232823
1000
Просветление. (часть 2)
284643
1000
Такой таблицы быть не может. Потому что не может быть одинаковых уникальных имен/наименований в базе данных.Хотите я вам такую таблицу покажу? ну чтобы вы не говорили, что "такой быть не может".
и где вы прочили про уникальность?
ХочуСпросить
ЗооПрограммист
Ну не успел еще человек про владельцев объектов и про полное имя объекта почитать. Ну чего сердиться-то 
KSergey
guru
Ну не успел еще человек про владельцев объектов и про полное имя объекта почитатьРечь, как я понял, про строки в таблице с идентичным содержимым, а не про объекты (таблицы) БД.
ХочуСпросить
ЗооПрограммист
Стоп. Похоже это я по диагонали прочитал... 
Хотите я вам такую таблицу покажу? ну чтобы вы не говорили, что "такой быть не может".Вы не читали, поэтому и задаете такие вопросы. Автор темы тоже не читал. Поэтому в национальном масштабе мы юзаем екзель.
и где вы прочили про уникальность?
Когда вы приходите в контору где есть клиентская база вам задают вопрос: вы у нас бывали? Если задают, значит там правильная культура. Если не задают: там дебилы и база данных им не нужна.
Каждый факт хранится в базе в единственном экземпляре. Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных и не надо мучиться с SQL'ем. Надо просто скопипастить ее в екзель и фильтрами корежить.
Довольно странно что приходится такие вещи объяснять после ссылок на документацию.
А вот зачем суммировать количество разных артикулов: ума не приложу. Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.
Сделать это будет легко: суммируем все поля количество в заказе выбранном по заказаИД из таблицы заказы выбранной по покупанИД.
name type sumЭто минимум 3 таблицы: товары, покупаны, заказы. Заказы связывают таблицы покупаны и товары и содержит поля товарИД и количество. Идентификатор отдельного заказа может быть датой, или числом. Но придется его размножать на каждую позицию. Можно не плодить эти лишние сущности и поделить заказы на заказы и заказ которые связываются по заказИД. То есть 4 таблицы: товары, покупаны, заказы, заказ. В каждой сугубо уникальные данные.
Вася болт 1
Петя гайка 1
Коля болт 2
Катя гвоздь 10
Вася шуруп 4
Коля гайка 5
Света шуруп 1
А вот зачем суммировать количество разных артикулов: ума не приложу. Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.
Сделать это будет легко: суммируем все поля количество в заказе выбранном по заказаИД из таблицы заказы выбранной по покупанИД.
А вот зачем суммировать количество разных артикулов: ума не приложу. Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.Я извиняюсь, зачем усложнять и удаляться от сабжа? Реквест на хелп был с четко сформированным заданием: "Можно ли сделать так, если дано вот так?". Первый же ответ был: "Можно". Вы имеете поспорить, что в скулевой таблице так нельзя сохранить данные? Или нельзя их так выбрать? Зачем это автору - другой вопрос. Мое мнение - просто упражнение, скажем, на курсе "Базы данных", именно на использование SUM() и GROUP BY в запросах...
Сделать это будет легко: суммируем все поля количество в заказе выбранном по заказаИД из таблицы заказы выбранной по покупанИД.
Ну вот, пришел модер и стало скучно... а я только пивом затарился...
автору, тоже :
автору, тоже :
Блин, я ж тут модератор, точно... А я-то и не вспомнил с разгону, зачем я в раздел залез и зачем написал...
Mad_Dollar
guru
Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных и не надо мучиться с SQL'емОчень спорное утверждение.
Основные задачи проектирования баз данныхСокращение != устранение.
Основные задачи:
Обеспечение хранения в БД всей необходимой информации.
Обеспечение возможности получения данных по всем необходимым запросам.
Сокращение избыточности и дублирования данных.
Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.
вам бы вот это почитать хотя бы с википедии
Наличие избыточности данных
а) всегда бывает плохо с точки зрения теории и структуры
б) иногда хорошо с точки зрения производительности при эксплуатации
Опять же - наличие или отсутствие избыточности ничего не говорит о реляционности модели данных.
Вы не читали, поэтому и задаете такие вопросы. Автор темы тоже не читал.Я все внимательно читал в отличии от некоторых.
Вы писали буквально следующее: "Такой таблицы быть не может. Потому что не может быть одинаковых уникальных имен/наименований в базе данных."
Теперь вдруг заясняете про какую-то культуру. Зачем?
Давайте вы уже определитесь: таки может или нет? замечу, натурный эксперимент дает однозначный ответ.
Каждый факт хранится в базе в единственном экземпляре. Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данныхТС где-то утверждает, что у него реляционная база? он где-то спрашивает реляционная ли она? нет? а зачем тогда вы все это пишите? Америку открываете?
Вот потому у нас на форумах вместо четrоко ответа по экселю начинают первым делом заяснять про оракл и как это круто. Не зависимо от вопроса. Все грамотные ведь.
А вот зачем суммировать количество разных артикулов: ума не приложу.И? ваши рассуждения вслух кому-то интересны?
Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.Мировая закулиса готовим мировой заговор! Это ж понятно сразу по вопросу! нас гайками-болтами не собьёшь.
ХочуСпросить
ЗооПрограммист
Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных и не надо мучиться с SQL'ем. Надо просто скопипастить ее в екзель и фильтрами корежить.Подкину в вентилятор:
Почитайте, что означают термины "реляционная" и "нормализованная". И сравните...
Такой таблицы быть не может в базе данных. В ёкзеле, конечно, это обычное дело. Потому что это не база данных.
Ну хорошо, если у вас несколько идентичных Свет, вы как будете править поле name. Начнем, SELECT name FROM table WHERE name = 'Света', выкатилось 150 Свет, дальше что? И так каждый раз, заметьте. Света, может показаться простым именем, если оператор не забудет вовремя переключиться на RU. Иначе он наберет Cdtn, заметит, сотрет латиницу до С, допишет вета и вы эту Цвету никогда уже не найдете в базе как и ее заказ. А может оказаться не простым, а вроде такого: Маркшейдерская контора Коробчук и Голдберг. Копипастить будете, да?
Не важно, в общем. В одной таблицы базы данных Света и Света это две разные Светы, а если одинаковые, то значит база данных спроектирована без потребности в SQL.
Кстати, в примере выше была ошибка проектирования. Сделана без умысла, просто я давно уже не практиковался. Но читателям пофигу. Исправляю: в том случае природу не обмануть: каждая позиция будет связана с заказом по заказы.заказID.
Ну хорошо, если у вас несколько идентичных Свет, вы как будете править поле name. Начнем, SELECT name FROM table WHERE name = 'Света', выкатилось 150 Свет, дальше что? И так каждый раз, заметьте. Света, может показаться простым именем, если оператор не забудет вовремя переключиться на RU. Иначе он наберет Cdtn, заметит, сотрет латиницу до С, допишет вета и вы эту Цвету никогда уже не найдете в базе как и ее заказ. А может оказаться не простым, а вроде такого: Маркшейдерская контора Коробчук и Голдберг. Копипастить будете, да?
Не важно, в общем. В одной таблицы базы данных Света и Света это две разные Светы, а если одинаковые, то значит база данных спроектирована без потребности в SQL.
Кстати, в примере выше была ошибка проектирования. Сделана без умысла, просто я давно уже не практиковался. Но читателям пофигу. Исправляю: в том случае природу не обмануть: каждая позиция будет связана с заказом по заказы.заказID.
Теперь вдруг заясняете про какую-то культуру. Зачем?Затем, что культура вырождается без поддержки культурного уровня. Сейчас вы оспариваете предикат баз данных "факт хранится в единственном числе" чтобы завтра опустить реляционную базу данных до уровня привычной вам электронной таблицы. Получится что в руках у вас SQL, а продукт - Ёкзель. Потомки идут по вашему следу и уравнивают: SQL == Ёкзель. Вот и не стало SQL'я. Был прогресс, вы его завернули вспять и получили деградацию.
ТС где-то утверждает, что у него реляционная база?Из вопроса по языку структуированных запросов самоочевидно вытекает наличие структуры. Но в приведенном примере никакой структуры не наблюдается. Нет структуры - нет структуированных запросов. Переводите в екзель, пользуйтесь фильтрами.
Такой таблицы быть не может в базе данных.Это вы, конечно, в учебнике прочитали? Поздравляю.
Ну хорошо, если у вас несколько идентичных Свет, вы как будете править поле name. Начнем, SELECT name FROM table WHERE name = 'Света', выкатилось 150 Свет, дальше что?Я прошу прощения, а Света - она на всем белом свете одна?!
тушите свет, концерт окончен.
Дальше я уже не читал.
Успехов!
Не знаю сколько Свет на белом свете, а X - один. Включайте свет, может хоть что-то поймете.
Автор хотел узнать сколько всего позиций заказала Света, следовательно это копипаста одной и той же Светы. О чем автор и пишет:
Автор хотел узнать сколько всего позиций заказала Света, следовательно это копипаста одной и той же Светы. О чем автор и пишет:
Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложился и получился вывод типа:
Жаль, про яйца убрали.
Так вот, возвращаясь к яйцам, если бы теоретиков кормили сугубо теоретической едой - просветление в их мозгах наступало бы довольно быстро.
Так вот, возвращаясь к яйцам, если бы теоретиков кормили сугубо теоретической едой - просветление в их мозгах наступало бы довольно быстро.
Включаем свет на местности. Света это значение переменной Х, или Y. Значение можно поменять, а переменную можно только создать или убить. У автора несколько переменных которые содержат одинаковое значение Вася. Он хочет узнать сколько Вася всего заказал. Ему приходится выбирать все переменные по значению Вася и затем группировать по этому же значению. Один Вася занимает несколько переменных, хотя коню ясно, ему вполне хватит одной. Он же один, уникальный, неповторимый Вася. Для разных Вась нужны разные переменные. Но тогда и значение у них будет разное: Вася Белый, Вася Обломов, Вася Питерский... Узнать сколько разные Васи заказали разного товара всего, можно будет с помощью предиката LIKE.
если бы теоретиков кормили сугубо теоретической едой - просветление в их мозгах наступало бы довольно быстро.Кто бы сомневался что профанский подход гораздо эффективнее на первых порах. Оба-на и готова база, пользуйтесь. Но через три месяца контора встала в ступор: никто не может разобраться где какой Вася среди сотен Вась. Это уже было, вы же не рискнули предложить решение что делать с кучей Свет.
На практике я регулярно с этим сталкиваюсь потому что смежники юзают екзели. Приходится акустически им помогать разобраться в их же проблемах по телефону. Он там запутался нафик, когда оно было актуально думал что все просто и понятно, а через три месяца забыл как оно было, а найти ничего не может.
Екзельные листы засасываются в базу через ODBC, но не все так просто как кажется. Приходится терять время, проверяя входящие в целях сохранения своей базы данных как таковой. Иначе засрется в кратчайшие сроки так, что сам станешь таким же варваром.
Mad_Dollar
guru
Скажите, а вы видимо себя специалистом считаете, да?
Даете советы космических масштабов и космической же глупости так легко и непринужденно, что я, право, сударь, теряюсь
Даете советы космических масштабов и космической же глупости так легко и непринужденно, что я, право, сударь, теряюсь
Если вы хотите чтобы ваш продукт развивался и продолжал приносить прибыль, придется читать "теоретиков" и вдалбливать культуру пользования базами данных. Испоганить можно самое блестящее проектирование. Поганый - значит язычник, многобожник. Но если мы считаем что люди себе не враги, то им достаточно объяснить что поддержание базы данных требует некоторых усилий и понимания и все пойдет на лад. Обычно это делается при помощи начальства. Ему объясняете, а оно уже принуждает. Отсюда растут требования к персоналу, а значит и рост зарплаты. Но зато один оператор хорошей базы стоит десятерых дятлов ковыряющих екзельные листы.
Сделайте в екзеле базу своей фототеки: make my day как говорится. В реляционной базе это делается за час и расти она будет годами под полным контролем юзера. И чем больше накапливается структуированных данных, тем выше их ценность. А куча хлама обесценивается, поскольку затраты на разбор завалов становятся непосильными.
Хорошо структуированные данные легко экспортировать в любой формат, в том числе в XML, например. Куча хлама в которой разбирается только тот, кто ее навалил не осилит этой простой в сущности операции. Годами будет перелопачивать и все равно выйдут одни только косяки.
Если в примере Вася это ID через который условные заказы связываются с условными покупанами, то почему name, а не ID? Но зачем суммировать запросом и группировать, если в таблицу покупанов можно добавить вычисляемое поле и пусть оно суммирует сколько на покупане висит заказов в таблице заказы через поле покупанID заказа.
Например http://sql-school.info/tutor/summirovan/funktsiya_183750.htm
Сделайте в екзеле базу своей фототеки: make my day как говорится. В реляционной базе это делается за час и расти она будет годами под полным контролем юзера. И чем больше накапливается структуированных данных, тем выше их ценность. А куча хлама обесценивается, поскольку затраты на разбор завалов становятся непосильными.
Хорошо структуированные данные легко экспортировать в любой формат, в том числе в XML, например. Куча хлама в которой разбирается только тот, кто ее навалил не осилит этой простой в сущности операции. Годами будет перелопачивать и все равно выйдут одни только косяки.
Если в примере Вася это ID через который условные заказы связываются с условными покупанами, то почему name, а не ID? Но зачем суммировать запросом и группировать, если в таблицу покупанов можно добавить вычисляемое поле и пусть оно суммирует сколько на покупане висит заказов в таблице заказы через поле покупанID заказа.
Например http://sql-school.info/tutor/summirovan/funktsiya_183750.htm
kostyanet
guru
Что-нибудь по существу изложите своими словами без цитат классиков.
Mad_Dollar
guru
а вы перечитайте начальный пост ТС и попробуйте представить, что все васи - это разные васи.
и изначально приведенные три колонки не полностью описывают структуру исходной таблицы - да-да, мы можем предположить, что там есть колонка уникального идентификатора, так вами любимого, который и используется при построении связей. что одновременно и опровергает неверное в корне ваше утверждение, сделанное на _допущении_, что этого уникального идентификатора нет.
и только конечная цель выборки, которую хочет топистартер состоит не в том, чтобы посчитать уникальных вась, петь и свет в разрезе суммы неких показателей, а получить статистические данные, как имя клиента влияет на количество заказанного ))) маркетоид он, хочет дать скидку всем покупателям с редким именем ценой минимальных потерь )))
парируйте, "специалист" вы наш. вы, простите, с чем работали? давно? долго? учились где-нибудь или так, обчитавшись грубера советы тут раздаете?
и изначально приведенные три колонки не полностью описывают структуру исходной таблицы - да-да, мы можем предположить, что там есть колонка уникального идентификатора, так вами любимого, который и используется при построении связей. что одновременно и опровергает неверное в корне ваше утверждение, сделанное на _допущении_, что этого уникального идентификатора нет.
и только конечная цель выборки, которую хочет топистартер состоит не в том, чтобы посчитать уникальных вась, петь и свет в разрезе суммы неких показателей, а получить статистические данные, как имя клиента влияет на количество заказанного ))) маркетоид он, хочет дать скидку всем покупателям с редким именем ценой минимальных потерь )))
парируйте, "специалист" вы наш. вы, простите, с чем работали? давно? долго? учились где-нибудь или так, обчитавшись грубера советы тут раздаете?
KSergey
guru
Скажите, а вы видимо себя специалистом считаете, да?Дело даже не в том.
Приведена задачка из учебника первого класса на закрепление методов, изучаемых в этом же первом классе: поезда отходят от станций А и Б одновременно навстречу друг другу, двигаются равномерно, со скоростью такой-то, найдите время когда... ну и т.д.
Соответственно ее надо быстренько решать методами первого класса, и тут же переходить к следующей.
И вдруг некто в блеском в глазах начинает заяснять, что поезда ездить должны не так, да еще надо учесть нагрев колес и то, что поезда от станций выезжают с ускорением, а еще по дороге есть 5 поворотов, где поезда сбрасывают скорость, а задачу надо решать дифурами, причем непременно с учетом теории относительности. И вообще поезда у вас спроектированы неправильно.
К чему это все - не понять. Похоже на типичного тролля.
kostyanet
guru
а вы перечитайте начальный пост ТС и попробуйте представить, что все васи - это разные васиТакого быть не может чтобы Вася был другой Вася. По условиям которые вы предлагаете еще раз прочитать, надо выбрать все имена == Вася и суммировать все заказы одного Васи.
В порядке апологии вы могли бы догадаться сказать что Вася это ID покупана, а гайка это ID товара и тогда перед нами таблица Заказы, с которой связаны таблицы Покупаны и Товары. Но вы доказываете ровно обратное. То есть подтверждаете мои же слова. Мило.
Автор сам за себя отвечал вполне. Да и вообще, мне-то что, хотите превратить ацес в абсцесс, пожалуйста. Забивайте гвозди микроскопом. Это по-нашему.
что Вася это ID покупана, а гайка это ID товара и тогда перед нами таблица ЗаказыА это и есть ID покупателя.
Или ID непременно должно быть чем-то вроде 123550 на ваш взгляд?
Перед нами и есть таблица заказов, причем идеально нормализованная!
А это и есть ID покупателя.Вы только что утверждали что это ID разных Вась.
Да, ладно, отстал...
Класс! Не даром пивом затарился... модерам - не сносить ни в коем рази! и-ик...
И так имеем задачку из первагу классу... асталось тока апределиться это те же Васи или другия...
и ваще, мож они и не покупаны вовся, а продаваны ... или эт-ти, как их, работягуны...
правда, нифига не понял, куда автор делся в пылу спора, ну да бог с ним! И без него весело.
Вот глядючи на весь этот сложный процесс, предлагаю перевести это в EAV модель и показать пример реализации на соответствующей БД... mongo к примеру или mumps...
Пошел за
автору и всем участникам
И так имеем задачку из первагу классу... асталось тока апределиться это те же Васи или другия...
и ваще, мож они и не покупаны вовся, а продаваны ... или эт-ти, как их, работягуны...
правда, нифига не понял, куда автор делся в пылу спора, ну да бог с ним! И без него весело.
Вот глядючи на весь этот сложный процесс, предлагаю перевести это в EAV модель и показать пример реализации на соответствующей БД... mongo к примеру или mumps...
Пошел за
автору и всем участникам
Вы только что утверждали что это ID разных Вась.Вы меня с кем-то спутали. Не помню такого.
Mad_Dollar
guru
Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложилсявот дословно что написано
но вы настолько уперты, что не хотите прочесть очевидное
Такого быть не может чтобы Вася был другой Вася. По условиям которые вы предлагаете еще раз прочитать, надо выбрать все имена == Вася и суммировать все заказы одного Васито есть скорректированное условие задачи вам топикстартер передал каким-то образом через космос прямо в мозг минуя форум? ах какой негодяй этот топикстартер! накол его!
kostyanet, надеюсь SQL это не ваш хлеб?
Дело в том, что это таблица импортированных значений из сторонней БД, а конкретнее из SAP а. Нумерные Id понятно дело разные, поэтому "Вася" это функциональное именование, которое отвечает за связывание соответствующих таблиц из разных баз
Чего непонятного то, я как прочитал первый пост - сразу догадался! 
Чего непонятного то
, я как прочитал первый пост - сразу догадался!