Вопросик по SQL

Чего ж тут хитрого?

SELECT name, SUM(sum)
FROM table
GROUP BY name

Чтобы такие селекты не казались хитрыми, почитайте небольшую книжицу http://www.sql.ru/docs/sql/u_sql/

В ответ на: Чтобы такие селекты не казались хитрыми, почитайте небольшую книжицу http://www.sql.ru/docs/sql/u_sql

"Предположим что вы хотите знать какие продавцы в настоящее время имеют свои порядки в таблице Порядков."
...
...
"SELECT snum FROM Orders; "

АААА!!!!

В ответ на: Чтобы такие селекты не казались хитрыми, почитайте небольшую книжицу http://www.sql.ru/docs/sql/u_sql/

Лучше вот это:
sql-ex.ru

В ответ на: Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложился и получился вывод

Такой таблицы быть не может. Потому что не может быть одинаковых уникальных имен/наименований в базе данных.

В ответ на: "Предположим что вы хотите знать какие продавцы в настоящее время имеют свои порядки в таблице Порядков."

"Переводчик не известен."

Известен. Это компьютер перевел.

В ответ на: Такой таблицы быть не может. Потому что не может быть одинаковых уникальных имен/наименований в базе данных.

Хотите я вам такую таблицу покажу? ну чтобы вы не говорили, что "такой быть не может".
и где вы прочили про уникальность?

Ну не успел еще человек про владельцев объектов и про полное имя объекта почитать. Ну чего сердиться-то

В ответ на: Ну не успел еще человек про владельцев объектов и про полное имя объекта почитать

Речь, как я понял, про строки в таблице с идентичным содержимым, а не про объекты (таблицы) БД.

Стоп. Похоже это я по диагонали прочитал...

В ответ на: Хотите я вам такую таблицу покажу? ну чтобы вы не говорили, что "такой быть не может".
и где вы прочили про уникальность?

Вы не читали, поэтому и задаете такие вопросы. Автор темы тоже не читал. Поэтому в национальном масштабе мы юзаем екзель.

Когда вы приходите в контору где есть клиентская база вам задают вопрос: вы у нас бывали? Если задают, значит там правильная культура. Если не задают: там дебилы и база данных им не нужна.

Каждый факт хранится в базе в единственном экземпляре. Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных и не надо мучиться с SQL'ем. Надо просто скопипастить ее в екзель и фильтрами корежить.

Довольно странно что приходится такие вещи объяснять после ссылок на документацию.

В ответ на: name type sum

Вася болт 1
Петя гайка 1
Коля болт 2
Катя гвоздь 10
Вася шуруп 4
Коля гайка 5
Света шуруп 1

Это минимум 3 таблицы: товары, покупаны, заказы. Заказы связывают таблицы покупаны и товары и содержит поля товарИД и количество. Идентификатор отдельного заказа может быть датой, или числом. Но придется его размножать на каждую позицию. Можно не плодить эти лишние сущности и поделить заказы на заказы и заказ которые связываются по заказИД. То есть 4 таблицы: товары, покупаны, заказы, заказ. В каждой сугубо уникальные данные.

А вот зачем суммировать количество разных артикулов: ума не приложу. Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.

Сделать это будет легко: суммируем все поля количество в заказе выбранном по заказаИД из таблицы заказы выбранной по покупанИД.

В ответ на: А вот зачем суммировать количество разных артикулов: ума не приложу. Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.

Сделать это будет легко: суммируем все поля количество в заказе выбранном по заказаИД из таблицы заказы выбранной по покупанИД.

Я извиняюсь, зачем усложнять и удаляться от сабжа? Реквест на хелп был с четко сформированным заданием: "Можно ли сделать так, если дано вот так?". Первый же ответ был: "Можно". Вы имеете поспорить, что в скулевой таблице так нельзя сохранить данные? Или нельзя их так выбрать? Зачем это автору - другой вопрос. Мое мнение - просто упражнение, скажем, на курсе "Базы данных", именно на использование SUM() и GROUP BY в запросах...

Ну вот, пришел модер и стало скучно... а я только пивом затарился...

автору, тоже :

Блин, я ж тут модератор, точно... А я-то и не вспомнил с разгону, зачем я в раздел залез и зачем написал...

В ответ на: Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных и не надо мучиться с SQL'ем

Очень спорное утверждение.

В ответ на: Основные задачи проектирования баз данных

Основные задачи:
Обеспечение хранения в БД всей необходимой информации.
Обеспечение возможности получения данных по всем необходимым запросам.
Сокращение избыточности и дублирования данных.
Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

вам бы вот это почитать хотя бы с википедии

Сокращение != устранение.
Наличие избыточности данных
а) всегда бывает плохо с точки зрения теории и структуры
б) иногда хорошо с точки зрения производительности при эксплуатации
Опять же - наличие или отсутствие избыточности ничего не говорит о реляционности модели данных.

В ответ на: Вы не читали, поэтому и задаете такие вопросы. Автор темы тоже не читал.

Я все внимательно читал в отличии от некоторых.
Вы писали буквально следующее: "Такой таблицы быть не может. Потому что не может быть одинаковых уникальных имен/наименований в базе данных."

Теперь вдруг заясняете про какую-то культуру. Зачем?
Давайте вы уже определитесь: таки может или нет? замечу, натурный эксперимент дает однозначный ответ.

В ответ на: Каждый факт хранится в базе в единственном экземпляре. Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных

ТС где-то утверждает, что у него реляционная база? он где-то спрашивает реляционная ли она? нет? а зачем тогда вы все это пишите? Америку открываете?
Вот потому у нас на форумах вместо четrоко ответа по экселю начинают первым делом заяснять про оракл и как это круто. Не зависимо от вопроса. Все грамотные ведь.

В ответ на: А вот зачем суммировать количество разных артикулов: ума не приложу.

И? ваши рассуждения вслух кому-то интересны?

В ответ на: Скорее всего автор интерпрентировал задачу так, чтобы скрыть истинную цель.

Мировая закулиса готовим мировой заговор! Это ж понятно сразу по вопросу! нас гайками-болтами не собьёшь.

В ответ на: Если как в примере автора Вася фигурирует несколько раз, это не реляционная база данных и не надо мучиться с SQL'ем. Надо просто скопипастить ее в екзель и фильтрами корежить.

Подкину в вентилятор:
Почитайте, что означают термины "реляционная" и "нормализованная". И сравните...

Такой таблицы быть не может в базе данных. В ёкзеле, конечно, это обычное дело. Потому что это не база данных.

Ну хорошо, если у вас несколько идентичных Свет, вы как будете править поле 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, но не все так просто как кажется. Приходится терять время, проверяя входящие в целях сохранения своей базы данных как таковой. Иначе засрется в кратчайшие сроки так, что сам станешь таким же варваром.

Скажите, а вы видимо себя специалистом считаете, да?
Даете советы космических масштабов и космической же глупости так легко и непринужденно, что я, право, сударь, теряюсь

Если вы хотите чтобы ваш продукт развивался и продолжал приносить прибыль, придется читать "теоретиков" и вдалбливать культуру пользования базами данных. Испоганить можно самое блестящее проектирование. Поганый - значит язычник, многобожник. Но если мы считаем что люди себе не враги, то им достаточно объяснить что поддержание базы данных требует некоторых усилий и понимания и все пойдет на лад. Обычно это делается при помощи начальства. Ему объясняете, а оно уже принуждает. Отсюда растут требования к персоналу, а значит и рост зарплаты. Но зато один оператор хорошей базы стоит десятерых дятлов ковыряющих екзельные листы.

Сделайте в екзеле базу своей фототеки: make my day как говорится. В реляционной базе это делается за час и расти она будет годами под полным контролем юзера. И чем больше накапливается структуированных данных, тем выше их ценность. А куча хлама обесценивается, поскольку затраты на разбор завалов становятся непосильными.

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

Если в примере Вася это ID через который условные заказы связываются с условными покупанами, то почему name, а не ID? Но зачем суммировать запросом и группировать, если в таблицу покупанов можно добавить вычисляемое поле и пусть оно суммирует сколько на покупане висит заказов в таблице заказы через поле покупанID заказа.

Например http://sql-school.info/tutor/summirovan/funktsiya_183750.htm

Что-нибудь по существу изложите своими словами без цитат классиков.

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

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

парируйте, "специалист" вы наш. вы, простите, с чем работали? давно? долго? учились где-нибудь или так, обчитавшись грубера советы тут раздаете?

В ответ на: Скажите, а вы видимо себя специалистом считаете, да?

Дело даже не в том.
Приведена задачка из учебника первого класса на закрепление методов, изучаемых в этом же первом классе: поезда отходят от станций А и Б одновременно навстречу друг другу, двигаются равномерно, со скоростью такой-то, найдите время когда... ну и т.д.
Соответственно ее надо быстренько решать методами первого класса, и тут же переходить к следующей.

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

К чему это все - не понять. Похоже на типичного тролля.

В ответ на: а вы перечитайте начальный пост ТС и попробуйте представить, что все васи - это разные васи

Такого быть не может чтобы Вася был другой Вася. По условиям которые вы предлагаете еще раз прочитать, надо выбрать все имена == Вася и суммировать все заказы одного Васи.

В порядке апологии вы могли бы догадаться сказать что Вася это ID покупана, а гайка это ID товара и тогда перед нами таблица Заказы, с которой связаны таблицы Покупаны и Товары. Но вы доказываете ровно обратное. То есть подтверждаете мои же слова. Мило.

Автор сам за себя отвечал вполне. Да и вообще, мне-то что, хотите превратить ацес в абсцесс, пожалуйста. Забивайте гвозди микроскопом. Это по-нашему.

В ответ на: что Вася это ID покупана, а гайка это ID товара и тогда перед нами таблица Заказы

А это и есть ID покупателя.
Или ID непременно должно быть чем-то вроде 123550 на ваш взгляд?
Перед нами и есть таблица заказов, причем идеально нормализованная!

В ответ на: А это и есть ID покупателя.

Вы только что утверждали что это ID разных Вась.

Да, ладно, отстал...

Класс! Не даром пивом затарился... модерам - не сносить ни в коем рази! и-ик...

И так имеем задачку из первагу классу... асталось тока апределиться это те же Васи или другия...
и ваще, мож они и не покупаны вовся, а продаваны ... или эт-ти, как их, работягуны...

правда, нифига не понял, куда автор делся в пылу спора, ну да бог с ним! И без него весело.

Вот глядючи на весь этот сложный процесс, предлагаю перевести это в EAV модель и показать пример реализации на соответствующей БД... mongo к примеру или mumps...

Пошел за

автору и всем участникам

В ответ на: Вы только что утверждали что это ID разных Вась.

Вы меня с кем-то спутали. Не помню такого.

В ответ на: Надо сделать хитрый SELECT, чтоб sum у одинаковых имен сложился

вот дословно что написано

но вы настолько уперты, что не хотите прочесть очевидное

В ответ на: Такого быть не может чтобы Вася был другой Вася. По условиям которые вы предлагаете еще раз прочитать, надо выбрать все имена == Вася и суммировать все заказы одного Васи

то есть скорректированное условие задачи вам топикстартер передал каким-то образом через космос прямо в мозг минуя форум? ах какой негодяй этот топикстартер! накол его!

kostyanet, надеюсь SQL это не ваш хлеб?

Тссссс, неспугни =)

Дело в том, что это таблица импортированных значений из сторонней БД, а конкретнее из SAP а. Нумерные Id понятно дело разные, поэтому "Вася" это функциональное именование, которое отвечает за связывание соответствующих таблиц из разных баз

Чего непонятного то , я как прочитал первый пост - сразу догадался!