Join трех таблиц (две к одной)

[Alks]

Цитата:

Изначально опубликовано Nikolaich
Да, к сожалению это так - придется терпеть. Сам не понимаю зачем многих прелестей
SQL лишили - например, оператора Having и других...

Да в общем то понятно почему.
Свой формат SQL языка понадобился потому что невозможно иным способом реализовать:
1. Независимость от СУБД. Хвалёные ANSI стандарты SQL языка на деле оборачиваются головняками для программистов, реально пытающихся обеспечить многоплатформенность своих СУБД
2. автоматическое, независящее от программиста и присвоение, RecId
3. автоматическую фильтрацию базы по компании или вирт. компании - DataAreaId
4. поддержка опциональных полей creation/modification Date/Time и т.п.
5. доступ на уровне записи
6. ...много чего еще.

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

[mazzy]

Цитата:

Изначально опубликовано alexbn
SQL - (как DML) язык управления массивами данных! ЗАчем господам понадобилось убирать все приемущества (а именно операции с наборами данных)?
Почему появились конструкции типа while select?
- иммено это и есть пример плохого тона программирования!
Посмотрите трайс на sql-сервере ужаснётесь... оцените время выполнения сложного sql запроса с помощю AOS (для начала попробуйте его написать!) и с помощю analyser-а. (простым select-ом)

Уважаемый, почитайте руководство разработчика по поводу таблиц и jBest Practice для начала
http://technet.navision.com/usered/B...our_tables.htm

http://technet.navision.com/usered/B...tStatement.htm

http://technet.navision.com/usered/B...imizations.htm

и пожалуйста вспомните, что Аксапта оперирует не таблицами, а более широкими объектами у которых есть методы на X++

Обратите внимание на delete action и на autorelation.

[mazzy]

Цитата:

Изначально опубликовано alexbn
А если обновить поля одной таблицы по значениям из второй?
простая операция? - элементарная!

Да ну?
Элементарная ровно до тех пор пока вы находитесь на уровне таблиц и системного администратора.

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

Элементарно? Почему у вас не получилось обойтись ОДНОЙ таблицей?

[ta_and]

Хочу отдать свой голос в защиту механизма выборки и изменения данных, принятого в Axapte! Лучшего механизма я еще НИГДЕ не видел.
Query в Axapte - это просто шедевр по своей гениальности и простоте.
-----------------------------
Единственное что раздражает - это, действительно, невозможность строить "ветвистые" запросы не inner join и, иногда, отсутствие union и having... Наследие Дамгаарда...

Может быть это исправят в следующей версии? Будем надеяться.... очень...
я просто мечтаю об этом.

[alexbn]

Цитата:

Изначально опубликовано mazzy

и пожалуйста вспомните, что Аксапта оперирует не таблицами, а более широкими объектами у которых есть методы на X++

Обратите внимание на delete action и на autorelation.

Всё понимаю, но разговор идёт про конкретный ql в аксапте.
Аксапта оперирует в первую очередь данными, а методы - это способ сохранения целостности БД и реализация бизнес-логики.
Я говорю про невозможность операций с массивами данных используя механизмы СУБД sql-сервера. Либо здесь излишен sql-сервер (понофунциональный), либо плохой движок, реализующий лишь часть возможностей t-sql.

Так что ссылки на Best Practice - неуместны.
И если вы так уж уважаете Best Practice - то могу заметить что сами разработчки MBS довольно часто от них отступают.
тем более это мнение разработчика - которое никак не может быть стандартом де-факто. У людей из oracle другой взгляд на эти вещи.

Цитата:

Изначально опубликовано mazzy

вы выходите на уровень бизнес-логики.
Скопируйте, пожалуйста, строки журнала оплат.
Скопируйте, пожалуйста, строки заказа.
Элементарно? Почему у вас не получилось обойтись ОДНОЙ таблицей?

Куда скопировать? "Заказ" - это определённым способом постоенная логика, со своими данными, связями и методами контроля (триггерами, проверками и т.п.)... Тут речи не идёт об одной таблице. За "заказом" потянуться справочники и служебные данные.... Что вы хотели сказать этим примером? К чему он?
Повторяю - я говорю только о языке запросов и языке общения AOS с SQL-сервером,
а не про структуру бизнес-логики.

и ещё:

Цитата:

Изначально опубликовано Alks

Независимость от СУБД. Хвалёные ANSI стандарты SQL языка на деле оборачиваются головняками для программистов, реально пытающихся обеспечить многоплатформенность своих СУБД

многоплатформенность своих СУБД? насколько я знаю (если не прав - mazzy поправит - после этого пойду бить рожу тому кто это сказал ) - у MBS в планах - отказ от Oracle. насчёт кроссплатформенности клиента и AOS вообще не стоит говорить.
А всё дело в реализации стандарта sql в разных субд.

PS:

Цитата:

Изначально опубликовано ta_and

Может быть это исправят в следующей версии? Будем надеяться.... очень...

насколько я знаю то вопрос об обновлении движка не стоит.
mazzy - просвети а? а то мне тоже интересно.

[Alks]

Цитата:

многоплатформенность своих СУБД?

Да, это я коряво выразился. Имелась ввиду возможность держать свои БД в разных СУБД.

Цитата:

насколько я знаю (если не прав - mazzy поправит - после этого пойду бить рожу тому кто это сказал ) - у MBS в планах - отказ от Oracle.

Сомнительный шаг, хотя действительно поддержка Oracle - это поддержка конкурента.