Замена полей запроса на значения из других таблиц

[VBTerminator]

Здравствуйте,народ!

У меня есть две нижеприведённые таблицы (СУБД: MySQL версии 5):

Таблица 'поставщики':

Код: Выделить всё

id | имя
---+------------
1  | Василий
2  | Борис
3  | Иван

Таблица 'фрукты':

Код: Выделить всё

id |  фрукт   | поставщик | покупатель | дата покупки
---+----------+-----------+------------+--------------
1  | Банан    | 1         | 3          | 12-янв-2010
2  | Яблоко   | 2         | 1          | 15-янв-2010
3  | Абрикос  | 1         | 3          | 2-дек-2009


Подскажите, пожалуйста, как составить запрос, чтобы в выборке столбцы "поставщик" и "покупатель" содержали их имена?

Т.е. чтобы получилось следующее:

Код: Выделить всё

id |  фрукт   | поставщик | покупатель | дата покупки
---+----------+-----------+------------+--------------
1  | Банан    | Василий   | Иван       | 12-янв-2010
2  | Яблоко   | Борис     | Василий    | 15-янв-2010
3  | Абрикос  | Василий   | Иван       | 2-дек-2009


[FireFenix]

фрукты = fruits
фрукт = name
поставщик = seller
покупатель = buyer
дата покупки = date

поставщик = sellers
имя = name

Код: Выделить всё

SELECT
    fruits.id
  , fruits.fruit
  , fruits.date
  , seller.name as 'продавец'
  , byer.name as 'покупатель'
FROM
    fruits
LEFT JOIN
    sellers as seller
ON
    fruits.seller=sellers.id
LEFT JOIN
    sellers as byer
ON
    fruits.buyer=sellers.id;

Как-то так...

P.S. Делать русские название столбцов - плохой пример, особенно если через пробел!

[SLIM]

Код: Выделить всё

select id, [фрукт],  (select [имя] from [поставщики] p where p.id=m.[поставщик]) [поставщик],  (select [имя] from [покупатели] p where p.id=m.[покупатель]) [покупатель], [дата покупки]
from [фрукты] m


[SLIM]

P.S. Делать русские название столбцов - плохой пример, особенно если через пробел!

Русские имена куда еще не шло.
Куда хуже структура таблицы [фрукты]. Зачем хранить поставщиков в таблице с продажами? А если это таблица с поставками - то зачем хранить продажи? А если это таблица операций, то почему структура вообще такая?
Здесь нужно разделить продажи от поставок однозначно.

[Andrey Fedorov]

P.S. Делать русские название столбцов - плохой пример, особенно если через пробел!

Русские имена куда еще не шло.

Собственно в русских именах с точки зрения сопровождения нет ничего плохого. Это гораздо удобней чем разгадывать абракадабру транслита или думать что означает некое англоязычное название...

[arvitaly]

Собственно в русских именах с точки зрения сопровождения нет ничего плохого. Это гораздо удобней чем разгадывать абракадабру транслита или думать что означает некое англоязычное название...

[Andrey Fedorov]

Собственно в русских именах с точки зрения сопровождения нет ничего плохого. Это гораздо удобней чем разгадывать абракадабру транслита или думать что означает некое англоязычное название...

И что тут смешного? Если база для российской конторы, то это очень даже удобно, особенно когда поддерживаешь ее раз в год (есть у меня и такие). Никаких проблем из-за русских имен нет. А вот быстрей разобраться в сотнях таблиц/процедур реально помогает.

[SLIM]

И что тут смешного? Если база для российской конторы, то это очень даже удобно, особенно когда поддерживаешь ее раз в год (есть у меня и такие). Никаких проблем из-за русских имен нет. А вот быстрей разобраться в сотнях таблиц/процедур реально помогает.

Смешного то особо ничего нет. Меня вот улыбнуло что приходится разбираться с абракадаброй транслита. Зачем давать сущностям имена на транслите? Нужно задавать смысловую нагрузку английскими словами. Тогда и разобраться будет проще.

[FireFenix]

Собственно в русских именах с точки зрения сопровождения нет ничего плохого. Это гораздо удобней чем разгадывать абракадабру транслита или думать что означает некое англоязычное название...

И что тут смешного? Если база для российской конторы, то это очень даже удобно, особенно когда поддерживаешь ее раз в год (есть у меня и такие). Никаких проблем из-за русских имен нет. А вот быстрей разобраться в сотнях таблиц/процедур реально помогает.

Да ну... Создание имён, переменных, других названий считается плохим тоном как и я зык 1С (взрывоопасно для мозга)
Мешать английский код с русскими запросами - плохо

Никаких проблем из-за русских имен нет

А если использовать английские, то сильно запутаешься? или долго вспоминать как переводится?
При правильном назначении столбцов и понимании функциональности - всё вспоминается довольно быстро, даже после 5ти лет возвращения

Английские - я имел ввиду чистый английский... Транслит в названиях - уныло и глупо...

[Andrey Fedorov]

Да ну... Создание имён, переменных, других названий считается плохим тоном как и я зык 1С (взрывоопасно для мозга)

Ни то ни другое вообще-то плохим тоном не являются. Да и чего ради? У всего свои области применения.

Мешать английский код с русскими запросами - плохо

Голословно. Что плохого в русскоязычном названии полей/таблиц/запросов?

А если использовать английские, то сильно запутаешься? или долго вспоминать как переводится?

Страдание комплексами от своего же языка... Тогда уж в Лондон переехать - там везде английский.

[iGrok]

как и я зык 1С (взрывоопасно для мозга)

Да ничего подобного. Тот же вб, только сбоку. Если у ТЕБЯ взрывается мозг от одного его вида, это не значит, что язык плохой. У меня вот не взрывается.

Русские имена полей в базе... Не вижу в этом ничего криминального. Вот именование полей базы 1С на sql-сервере, это да. Это жесть. Транслит - тоже жесть. А русские или английские говорящие имена - вполне нормально.

[FireFenix]

Страдание комплексами от своего же языка... Тогда уж в Лондон переехать - там везде английский.

Ты ведь код пишешь англ. лексемами, т.е. у тебя комплекс англ языка?

Да ничего подобного. Тот же вб, только сбоку

Ну если бы ты с Д сравнил, куда не шло, но Vb использует англ лексемы

Если у ТЕБЯ взрывается мозг от одного его вида, это не значит, что язык плохой

Если используются русские столбцы в SQL, то надо же как-то составлять запрос из них, а для этого нужны либо русские переменные, либо англ переменные, которые соответствуют русским столбцам...
Когда просто SQL отдельно - ещё ладно, когда всё в купе - ад...

Обычно использовать русские имена любят новички, тогда как и качество разбираемого кода оставляет желать лучшего...

[Andrey Fedorov]

Ты ведь код пишешь англ. лексемами, т.е. у тебя комплекс англ языка?

Абсолютно нет - если заказчик забугорный, то все делаю на английском (сейчас как раз такой проект).
И комплекса русского языка я не имею, в отличии...

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

В чем проблема-то, в конце-концов? В том что что-то обозвано не на языке заморской империи? Или трудно переключать раскладку клавиатуры?

Обычно использовать русские имена любят новички, тогда как и качество разбираемого кода оставляет желать лучшего...

Промашка, однако.

[iGrok]

использует англ лексемы

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

Ты можешь хоть один серьёзный аргумент привести, или нет?

[VBTerminator]

Большое всем спасибо!

P.S. Делать русские название столбцов - плохой пример, особенно если через пробел!

Если используются русские столбцы в SQL, то надо же как-то составлять запрос из них, а для этого нужны либо русские переменные, либо англ переменные, которые соответствуют русским столбцам...Когда просто SQL отдельно - ещё ладно, когда всё в купе - ад...

Спасибо за совет, буду исправлять названия (благо, доступ к базе есть).

Куда хуже структура таблицы [фрукты]. Зачем хранить поставщиков в таблице с продажами? А если это таблица с поставками - то зачем хранить продажи? А если это таблица операций, то почему структура вообще такая?
Здесь нужно разделить продажи от поставок однозначно.

Вы про создание ещё одной таблицы "Покупатели"? Но тогда будет две абслютно одинаковых таблицы с продавцами и покупателями (т. к. один и тот же человек может продавать и покупать фрукты).

[SLIM]

Вы про создание ещё одной таблицы "Покупатели"? Но тогда будет две абслютно одинаковых таблицы с продавцами и покупателями (т. к. один и тот же человек может продавать и покупать фрукты).

Я о том что не стоит хранить разные операции в одной таблице. Т.е. продажи и поставки.
По поводу создания таблицы "Покапутели" то не нужно. Хватит таблицы "Контрагенты".

[iGrok]

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

Вот что имеет смысл, так это разбить её на "товары" и "операции".

А вообще, всё это домыслы, т.к. реальной сути операций мы с тобой не знаем. )

[SLIM]

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

[VBTerminator]

По поводу создания таблицы "Покапутели" то не нужно. Хватит таблицы "Контрагенты".

Вы про переименование таблицы "Поставщики" в "Контрагенты"?

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

Да, причём один вид фруктов продаётся одним человеком и закупается тоже кем-то одним (пока), поэтому отношения между таблицами "Контрагенты" и "Фрукты" - "один-ко-многим". Из-за этого разбить таблицу "Фрукты" на "Товары" и "Операции" не имеет смысла.

[SLIM]

Вы про переименование таблицы "Поставщики" в "Контрагенты"?

Контрагенты - это и покупатели и поставщики. Имелось ввиду иметь справочник контрагентов с соответствующим делением.
Но если это действительно прямые продажи, то пойдет и так.