Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.09.10;
Скачать: CL | DM;

Вниз

SQL-запрос   Найти похожие ветки 

 
Evlahov ©   (2006-08-16 16:11) [0]

Помогите пожалуйста!
Имеются две таблицы PLAT (платежки (PLAT.№,  PLAT.ORG_P,  PLAT.ORG_B)) и ORG (организации (ORG.№, ORG.NAME)) В таблице PLAT хранятся данные (Организация получатель и Банк получатель) данные добавляются из таблицы ORG (организации). Таблицы связаны (ORG.№ -первичный ключ), (PLAT.ORG_P,  PLAT.ORG_B – внешние ключи)
Вопрос как написать запрос чтобы вывести наименование организации ПОЛУЧАТЕЛЯ и наименование БАНК ПОЛУЧАТЕЛЬ


 
Desdechado ©   (2006-08-16 16:21) [1]

SELECT P.№, O.name, B.name
FROM Plat P, Org O, Org B
WHERE P.org_p = O.№ AND P.org_b = B.№


короче, таблицу можно несколько раз с разными псевдонимами в FROM указывать


 
evvcom ©   (2006-08-17 08:34) [2]

> [0] Evlahov ©   (16.08.06 16:11)

У тебя организации и банки в одной куче? Неверный подход. Насчет банков: вообще лучше взять официальный файл Центробанка и с ним работать.


 
StriderMan ©   (2006-08-17 10:09) [3]


> Desdechado ©   (16.08.06 16:21) [1]

ИМХО лучше JOIN использовать при выборе из нескольких таблиц.


 
Sergey13 ©   (2006-08-17 10:13) [4]

> [3] StriderMan ©   (17.08.06 10:09)

Он и так будет по любому. А внешний тут вроде смысла не имеет.


 
Desdechado ©   (2006-08-17 11:33) [5]

> У тебя организации и банки в одной куче? Неверный подход.
Почему? А что, банк - не организация, что ли? И один банк заплатить другому не может что ли сам за себя, а не за клиента?
Хотя возможны варианты (например, открыть счет для себя у себя :)

StriderMan ©   (17.08.06 10:09) [3]
Методологически - да. Тогда легко визуально разделяются соединения таблиц и ограничивающие условия. Не зря именно так стандарт рекомендует.
Но привычка, как говорят, - вторая натура.


 
evvcom ©   (2006-08-17 13:52) [6]

> [5] Desdechado ©   (17.08.06 11:33)
> Почему? А что, банк - не организация, что ли?

Организация. Но... Банк может выступать как обычный контрагент (дебитор/кредитор) со всеми платежными реквизитами: ИНН, наименование и таблицей счетов: БИК банка (внешний ключ), № счета и пр. И может выступать как (как бы это точнее выразить) посредник при совершении финансовых сделок со своим наименованием, БИКом (первичный ключ) и пр. Это разные сущности.
Собрав все это в одну кучу, мы добавляем себе лишнего геморроя. Таблица со счетами (ее логика) должна будет постоянно следить при записи ключа банка, а банк ли это? Автор ничего не сказал про используемую им СУБД, но я так подозреваю, что опять какой-нить dBase или Paradox. В этом случае с таблицей банков вообще не будет геморроя с обновлением, если брать Центробанковский файл в неизменном виде.
Ладно, все ИМХО. Но именно с банками и платежами я в свое время возился при внедрении SAP R/3 на предыдущем месте работы, и там именно так и было построено.


 
Evlahov ©   (2006-08-18 17:22) [7]

СУБД использую InterBase. Большое спасибо за помощь, все получилось.



Страницы: 1 вся ветка

Текущий архив: 2006.09.10;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.044 c
15-1155426441
SerJaNT
2006-08-13 03:47
2006.09.10
Выбор машины


6-1145860570
cosmos
2006-04-24 10:36
2006.09.10
Ошибка подключения к Paradox через ADO


2-1156068282
Neket
2006-08-20 14:04
2006.09.10
Буфер обмена


1-1154237394
tio
2006-07-30 09:29
2006.09.10
Вывод окна на передний план


15-1155547420
Darkwing
2006-08-14 13:23
2006.09.10
Оценка труда программиста.