Главная страница
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.053 c
1-1153996431
zrv
2006-07-27 14:33
2006.09.10
формирование XML-файла


6-1145631768
M@D
2006-04-21 19:02
2006.09.10
Error (INDY)


5-1138111947
Creative
2006-01-24 17:12
2006.09.10
обработчик onKeyDown


15-1155537715
Furyz
2006-08-14 10:41
2006.09.10
SWI.Чей это формат?


1-1153983714
Natalli
2006-07-27 11:01
2006.09.10
WinAmp ANDDelphi 7