Какой-то сложный у меня запрос получается?
 

Народ, 3 часа ночи, что-то я тормозить начал - не могу запрос придумать.
Есть несколько таблиц, примерно одинакового содержания, в которых есть поле dPrice. Нужно сложить все данные в этом поле по всем таблицам. Что-то не придумаю(((.

И не придумаешь. При работе с правильно спроектированной базой такое желание не должно появляться.

Крези, это уже не вопрос организации базы. У меня есть несколько таблиц - orders_plains, orders_trains, orders_partitions - разной структуры. Но во всех них есть есть поле dPrice. Мне нужно сотставить запрос, который забрал бы из всех этих таблиц стоимость услуг соответствующий какому-то заказу (iOrderID). Конечно, можно было бы составить запрос для каждой из таблиц, и сложить все данные, но почему бы не предоставить эту задачу СУБД, а не ПХП? Только вот моего знания SQL что-то не хватает, не могу составить запрос...

Еще раз: если подлежашие суммированию поля разнесли по разным таблицам -- это ошибка проекитирования.

Продвинутые СУБД имеют расширения SQL, позволяющие делать такие странные операции. К примеру, в MS SQL ты можешь сделать хранимую процедуру, которая не сервере выполнит три запроса, произведет суммирование и вернет результат.

Гм... с какой-то стороны ты и прав, можно запихнуть стоимость в отдельную таблицу... сенкс за мысль...
Вопрос:
где у меня ошибка в этом запросе?
SELECT dPrice from orders_propositions UNION SELECT dPrice FROM orders_transfers;
мускуль настойчиво говорит мне, что запрос неправельно составлен, хотя, насколько я помню синтаксис SQL (я не очень продвинут в запросах на объединение), все правильно написано.

В твоей версии MySQL тебе кем-то был обещан UNION?

Хммм ...

select sum (table1.dPrice + table2.dPrice + table3.dPrice) from table1, ...

чего то не так возвращает?

Мысля рульная, сейчас попробую... не... не рульная...
что пробывал -
SELECT orders_propositions.dPrice+orders_transfers.dPrice as dAllPrice FROM orders_propositions,orders_transfers WHERE orders_propositions.iOrderID=orders_transfers.iOrderID;


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

Так вот, кидаю новый заказ, в нем - только путевку, без трансфера - и получаю в ответ на запрос - пустое поле((
А сточки зрения организации БД - по-моему - лучше не придумаешь. Хотя мне девятнадцать, и я не в коем случае не считаю себя супер-пупер.

Мля, где функция SUM в том что ты пробывал?

SELECT sum(orders_propositions.dPrice+orders_transfers.dPrice)as dAllPrice FROM orders_propositions,orders_transfers WHERE orders_propositions.iOrderID=orders_transfers.iOrderID;


А насчет организации, с каждым разом будет лучше ;)

Эта конструкция в зависимости от того, что прописано в where, либо отработает верно, либо вернет бред.

Простейший пример: в таблицаз живут значения за три разных месяца...

Полностью согласен. Интересно было-бы все-таки взглянуть на эту структуру.

Кстати, Chas, ты ведь сам сказал что у тебя "несколько таблиц с примерно одинаковым содержанием" ... Это очень не верно. Информация может повторяться только в очень редких случаях :
1, редунданция для критических запросов (тобиш повторяющаяся информация которая "облегчает" работу базы данных)
2, упрощенная структура (где данные в таблицах не полностью изолированны) что-бы упростить с нею работу.

Вот тебе кусок бекапа - оцени:

create table orders
(
iID int (12) primary key auto_increment,
dtCreationDate date,
iCustomerID int (6),
dPaid double (10,4)
);
create table orders_trains (
iID int (6) primary key auto_increment,
iOrderID int (6),

iCarType int (2),
iDirectionType int (2),
sTrainNumber varchar (6),

dtArrivingDate date,
sArrivingTime varchar (10),
dtDepartureDate date,
sDepartureTime varchar (10),
dPrice double (10,4)
);
create table orders_propositions (
iID int (6) primary key auto_increment,
iOrderID int (6),
iPropositionID int (6),
sService varchar (250),
dPrice double (10,4)
);
create table orders_transfers (
iID int (6) primary key auto_increment,
iOrderID int (6),
sArrivingPlace varchar (100),
iTransportType int (2),
iArriving int (2),
dtArrivingDate date,
sArrivingTime varchar (10),
sArrivingIssue varchar (10),
iDeparture int (2),
dtDepartureDate date,
sDepartureTime varchar (10),
sDepartureIssue varchar (10),
dPrice double (10,4)
);
Поставленная задача - человек делает заказ покупает, скажем путевку, билет на поезд Киев-Симферополь и трансфер из Симферополя в Ялту в пансионат. Сделать - веб-интерфейс, чтобы можно было делать подобные заказы и тут же получать счет по мылу - где все расписано - что-почем-куда. Для этой же базы - веб-интерфейс администратора - чтобы он мог указать статус заказа (оплачен-неолачен-просрочен-аннулирован), распечатать ваучер, статистику, добавить новый пансионат/группу заездов - короче - я уже около 2х месяцев с ней работаю. Правда администраторскую часть я пишу в Access. Соединил ODBC-драйвером с мускулем. Очень удобно в аксессе проэктировать формы, отчеты.

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

Гм... iOrderID нельзя использовать в качестве ключевого поля -один заказ соответсвует нескольким услугам, у каждой из которых своя цена, orders_trains.iID или orders_transfers.iID имеют свою независимую нумерацию... тогда нужно создавать таблицу типа - orders_prices (iPriceID, dPrice), а в каждой из orders_trains, orders_propositions - заменить dPrice на iPriceID - дурдом... по-другому - не вижу как.
Думаю сделать следующее - в orders - добавить поле dPrice и каждый раз при добавлении новой услуги - пересчитывать поле общей стоимости. Мне думается, так будет и мне удобней работать, и отчеты быстрей будут выполняться типа - сколько у нас заказов за этот месяц...

Если начать с концептуальной модели, то ответ звучит просто: наследование. Т.е. создается entity Prices, содержащий поле dPrice, от которого наследуются нужные таблицы.

Разумеется, нужно построить физическую модель. Если мы строим ее по схеме "генерация родителя и потомков с наследованием ключа", то получается тот способ, который ты описал как "заменить dPrice на iPriceID".

При другом варианте генерации PK потомков перетекают в родителя. В этом случае никакого iPriceID не будет, а в таблицк цен будет композиция всех ключевых полей из твоих таблиц.

Что же до дурдома, то на него вполне похож третий -- на самом деле тоже логичный -- вариант: ВСЕ генерится в одну таблицу с композицией всех собственных полей наследников с полем dPricе, доставшимся от папы.

Обращаю внимание: все три схемы логически эквивалентны и в каждой из них dPrice лежит ровно в одной таблице.

Не забудь про блокировки. Этот способ хорош в плане минимизации правок, но потенциально может создать больше всего проблем.

Ё-мое! Неет, столько пива не бывает. Крези, я теперь знаю, почему Вас крези величать)))))))))))))))))) Блин, если бы во всех моих книгах принципы БД были описаны ТАК, я бы до сих пор бесиком баловался.
Я... я прям зауважал старшее поколение )))
ЗЫ. Так. Тред переходит во флуд. Спасибо г-ну Комраду за совет с запросом - попробую еще раз.
ЗЗЫ: Крези, хотелось бы мне на кусок вашей базы глянуть...

ты зря так ... дельное говорит comarada Крэзи

а что до запроса, попробуйте батенька ... главное в where все правильно выставьте ... Один null и будет опять пустое поле

Мне до батеньки еще очень далеко.... во всех смыслах...
Я отлично понял все, что сказал Крези, просто, ЗАЧЕМ говорить таким сложным языком. У меня однажды был препод по БД в универе, который советовал нам книгу 82 года рождения, писал в Delphi 3 и называл таблицу картотекой. Ну... разве в этом профи? ЗАпрос попробую завтра. У меня местное время - 3 часа ночи.

а в библии тоже много че интересного? а когда она написана? в общем я опоздал, это точно. эх. хороший тред получился.

Ты в состоянии сказать это проще без потери смысла?

Называть таблицу картотекой -- неграмотно. Что до книг, то второе издание книги Дейта "Введение в системы баз данных" вышло на русском языке в 1980г. :) Сейчас продается седьмое издание, но от чтения второго пользы будет не сильно меньше. Что любопытно, имеется об этой книге вот такое мнение: "Если книгу 1980 года я смело рекомендовал и продолжаю рекомендовать в качестве учебника для студентов, то уже книгу 1999 года я рекомендую начинающим студентам только с оговорками.". Цитата отсюда.

При чем здесь Delphi 3 -- осталось для меня загадкой... :)

To Crazy

Crazy, вижу вы действительно знаете толк в базах данных.
Задавать вопросы конкретно по моему заданию считаю излишней наглостью, но не могли бы вы немного рассказать ил хоть дать толковые ссылки на материалы по поводу (лучше всего Delphi, но можно и общие концепции или PHP compiled):


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

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

3) есть ли у вас личные наработки по компиляции РНР-скриптов для локального сполнения. Видел много программ для компиляции, но они либо перегоняют либо в С код, либо работают из коммандной строки, либо непонятно что делают. Никаких намеков на GUI-интерфейс, описанный в литературе, или изображенный в примерах gtk. Я, конечно допускаю что я просто баран или использую старые версии софта, но я наверняка не один. Если можете что-либо сказать из личного опыта, буду безгранично благодарен.