Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.12.05 17:05
Оценка: :)
Здравствуйте, ie, Вы писали:

ie>IntelliSense — вряд ли.


Не вряд ли, а так и есть. Информация из первых рук.

ie>Почему-то с foreach таких заморочек небыло, а тут на тебе. А в для редактора эти проблемы должны решаться с помощью код-сниппетов, а не с помощью дескриминации читаемости выражений.


Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.

КО>>Другое дело мы уже к SQL привыкли...


ie>То-то и оно


Это даже хорошо, потому что, при внешней похожести, по семантике LInQ очень серьезно отличается от SQL.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>

08.01.06 21:31: Ветка выделена из темы Чего не хватает в C#?
Автор: Кирилл Осенков
Дата: 07.12.05
— AndrewVK
AVK Blog
Re[5]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.05 00:07
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

AVK>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


Извини конечно но это полная фигня. Граматика для SQL валяется на АНТЛР-овском сайте. Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.

И вообще, язык деларативный. Запросы маленькие. Так что проблем тут никаких. Другое дело, что в этом самом линке далеко не SQL. Хотя тому же Васику это почему-то немешает. В нем select пока что спереди. И я уверен, что интелисенс в нем будет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Язык запросов: from в начале
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.12.05 08:23
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndrewVK, Вы писали:


AVK>>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


VD>Извини конечно но это полная фигня. Граматика для SQL валяется на АНТЛР-овском сайте. Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.

О! Покажи мне такой!
Я вот совершенно не понимаю, как может работать хоть какой-то интеллисенс. Он же должен работать слева направо?
Вот я набрал
sel|

Ага, тут мне интеллисенс подскажет — select. Это ежу понятно. Возможных начал стейтментов не так и много в T-SQL.
Ок, я набрал
select |

А дальше что? У меня нет никакого контекста. Я могу набрать *, или алиас.*, или имя поля, или алиас.поле... Вот пример запроса:
select t.id, maxvalue, name from (select id, max(value) as maxvalue from myTable group by id) t 
  inner join myOtherTable k on k.id = t.id

здесь MyTable.id — это FK в myOtherTable. В myOtherTable есть Name.
Вот тут я повставлял символы | в тех местах, где мне интересно поителлисенсить. Представь себе, что в каждом из них набрано только то, что слева. Что ты собираешься мне показать в списке кандидатов? Как в нем окажется то, что я на самом деле написал? :
select |t.|id, |maxvalue, |name from (select |id, |max(value) as maxvalue from |myTable group by |id) t 
  inner join |myOtherTable k on |k.id = |t.id


Дай хотя бы намек — ведь проблем никаких нет.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 19.12.05 08:51
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Извини конечно но это полная фигня.

Мне эта фигня жить мешает... Как камушек в ботинке.

VD>Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.

Приличный он только если с Ноутпадом сравнивать, ты все равно вынужден санчала указать объекты в From, а потом вернуться к select-у и заниматься изнурительным интелисенсом со списком полей. Озлобляет.

VD>Запросы маленькие.



VD>Так что проблем тут никаких.

Влад, "таким бы хлебальцем, да медка бы навернуть"..

VD>Хотя тому же Васику это почему-то немешает. В нем select пока что спереди. И я уверен, что интелисенс в нем будет.

Только такой же кривой как в foreach-е.

Я очень надеюсь что в шарпе все так и останется и они не вынесут select в начало.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.05 08:57
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


VD>Извини конечно но это полная фигня. Граматика для SQL валяется на АНТЛР-овском сайте.


Грамматика тут не при чем.

VD> Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.


Значит у нас разное понимание приличного.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[7]: Язык запросов: from в начале
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 19.12.05 11:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>
S>select |
S>

S>А дальше что? У меня нет никакого контекста. Я могу набрать *, или алиас.*, или имя поля, или алиас.поле...

Это ясно. Но ведь согласитесь, не обязательно настолько круто предугадывать. Варианты:
1. select * from |[выпал список таблиц]
2. select t.|[выпал список полей] from table t
Лично мне достаточно было бы и этого.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Вселенная бесконечна как вширь, так и вглубь.
Re[8]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.05 12:08
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Это ясно. Но ведь согласитесь, не обязательно настолько круто предугадывать.


По нынешним временам пожалуй уже обязательно. А главное — ради наличия такой функциональности лично я согласен привыкнуть к select в конце фразы.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[7]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Ок, я набрал

S>
S>select |
S>

S>А дальше что? У меня нет никакого контекста. Я могу набрать *, или алиас.*, или имя поля, или алиас.поле...

Если ты о том как поступают имеющиеся приложения в таких случаях, то все просто. Они просто предлагают список таблиц (а то и полей) из БД. Если уже имеется часть "from", то список алиасов и таблиц из него.

S> Вот пример запроса:

S>
S>select t.id, maxvalue, name 
S>  from (select id, max(value) as maxvalue from myTable group by id) t 
S>  inner join myOtherTable k on k.id = t.id
S>

S>здесь MyTable.id — это FK в myOtherTable. В myOtherTable есть Name.
S>Вот тут я повставлял символы | в тех местах, где мне интересно поителлисенсить. Представь себе, что в каждом из них набрано только то, что слева. Что ты собираешься мне показать в списке кандидатов? Как в нем окажется то, что я на самом деле написал? :
S>
S>select |t.|id, |maxvalue, |name from (select |id, |max(value) as maxvalue from |myTable group by |id) t 
S>  inner join |myOtherTable k on |k.id = |t.id
S>


S>Дай хотя бы намек — ведь проблем никаких нет.


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

Потом нужно понимать, что если комплит даст несколько больше, то хуже не будет. Так что если ты даже дашь все поля и таблицы/алиасы из запроса, то тебе скажут только спасибо.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка: +1 -2
Здравствуйте, AndrewVK, Вы писали:

AVK>По нынешним временам пожалуй уже обязательно. А главное — ради наличия такой функциональности лично я согласен привыкнуть к select в конце фразы.


А что изменит положение селекта?

Все будет тоже самое. Ну, разве что позволяет надеяться, что from к этому мометну уже будет полностью сформирован. Ну, так нет проблем селек и вперед вписывать только после того как весь запрос сформирован.

Я вообще не понимаю такую заботу о вводе при полной наплевательстве на читаемость текста. Ты его ровно один раз писать будешь, а вот читать еще мног-много раз. Так что это плохое решение.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка:
Здравствуйте, Merle, Вы писали:

VD>>Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.

M>Приличный он только если с Ноутпадом сравнивать, ты все равно вынужден санчала указать объекты в From, а потом вернуться к select-у и заниматься изнурительным интелисенсом со списком полей. Озлобляет.

Ну, и что. Ну, напишу я "*", а потом вернусь и заменю ее на то что нужно.
Нельзя же ради микроскопического удобства при вводе плевать на читаемость?!

VD>>Запросы маленькие.

M>

А что ты улыбаешься? Сравни их размер с мало-мальским проектом на Шапе. Я уеже не говорю о плюсах.

VD>>Хотя тому же Васику это почему-то немешает. В нем select пока что спереди. И я уверен, что интелисенс в нем будет.

M>Только такой же кривой как в foreach-е.

Ты видил что говоришь?

M>Я очень надеюсь что в шарпе все так и останется и они не вынесут select в начало.


А я надеюсь они все же исравят эту кривоту. Читать это прийдется все же чаще чем писать. Да и нет особых проблем с написанием. То же мне проблема — отложить написание строчки на пару секунд.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 01:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Грамматика тут не при чем.


А что же тут причем? Неужели тебе сложно отложить написание этого самого select самостоятельно, а не по тычку авторов языка?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Язык запросов: from в начале
От: ie Россия http://ziez.blogspot.com/
Дата: 20.12.05 03:58
Оценка: 23 (1) :)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:


AVK>>>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


VD>>Извини конечно но это полная фигня. Граматика для SQL валяется на АНТЛР-овском сайте. Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.

S>О! Покажи мне такой!
S>Я вот совершенно не понимаю, как может работать хоть какой-то интеллисенс. Он же должен работать слева направо?

Влад тут уже изложил, совпадающую с моей, точку зрения на эту проблему, поэтому я во многом его повторю.
Работать слева направо — тут, безусловно, никаких возможностей не представляется. Ну не гадалка intellisence, чтоб угадывать откуда я from буду делать и по каким полям буду группировать... Однако, мне понравилось решение предлагаемое разработчиками РеШарпера для цикла foreach (к сожалению, разработчики студийного intellisence не сделали аналогично), т.е. в первую очередь указывается енумератор, а уж затем вводиться тип и название переменной цикла.
Так вот мое мнение, что не имеет смысла пытаться что-то угадать мысли разработчика или выкидывать неимоверный по объему список, а следует уточнить откуда он хочет делать выборку, а уже потом вернуться к select-части.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[8]: Язык запросов: from в начале
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.12.05 04:50
Оценка: +4
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sinclair, Вы писали:


S>>Ок, я набрал

S>>
S>>select |
S>>

S>>А дальше что? У меня нет никакого контекста. Я могу набрать *, или алиас.*, или имя поля, или алиас.поле...

VD>Если ты о том как поступают имеющиеся приложения в таких случаях, то все просто. Они просто предлагают список таблиц (а то и полей) из БД.

Влад, ты себе представляешь объем этого списка? Учитывая то, что можно указывать а) имя базы и б) имя связанного сервера? Это же бесконечная простыня.
Видел я такое решение у какой-то приблуды к interbase. Полезность = 0, т.к. не дождешься, пока оно список полей вытащит, и угадывает оно крайне редко.
VD>Если уже имеется часть "from", то список алиасов и таблиц из него.
Дело хорошее. Но это требует написать сначала from, а потом уже select. Догадываешься, к чему я клоню?
S>> Вот пример запроса:
S>>
S>>select t.id, maxvalue, name 
S>>  from (select id, max(value) as maxvalue from myTable group by id) t 
S>>  inner join myOtherTable k on k.id = t.id
S>>

S>>здесь MyTable.id — это FK в myOtherTable. В myOtherTable есть Name.
S>>Вот тут я повставлял символы | в тех местах, где мне интересно поителлисенсить. Представь себе, что в каждом из них набрано только то, что слева. Что ты собираешься мне показать в списке кандидатов? Как в нем окажется то, что я на самом деле написал? :
S>>
S>>select |t.|id, |maxvalue, |name from (select |id, |max(value) as maxvalue from |myTable group by |id) t 
S>>  inner join |myOtherTable k on |k.id = |t.id
S>>


S>>Дай хотя бы намек — ведь проблем никаких нет.


VD>Во втором случае вообще никаких проблем нет. Есть и список алиасов, и джоин.

В смысле? Какой второй случай? Тут ровно один случай. Откуда есть список алиасов? Не знаю как ты, а я лично набираю слева направо. И оказывается, что твой безпроблемный парсинг не подскажет мне ничего почти ни в один момент при наборе этого стейтмента. Я вот вижу всего 3 точки из 11, где есть хоть какой-то шанс включить в список то что нужно. И, спрашивается, нафига нужен такой интеллисенс? Причем еще и назойливый — в 8 точках он будет мне показывать все что угодно вместо того, что мне надо.
VD>Все это без проблем парсится и предлагается для комплита.
VD>Потом нужно понимать, что если комплит даст несколько больше, то хуже не будет. Так что если ты даже дашь все поля и таблицы/алиасы из запроса, то тебе скажут только спасибо.
Влад, проблема в том, что алиас может появиться в любой момент. И комплит даст не просто больше, а вообще не то.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Язык запросов: from в начале
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.12.05 04:50
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:
VD>А что же тут причем? Неужели тебе сложно отложить написание этого самого select самостоятельно, а не по тычку авторов языка?
А ЗАЧЕМ?
Влад, читаемость селекта связана только с вредной привычкой. Я тебя уверяю — поработай плотненько с from ... select и ты будешь удивляться, как ты вообще мог читать этот ужасный SQL. Необходимость прыгать вперед-назад при наборе удручает со страшной силой.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 05:35
Оценка: +2
Здравствуйте, VladD2, Вы писали:

AVK>>По нынешним временам пожалуй уже обязательно. А главное — ради наличия такой функциональности лично я согласен привыкнуть к select в конце фразы.


VD>А что изменит положение селекта?


На момент его написания в конце есть полная информация о том, что там можно подставить, следовательно intellisense будет работать в полном объеме.

VD>Все будет тоже самое. Ну, разве что позволяет надеяться, что from к этому мометну уже будет полностью сформирован. Ну, так нет проблем селек и вперед вписывать только после того как весь запрос сформирован.


Только так никто не делает

VD>Я вообще не понимаю такую заботу о вводе при полной наплевательстве на читаемость текста.


А по мне так читаемость не хуже. Просто непривычно несколько. Никакого принципиального ухудшения по сравнению с селектом вначале лично я не вижу.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[8]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 05:35
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>А что же тут причем? Неужели тебе сложно отложить написание этого самого select самостоятельно, а не по тычку авторов языка?


Сложно. Потому что раком.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[8]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 20.12.05 09:20
Оценка: +1 -1
Здравствуйте, ie, Вы писали:

ie>Работать слева направо — тут, безусловно, никаких возможностей не представляется. Ну не гадалка intellisence, чтоб угадывать откуда я from буду делать и по каким полям буду группировать...

В этом-то и проблема.

ie>Однако, мне понравилось решение предлагаемое разработчиками РеШарпера для цикла foreach <...>

Это не решение, а замазка. По удобству оно все равно значительно уступает обычному ителлисенсу.

ie>Так вот мое мнение, что не имеет смысла пытаться что-то угадать мысли разработчика или выкидывать неимоверный по объему список, а следует уточнить откуда он хочет делать выборку, а уже потом вернуться к select-части.

Правильно. Только возвращаться к select части — не удобно, очень неудобно и гораздо правильнее вынести select в конец, раз есть такая возможность.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 20.12.05 09:20
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

VD>Ну, и что. Ну, напишу я "*", а потом вернусь и заменю ее на то что нужно.

Еще раз: это не удобно, ну неудобно это.

VD>Нельзя же ради микроскопического удобства при вводе плевать на читаемость?!

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

VD>А что ты улыбаешься? Сравни их размер с мало-мальским проектом на Шапе. Я уеже не говорю о плюсах.

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

VD>Ты видил что говоришь?

Ессесно, причем я имел ввиду даже продвинутый решарперовский.

VD> Читать это прийдется все же чаще чем писать.

Читать это нисколько не мешает.

VD> Да и нет особых проблем с написанием. То же мне проблема — отложить написание строчки на пару секунд.

Ну что за привычка поспорить... Ну согласись, что в последнее время, как минимум мы с Тохой с SQL-ем работаем в разы больше тебя, и нам и переучиваться сложнее и проблемы с текущим положением вещей нам известны отнюдь не теоретически, и тем не менее мы в один голос одобряем этот шаг. Странно правда?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 12:20
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

AVK>На момент его написания в конце есть полная информация о том, что там можно подставить, следовательно intellisense будет работать в полном объеме.


Ну, и что помешает на этот момент подняться на строчку и вписать поля в селекте расположеном выше?

VD>>Все будет тоже самое. Ну, разве что позволяет надеяться, что from к этому мометну уже будет полностью сформирован. Ну, так нет проблем селек и вперед вписывать только после того как весь запрос сформирован.


AVK>Только так никто не делает


А кто эти "никто"? Я тебе уже говорил, что видел работающие варианты. Не сказать, чтобы я был в полном восторге, но все работало.

VD>>Я вообще не понимаю такую заботу о вводе при полной наплевательстве на читаемость текста.


AVK>А по мне так читаемость не хуже.


Ага. Точно. Конечно ниже. Надо в комитет по SQL-ю об этом сказать. Вы им глаза просто таки откроете!

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

AVK> Просто непривычно несколько. Никакого принципиального ухудшения по сравнению с селектом вначале лично я не вижу.


Ага. Просто. Причем в Васике будет привычно. А мы пойдем своим путем. Не слов, блин.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.05 12:20
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Влад, ты себе представляешь объем этого списка?


Да. Он мизерный. В списке методов/классов в мало мальски серьезном проекте на ИЯ он куда больше.

S> Учитывая то, что можно указывать а) имя базы и б) имя связанного сервера? Это же бесконечная простыня.


Да, что уж, там скромничать. Не "бесконечная, "а затмивающая вселенную". Там будет точнее.
А главное, это ведь так хорошо доказывает, что писать нужно "из ..., выбрать ...", а не "выбрать... из...".

S>Видел я такое решение у какой-то приблуды к interbase. Полезность = 0, т.к. не дождешься, пока оно список полей вытащит, и угадывает оно крайне редко.


Угадывать там нечего. Все и так извесно. Про полезность... ну, конечно ручками то куда удобнее.

VD>>Если уже имеется часть "from", то список алиасов и таблиц из него.

S>Дело хорошее. Но это требует написать сначала from, а потом уже select. Догадываешься, к чему я клоню?

Ой. Писать прийдется перемещаясь на строчку вверх?! Я угодал? И как же тупые американцы смогут до этого допереть. Пусть уж лучше мучаются когда читают. А чтобы было меньше сомнений зафигачим по больше пиару. Обоснуем (ну, примерно так же как вы тут)... в общем, промоем мозги. Так проще. Американцы ведь код пишут исключительно слева направо и сверху вниз. Перемещаться — это же терять мысль. Вот только я не американец. И я когда код пишу постояно по строчкам туда-сюда прыгаю. И для меня это не проблема! Я уж лучше по прыгаю чуть-чуть, чем потом читать раком написанный текст.

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

S>Не знаю как ты, а я лично набираю слева направо.


Да? И как же ты бедный с такими способностями SQL-запросы то умудряшся писать. Совсем уж в оправданих этого "решения" до маразма скатился. Прям вижу в твоих глазах тупого американца.

Только не разбивай мне сердце рассказом, что не можешь написать примитивного запроса без QBE.

ЗЫ

В общем, это просто не серьезно. Это попытка оправдать выбор больших дядь любой ценой.
Еще раз, последний, изложу свою позицию серьезно.

Заботиться нужно в первую очередь о читабельности получаемого кода. Никакие угоды интелисоенсам не должны превращать код в бред. Да и нет особых проблем с интелисенсом. Ну, нет проблем вписать селект чуть позже. Нету!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.05 12:32
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>На момент его написания в конце есть полная информация о том, что там можно подставить, следовательно intellisense будет работать в полном объеме.


VD>Ну, и что помешает на этот момент подняться на строчку и вписать поля в селекте расположеном выше?


Это неудобно.

AVK>>А по мне так читаемость не хуже.


VD>Ага. Точно. Конечно ниже.


Что ниже?

VD> Надо в комитет по SQL-ю об этом сказать.


О чем?

VD>Конечно читать: Из таблиц ..., при условии ..., сгрупировав по ..., выбрать ... Куда удобнее и проще чем: Выбрать ..., из таблиц ..., при условии..., сгрупировав по ... Ну, это же как божий день ясно.


Тебе может и ясно. Я мне, например, нет. Аргументы будут?

AVK>> Просто непривычно несколько. Никакого принципиального ухудшения по сравнению с селектом вначале лично я не вижу.


VD>Ага. Просто. Причем в Васике будет привычно. А мы пойдем своим путем. Не слов, блин.


Т.е. аргументов нет. Так и запишем.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[10]: Язык запросов: from в начале
От: IT Россия linq2db.com
Дата: 20.12.05 12:42
Оценка: 12 (1) +2 -1
Здравствуйте, VladD2, Вы писали:

VD>Заботиться нужно в первую очередь о читабельности получаемого кода. Никакие угоды интелисоенсам не должны превращать код в бред. Да и нет особых проблем с интелисенсом. Ну, нет проблем вписать селект чуть позже. Нету!


Насчёт проблем не знаю. Но так или иначе, рано или поздно они решатся. Пять лет назад вообще никакого интеллисенса не было. А вот кривой синтаксис останется навсегда. В общем, вынесение селекта взад ради удобства интеллисенса — это глупость.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Язык запросов: from в начале
От: IT Россия linq2db.com
Дата: 20.12.05 14:56
Оценка:
Здравствуйте, Merle, Вы писали:

M>Правильно. Только возвращаться к select части — не удобно, очень неудобно и гораздо правильнее вынести select в конец, раз есть такая возможность.


А читать это потом удобно будет? Особенно если чукча не писатель
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 20.12.05 15:18
Оценка: +2
Здравствуйте, IT, Вы писали:

IT>А читать это потом удобно будет? Особенно если чукча не писатель

Сдается мне, что читать будет даже удобнее.. Когда я пялюсь в малознакомый запрос, то в первую очередь меня интересует из каких объектов (таблиц) идет выборка, затем условия отбора, а потом уже, какие именно поля выбираются. Я, на самом деле не уверен насчет приоритетов, условия отбора/набор полей, но то что объекты идут на первом месте — это точно.
Специально сегодня сидел и при разборе запросов думал, что же мне от них надо..
И действительно, сначала ищешь глазами секцию From, смотришь откуда, как и зачем, а потом ползешь обратно и смотришь что же именно, если надо. Причем, если есть возможность, то прогоняешь запрос, и список полей смотришь в результате запроса, а не в тексте, так что все равно select получается в конце.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Язык запросов: from в начале
От: GlebZ Россия  
Дата: 20.12.05 17:05
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Извини конечно но это полная фигня. Граматика для SQL валяется на АНТЛР-овском сайте. Плюсь своими глазами видел не один редактор SQL с приличным интелисенсом.


VD>И вообще, язык деларативный. Запросы маленькие. Так что проблем тут никаких. Другое дело, что в этом самом линке далеко не SQL. Хотя тому же Васику это почему-то немешает. В нем select пока что спереди. И я уверен, что интелисенс в нем будет.

Только что делал парсер SQL на COCO/R в LL(1). Мрак. Select проверять постфактум. Но более всего убило примерно такое:
хорошо было бы
"SELECT" [table '.'] column_name ...
а приходится делать
"SELECT" table ['.' column_name] ...
Естественно и table_name и column_name — один и тот же токен. То же самое со схемами. Думаю семантику легче будет сделать вторым проходом, или перейти уйти с COCO/R что делать лениво.
Вообще же SQL делали под лозунгом что и кухарка сможет писать запросы. Кухарка конечно не шмогла, но для человека язык достаточно дружелюбный. А вот для автоматизированной обработки — полная сипука.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 09:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, VladD2, Вы писали:


AVK>>>На момент его написания в конце есть полная информация о том, что там можно подставить, следовательно intellisense будет работать в полном объеме.


VD>>Ну, и что помешает на этот момент подняться на строчку и вписать поля в селекте расположеном выше?


AVK>Это неудобно.


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

AVK>Что ниже?


Хуже читаемость. Ну, полный берд писать "из..., взять...".

VD>> Надо в комитет по SQL-ю об этом сказать.


AVK>О чем?


Не включай дурака. О том что они всю жизнь пользовались "неудобным" синтаксисом (писали "select" в начале запроса).

VD>>Конечно читать: Из таблиц ..., при условии ..., сгрупировав по ..., выбрать ... Куда удобнее и проще чем: Выбрать ..., из таблиц ..., при условии..., сгрупировав по ... Ну, это же как божий день ясно.


AVK>Тебе может и ясно. Я мне, например, нет. Аргументы будут?


Какие аргументы, Андрюша? Я же твое позицию выразил. Ты не заметил, что я над тобой стебаюсь?

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

AVK>>> Просто непривычно несколько. Никакого принципиального ухудшения по сравнению с селектом вначале лично я не вижу.


VD>>Ага. Просто. Причем в Васике будет привычно. А мы пойдем своим путем. Не слов, блин.


AVK>Т.е. аргументов нет. Так и запишем.


У тебя то? И небыло никогда. Единственный аргумент — "удобство реализации комплита" невыдерживает никакой критики.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 09:51
Оценка: 46 (3)
Здравствуйте, IT, Вы писали:

IT>Насчёт проблем не знаю. Но так или иначе, рано или поздно они решатся. Пять лет назад вообще никакого интеллисенса не было. А вот кривой синтаксис останется навсегда. В общем, вынесение селекта взад ради удобства интеллисенса — это глупость.


Полностью согаслен! Нельзя технические проблемы ставить выше идеологических.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.05 09:51
Оценка: :)
Здравствуйте, GlebZ, Вы писали:

GZ>Только что делал парсер SQL на COCO/R в LL(1). Мрак. Select проверять постфактум.


О создании AST не подумал?

GZ> Но более всего убило примерно такое:

GZ>хорошо было бы
GZ>"SELECT" [table '.'] column_name ...
GZ>а приходится делать
GZ>"SELECT" table ['.' column_name] ...

Да, уж серьезнейшая проблема. Иди погляди как пришлось под LL(1) переписать граматику C#. Вот там действительно не просто. И граматика не сравненно сложнее. Но ничего. Все воркает как надо.

GZ>Естественно и table_name и column_name — один и тот же токен. То же самое со схемами. Думаю семантику легче будет сделать вторым проходом, или перейти уйти с COCO/R что делать лениво.


А семантику и не нужно делать первым проходом. Для любого мало мальски реального языка на сегодня требуется создать AST. Семантика обрабатывается уже по AST. И никаких проблем при этом не возникает. В общем, технических проблем тут нет. Мои оппоненты говорят не о технических проблемах. Они говорят, что мол до того как программист задаст список источников данных (from ...) нельзя вывести список полей для select-части запроса. И что мол расположив запрос раком (сначало from, а потом select) можно будет сделать набор текста более удобным. Вот только при этом резко менее удобным становится чтение этого самого запроса. И все потуги к тому чтобы взять, хотя бы частично, синтаксис SQL можно считать бессмысленными.

GZ>Вообще же SQL делали под лозунгом что и кухарка сможет писать запросы. Кухарка конечно не шмогла, но для человека язык достаточно дружелюбный. А вот для автоматизированной обработки — полная сипука.


Вообще-то SQL делали без лозунгов. Это очень успешная разработка DSL позволяющего декларативно описывать данные которые нужно вытащить из реляционной БД. Ничего лучшего для этих целей по сей день я лично не видел. И писать запросы к БД на ИЯ я лично очень не хочу.

И вообще, если нормальное построение фразы запроса — это не круто и для кухарок, то я лучше уж буду в стане кухарок, чем в стане интелектуальных извращенцев.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 21.12.05 10:29
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD> У тебя в foreach тоже сначало нужно задать список элементы которого перелбирашь.

Удивишся, но это тоже неудобно, и это не ерунда.

VD> Учитывая, что вписывать руками этот запрос ты все равно не будешь, а воспользуешся снипетом, то этот самый снипет в лучшем виде тебе проведет оп всем стадиям создания запроса в нужном порядке.

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

VD>Хуже читаемость. Ну, полный берд писать "из..., взять...".

Влад, не все что тебе непривычно — бред. Иногда совсем даже наоборот.
Во-первых даже с точки зрения обычного языка ничего неправильного и нелогичного во фразе "из..., взять..." — нету.
А во-вторых, это не обычный язык, и, как я уже писал, когда я смотрю в запрос, то что именно я беру меня интересует в последнюю очередь, а вот в первую очередь меня интересует откуда я это делаю и по какому условию. Поэтому я все равно галзами ищю секцию From и начинаю разбор запроса с неё.
Так что с точки зрения читаемости это тоже сплошное улучшение.

Еще один момент, раз уж ты аппелируешь к SQL-ю: В новом стандарте, и в сиквеле, есть CTE, и при использовании CTE ты сначала формируешь набор откуда ты будешь выбирать данные, а потом уже какие именно и по какому условию — тоже проблем с читаемостью особых нет.

VD>О том что они всю жизнь пользовались "неудобным" синтаксисом (писали "select" в начале запроса).

Сейчас уже это менять поздно, хотя я бы не отказался.

VD>Так что уж ты будь добр, предоставь аргументы в пользу изменения синтаксиса запроса приводящего к написанию select-а черт знает где.

См. выше.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[14]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.12.05 11:06
Оценка: +1
Здравствуйте, VladD2, Вы писали:

AVK>>Это неудобно.


VD>Ерунду говоришь. У тебя в foreach тоже сначало нужно задать список элементы которого перелбирашь.


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

VD> Учитывая, что вписывать руками этот запрос ты все равно не будешь, а воспользуешся снипетом


Не факт. Лично меня пока эта автоматизация Copy-Paste не очень то привлекает.

AVK>>Что ниже?


VD>Хуже читаемость. Ну, полный берд писать "из..., взять...".


Т.е. аргументов нет. Тогда лучше закончить этот бессмысленный спор.

VD>>> Надо в комитет по SQL-ю об этом сказать.


AVK>>О чем?


VD>Не включай дурака.


Я не включаю. Это ты пишешь так, что тебя невозможно понять.

VD> О том что они всю жизнь пользовались "неудобным" синтаксисом (писали "select" в начале запроса).


Они и так это знают, не переживай.

AVK>>Тебе может и ясно. Я мне, например, нет. Аргументы будут?


VD>Какие аргументы, Андрюша? Я же твое позицию выразил. Ты не заметил, что я над тобой стебаюсь?


Без каких либо аргументов. Т.е. 100% pure сам-знаешь-чего.

VD>Так что уж ты будь добр, предоставь аргументы в пользу изменения синтаксиса запроса приводящего к написанию select-а черт знает где.


Я уже написал. Могу повторить
1) Нормальная работа intellisense при нормальном наборе слева направо.
2) Лучше читаемость, потому что в таком виде мы сперва видим откуда выбираем, а потом какие конкретно данные. При стандартной записи же это как сначала сказать что температура завтра будет +30 градусов, а потом уточнить что в Тайланде.
Минус я пока вижу ровно один — непривычно

VD>>>Ага. Просто. Причем в Васике будет привычно. А мы пойдем своим путем. Не слов, блин.


AVK>>Т.е. аргументов нет. Так и запишем.


VD>У тебя то? И небыло никогда. Единственный аргумент — "удобство реализации комплита" невыдерживает никакой критики.


У тебя и таких аргументов нет, одни эмоции.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[8]: Язык запросов: from в начале
От: GlebZ Россия  
Дата: 21.12.05 18:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, GlebZ, Вы писали:


GZ>>Только что делал парсер SQL на COCO/R в LL(1). Мрак. Select проверять постфактум.


VD>О создании AST не подумал?

Я ленив... А вообще AST дерево тут фактически не помогает. Семантика SQL вообще не кладется в дерево. Это некоторая граф в котором есть корневые объекты(а самое главное алиасы) из from от которых идут дуги на поля и взаимосвязи между ними. Вобщем жутко неприятно и AST на основе синтаксиса не сильно нужен.

VD>Да, уж серьезнейшая проблема. Иди погляди как пришлось под LL(1) переписать граматику C#. Вот там действительно не просто. И граматика не сравненно сложнее. Но ничего. Все воркает как надо.

Просто по человечески обидно. Вроде достаточно просто выглядит, а копнешь ...

GZ>>Естественно и table_name и column_name — один и тот же токен. То же самое со схемами. Думаю семантику легче будет сделать вторым проходом, или перейти уйти с COCO/R что делать лениво.

VD>А семантику и не нужно делать первым проходом. Для любого мало мальски реального языка на сегодня требуется создать AST. Семантика обрабатывается уже по AST. И никаких проблем при этом не возникает. В общем, технических проблем тут нет. Мои оппоненты говорят не о технических проблемах. Они говорят, что мол до того как программист задаст список источников данных (from ...) нельзя вывести список полей для select-части запроса. И что мол расположив запрос раком (сначало from, а потом select) можно будет сделать набор текста более удобным. Вот только при этом резко менее удобным становится чтение этого самого запроса. И все потуги к тому чтобы взять, хотя бы частично, синтаксис SQL можно считать бессмысленными.
Вообще-то они правы. Не стал бы утверждать про читабельность, такое построение очень похоже на написание мат. формул. Например моноид list{a.b|a<-A, a.c<10}. Может из-за этого так и сделали. Но мне тоже нравится from перед select. Сначало нужно смотреть alias'ы для столбцов, а затем уже сами столбца. A с набором также, сначало набиваешь звезду, затем from и в самом конце переписываешь фром в нужную сторону. Алгоритм не очень хороший.

VD>Вообще-то SQL делали без лозунгов. Это очень успешная разработка DSL позволяющего декларативно описывать данные которые нужно вытащить из реляционной БД. Ничего лучшего для этих целей по сей день я лично не видел. И писать запросы к БД на ИЯ я лично очень не хочу.

Честно говоря с лозунгами. Проводились исследования как лучше и читабельней сделать SQL. Была проведена достаточно большая работа. Даже была выпущена достаточно известная в некоторых проф. кругах работа по данному исследованию(кажется это была тематика психологов).

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Язык запросов: from в начале
От: Denis_TST Россия www.transsys.ru
Дата: 21.12.05 18:42
Оценка: +1 :)
Здравствуйте, Real 3L0, Вы писали:

R3>Это ясно. Но ведь согласитесь, не обязательно настолько круто предугадывать. Варианты:

R3>1. select * from |[выпал список таблиц]
R3>2. select t.|[выпал список полей] from table t
R3>Лично мне достаточно было бы и этого.
PLSQL Developer (для Oracle) это умеет. Еще умеет так
select t.F1 from table t, table2 t2
where t.|[выпал список полей]
... << RSDN@Home 1.2.0 alpha rev. 622>>
Re[7]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 00:26
Оценка: 12 (1) +1
Здравствуйте, Sinclair, Вы писали:

S>Вот тут я повставлял символы | в тех местах, где мне интересно поителлисенсить. Представь себе, что в каждом из них набрано только то, что слева. Что ты собираешься мне показать в списке кандидатов? Как в нем окажется то, что я на самом деле написал? :

S>
S>select |t.|id, |maxvalue, |name from (select |id, |max(value) as maxvalue from |myTable group by |id) t 
S>  inner join |myOtherTable k on |k.id = |t.id
S>


Ты уж покажи тогда как замечательно всё подставиться если SELECT в конце. А то у тебя странно как-то выходит, вместо того чтобы похвалить новое, ты почему-то ругаешь старое Чем новое-то лучше?
Кроме того, давайте не скатываться в каменный век. Паскаль писали для того чтобы компилятор был однопроходным, но это было давно. Сейчас компьютеры подстаиваются под людей, а не наоборот. Не забывай, что SQL это когда-то SEQUEL — Structured English Query Language. Запросы вполне можно читать как синтаксически верные предложения. Мы говорим "дай карандаш из ящика", а не "ящика из карандаш дай". Если кому-то сложно реализовавать IntelliSence, то пусть съест сникерс и зарядит мозги, а синтаксис оставит человеческим. Надеюсь дочитав до этого места ты не забыл, что должен показать как замечательно выплывают подсказки для примера выше, если SELECT в конце
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 00:38
Оценка: +1 -1
Здравствуйте, AndrewVK, Вы писали:

AVK>1) Нормальная работа intellisense при нормальном наборе слева направо.


Это не аргумент. Красивые менюшки тоже сложнее реализовывать, чем некрасивые.
Более того, если ты не заметил, современный IntelliSence использует MRU системы, так что набор двух похожих запросов это не тоже самое, что набор одного. И ещё, IntelliSence это ИМХО средство подбора окончания слова, а не нацисания его целиком за тебя.

AVK>2) Лучше читаемость, потому что в таком виде мы сперва видим откуда выбираем, а потом какие конкретно данные. При стандартной записи же это как сначала сказать что температура завтра будет +30 градусов, а потом уточнить что в Тайланде.


Я вообще не думаю, что к большому SQL-like запросу применимо слово читаемость.

AVK>Минус я пока вижу ровно один — непривычно


Не просто непривычно. не соответствует синтаксису человеческого языка.

foreach это "для каждого яблока в ящике". Это можно не просто разибирать как синтаксическую конструкцию, но читать вслух слева на право!
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 00:41
Оценка: +1 -1
Здравствуйте, ie, Вы писали:

ie>Работать слева направо — тут, безусловно, никаких возможностей не представляется. Ну не гадалка intellisence, чтоб угадывать откуда я from буду делать и по каким полям буду группировать...


Не гадалка, но запомнить несколько предыдущих запросов вполне возможно. Как результат при написании нескольких похожих запросов IntelliSence вполне может поработать и гадалкой и совсем не без успеха.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 00:43
Оценка: +3
Здравствуйте, Merle, Вы писали:

M>И действительно, сначала ищешь глазами секцию From, смотришь откуда, как и зачем, а потом ползешь обратно и смотришь что же именно, если надо. Причем, если есть возможность, то прогоняешь запрос, и список полей смотришь в результате запроса, а не в тексте, так что все равно select получается в конце.


Я конечно не гуру БД, но даже я первое к чему себя приучил это писать SELECT, WHERE, FROM, GROUP BY, ORDER BY с новой строки, а если запрос большой то и с пропуском строки. И как-то никогда не было проблем с поиском, хотя на зрение жалуюсь
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[7]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 00:46
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Кухарка конечно не шмогла, но для человека язык достаточно дружелюбный.


На самом деле это пожалуй его единственное достоинство. Сам факт наличия сложнейших оптимизаторов с SQL серверах говорит о том, что между SQL запросом и тем как он выполняется пропасть. Теперь у нас хотят отнять и это преимущество ничего не давая взамен
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Язык запросов: from в начале
От: Real 3L0 Россия http://prikhodko.blogspot.com
Дата: 22.12.05 05:19
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ> Проводились исследования как лучше и читабельней сделать SQL. Была проведена достаточно большая работа. Даже была выпущена достаточно известная в некоторых проф. кругах работа по данному исследованию(кажется это была тематика психологов).


Интересно, а они учитывали, что понятие "взять карандаш из ящика" в реальной жизни человеческому мозгу гораздо проще расшифровать, т.к. понятия "карандаш" и "ящик" в мозг вбиты в виде аксиом? Ведь совсем другое дело, когда "карандаш" и "ящик" лежит в БД — приходится постоянно трансформировать понятия из человеческого мира в мир БД.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Вселенная бесконечна как вширь, так и вглубь.
Re[16]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 22.12.05 08:14
Оценка: +2 -1
Здравствуйте, adontz, Вы писали:

A>Это не аргумент. Красивые менюшки тоже сложнее реализовывать, чем некрасивые.

Дело не в сложности реализации, а в удобстве использования того что реализовано.

A> И ещё, IntelliSence это ИМХО средство подбора окончания слова...

Правильно. Подбора окончания, а не начала по готовому окончанию.

A>не соответствует синтаксису человеческого языка.

Во-первых, причем здесь человеческий язык? А во-вторых — вполне соответствует.

A>foreach это "для каждого яблока в ящике". Это можно не просто разибирать как синтаксическую конструкцию, но читать вслух слева на право!

Точно так же слева на право можно читать "Дайте мне из этого ящика все яблоки".
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[12]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 22.12.05 08:14
Оценка: +2 -1
Здравствуйте, adontz, Вы писали:

A>Я конечно не гуру БД, но даже я первое к чему себя приучил это писать SELECT, WHERE, FROM, GROUP BY, ORDER BY с новой строки, а если запрос большой то и с пропуском строки.

Молодец. Только читать при этом приходится сначала FROM, потом ниже, а потом возвращаться глазами на верх или даже прокручивать, что совсем не удобно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 22.12.05 08:14
Оценка: +1
Здравствуйте, adontz, Вы писали:

A> Запросы вполне можно читать как синтаксически верные предложения. Мы говорим "дай карандаш из ящика", а не "ящика из карандаш дай".

Ну не надо тут на психику давить, фраза "Дай из ящика карандаш" звучит не чуть не хуже.

A> Если кому-то сложно реализовавать IntelliSence, то пусть съест сникерс и зарядит мозги, а синтаксис оставит человеческим.

Еще раз. Сложность не в реализации а в пользовании тем, что реализовано. Интеллисенсом, который работает справа на лево пользоваться невозможно.

A>Надеюсь дочитав до этого места ты не забыл, что должен показать как замечательно выплывают подсказки для примера выше, если SELECT в конце

Замечательно всплывают, во всех местах, без каких либо проблем и возвратов налево.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[16]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 08:48
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Это не аргумент.


Кому как.

AVK>>2) Лучше читаемость, потому что в таком виде мы сперва видим откуда выбираем, а потом какие конкретно данные. При стандартной записи же это как сначала сказать что температура завтра будет +30 градусов, а потом уточнить что в Тайланде.


A>Я вообще не думаю, что к большому SQL-like запросу применимо слово читаемость.


Зря. Тем более что linq это далеко не SQL.

A>foreach это "для каждого яблока в ящике".


А можно сказать по другому — "из ящика выбрать каждое яблоко и сделать с ним то-то и то-то". Тоже вполне по-русски. А есть еще и другие языки.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[8]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 08:48
Оценка:
Здравствуйте, adontz, Вы писали:

A>На самом деле это пожалуй его единственное достоинство. Сам факт наличия сложнейших оптимизаторов с SQL серверах говорит о том, что между SQL запросом и тем как он выполняется пропасть.


SQL тут не при чем. Оптимизатор (по крайней мере в MSSQL) не работает с текстом запроса. Он даже не работает с его AST. Оптимизатор работает с набором абстракций, описывающих некие атомарные операции собственно движка БД.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[17]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 11:59
Оценка: -1
Здравствуйте, Merle, Вы писали:

A>>foreach это "для каждого яблока в ящике". Это можно не просто разибирать как синтаксическую конструкцию, но читать вслух слева на право!

M>Точно так же слева на право можно читать "Дайте мне из этого ящика все яблоки".

я тебя люблю
я люблю тебя
тебя я люблю
тебя люблю я
люблю я тебя
люблю тебя я

Все эти предложения в руском языке не только синтаксически верны, но даже имеют различный смысл.

Так что как только ты грамостно скажешь "Дайте мне из этого ящика все яблоки" по-английски с сохранением порядка слов, я безоговорочно капитулирую, а пока мой перевод "Give me from this box all apples" не укладывается нормы синтаксиса и вызывает отторжение, я ещё немножечко поспорю
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 12:01
Оценка:
Здравствуйте, adontz, Вы писали:

A>Не гадалка, но запомнить несколько предыдущих запросов вполне возможно. Как результат при написании нескольких похожих запросов IntelliSence вполне может поработать и гадалкой и совсем не без успеха.


Иван, а за что минус? VisualAssist в C++ не так уж редко правильно угадывает. Думаешь SQL сложнее Си++? Ну-ну. Каждый кулик...
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[17]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 12:06
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

A>>foreach это "для каждого яблока в ящике".

AVK>А можно сказать по другому — "из ящика выбрать каждое яблоко и сделать с ним то-то и то-то". Тоже вполне по-русски. А есть еще и другие языки.

А причём тут русский язык?

foreach (Apple apple in box) -> for each apple in the box
from box select apple -> ?
ну ка замени ? на что-либо по английски. Это тебе не русский где слова тасуются как карты в колоде и всё равно что-то получается.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 12:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>SQL тут не при чем. Оптимизатор (по крайней мере в MSSQL) не работает с текстом запроса. Он даже не работает с его AST. Оптимизатор работает с набором абстракций, описывающих некие атомарные операции собственно движка БД.


Я может не совсем точно выразился, ту скорее даже парсер наверное, а не оптимизатор.
Вобщем я о том, что один и тот же SQL запрос может быть выполнен очень по-разному не из-за наличия или отсутствия оптимизации,а просто потому что может быть по-разному разобран, а несколько разных запросов могут приводить к один и тем же результатам.
В языках типа C#/C++ такого нет, SQL совсем другой, скорее даже декларативный.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 14:40
Оценка:
Здравствуйте, adontz, Вы писали:

A>Иван, а за что минус? VisualAssist в C++ не так уж редко правильно угадывает. Думаешь SQL сложнее Си++? Ну-ну. Каждый кулик...


Ты решарпер пробовал ставить? Если пробовал, то должен понять чем отличается нормальный интеллисенс от VA.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[10]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 14:40
Оценка:
Здравствуйте, adontz, Вы писали:

A>Я может не совсем точно выразился, ту скорее даже парсер наверное, а не оптимизатор.


А про "факт наличия сложнейших" парсеров лично я ничего не слышал.

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


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

A>В языках типа C#/C++ такого нет, SQL совсем другой, скорее даже декларативный.


Не скорее, а декларативный и есть.
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[11]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 15:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ты решарпер пробовал ставить?


Естественно.

AVK>Если пробовал, то должен понять чем отличается нормальный интеллисенс от VA.


Мы говорим об автоподстановке всё ещё или о примочках типа — переимену мне этот метод во всех файлах? Давай тогда уже конкретно — пример кода на котором VA лажается, а решарпер крут. А то вот я поставил и до сих пор ничего офигительно крутого не заметил.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.12.05 15:35
Оценка:
Здравствуйте, adontz, Вы писали:

AVK>>Если пробовал, то должен понять чем отличается нормальный интеллисенс от VA.


A>Мы говорим об автоподстановке всё ещё или о примочках типа — переимену мне этот метод во всех файлах? Давай тогда уже конкретно — пример кода на котором VA лажается, а решарпер крут. А то вот я поставил и до сих пор ничего офигительно крутого не заметил.


Плохо смотрел. Smart autocomplete использовал?
... << RSDN@Home 1.2.0 alpha rev. 624>>
AVK Blog
Re[10]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 22.12.05 15:39
Оценка: -2
Здравствуйте, adontz, Вы писали:

A>Иван, а за что минус?

За то что запоминать предыдущие запросы занятие в плане интеллисенса совершенно бесполезное.

A> Думаешь SQL сложнее Си++? Ну-ну. Каждый кулик...

Думаю что он другой.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 22.12.05 17:57
Оценка: +1
Здравствуйте, Merle, Вы писали:

M>За то что запоминать предыдущие запросы занятие в плане интеллисенса совершенно бесполезное.


Это ты очень-очень не прав
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.12.05 22:27
Оценка:
Здравствуйте, Merle, Вы писали:

M>Здравствуйте, VladD2, Вы писали:


VD>> У тебя в foreach тоже сначало нужно задать список элементы которого перелбирашь.

M>Удивишся, но это тоже неудобно, и это не ерунда.

Это ерунда. Пользуйся РеШарпером или VS2005. В них никаких проблем с этим нет.
Ты лучше скажи, ты что предлагашь и foreach записывать задом на перед, чтобы набирать было удобнее? Хотя хотя бы последовательный подход. Если уж мы пишем "from источки select поля", то логично присать "foreach in источкник поля". Раком конечно, но последовательно.

VD>> Учитывая, что вписывать руками этот запрос ты все равно не будешь, а воспользуешся снипетом, то этот самый снипет в лучшем виде тебе проведет оп всем стадиям создания запроса в нужном порядке.

M>Именно для того чтобы не менялся порядок ввода, что, например меня очень сильно сбивает, лично я снипетом не пользуюсь и приходится набирать все руками.

И зря. Ну, да это твои проблемы.

VD>>Хуже читаемость. Ну, полный берд писать "из..., взять...".

M>Влад, не все что тебе непривычно — бред. Иногда совсем даже наоборот.

Ну, на этом основании можно начать возвышать пидарасов и т.п. Аргумент еще тот.

M>Во-первых даже с точки зрения обычного языка ничего неправильного и нелогичного во фразе "из..., взять..." — нету.


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

M>А во-вторых, это не обычный язык, и, как я уже писал, когда я смотрю в запрос, то что именно я беру меня интересует в последнюю очередь, а вот в первую очередь меня интересует откуда я это делаю и по какому условию. Поэтому я все равно галзами ищю секцию From и начинаю разбор запроса с неё.

M>Так что с точки зрения читаемости это тоже сплошное улучшение.

Понимаешь ли в чем дело? Ты не смотришь на запрос как на строку символов. Ты воспринимашь его или в целом, как предложение, или как отдельные его части. И это восприятие тем проще чем привычнее тебе структура этогого запроса.

Во ты думашь почему функциональные языки так плохо воспринимаются народом? Да потому, что они очень сильно отличаются от привычной людям записи. SQL тоже своего рода функциональный язык, но он в отличии от универсальных ФЯ проектировался не в угоду простоты парсигна, а в угоду привычек человека. Именно по этому SQL так хорошо возспринимается даже не очень подготовленными людми.

M>Еще один момент, раз уж ты аппелируешь к SQL-ю: В новом стандарте,


Что за новый стандарт?

M> и в сиквеле, есть CTE, и при использовании CTE ты сначала формируешь набор откуда ты будешь выбирать данные, а потом уже какие именно и по какому условию — тоже проблем с читаемостью особых нет.


CTE тут не причем. Это трехэтажные навороты к делу не относящиеся.

VD>>О том что они всю жизнь пользовались "неудобным" синтаксисом (писали "select" в начале запроса).

M>Сейчас уже это менять поздно, хотя я бы не отказался.

Ну, слава богу, что поздно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.12.05 22:27
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

AVK>Т.е. аргументов нет. Тогда лучше закончить этот бессмысленный спор.


То что чужие агрументы для тебя таковыми не являются, это еще не значит, что это не аргументы.
Я вот другое заметил, когда у тебя этих самых аргументов нет, или они слабые, ты сразу начинашь повторять эту фрау.

AVK>Я не включаю. Это ты пишешь так, что тебя невозможно понять.


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

VD>> О том что они всю жизнь пользовались "неудобным" синтаксисом (писали "select" в начале запроса).


AVK>Они и так это знают, не переживай.




AVK>>>Тебе может и ясно. Я мне, например, нет. Аргументы будут?


VD>>Какие аргументы, Андрюша? Я же твое позицию выразил. Ты не заметил, что я над тобой стебаюсь?


AVK>Без каких либо аргументов. Т.е. 100% pure сам-знаешь-чего.


Нда.

AVK>Я уже написал. Могу повторить

AVK>1) Нормальная работа intellisense при нормальном наборе слева направо.

Это хреновый аргумент. К тому же ни о какой нормальности речи не идет. Я тебе уже это объяснял.

AVK>2) Лучше читаемость, потому что в таком виде мы сперва видим откуда выбираем, а потом какие конкретно данные. При стандартной записи же это как сначала сказать что температура завтра будет +30 градусов, а потом уточнить что в Тайланде.


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

AVK>Минус я пока вижу ровно один — непривычно


Я бы назвал вещи своими именами — неграмотно!

AVK>У тебя и таких аргументов нет, одни эмоции.


Это я уже слышал. Ну, что же говорить дествительно не о чем. Когда главный аргумент — непризнание чужих, то консенсуса не будет. Завязываем.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 22.12.05 22:53
Оценка: +4 -1
Здравствуйте, VladD2, Вы писали:

VD>Это ерунда.

Нет

VD> Пользуйся РеШарпером или VS2005. В них никаких проблем с этим нет.

Есть и очень серьезные. Ни в студии, ни в решарпере комплитом для foreach-а пользоваться невозможно.

VD>Ты лучше скажи, ты что предлагашь и foreach записывать задом на перед, чтобы набирать было удобнее?

Да. Так было бы лучше.

VD> Раком конечно, но последовательно.

Раком — то как это выглядит сейчас.

M>>Влад, не все что тебе непривычно — бред. Иногда совсем даже наоборот.

VD>Ну, на этом основании можно начать возвышать пидарасов и т.п. Аргумент еще тот.
Это была всего лишь 238-я попытка обратить твое внимание на то, что навешивать эпитет "бред" лишь потому, что что-то тебе непривычно, несколько некорректно.

VD>Обратись к филолагам. Возможно они тебе объяснят, что в языках есть правила построения предложения.

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

VD> И это восприятие тем проще чем привычнее тебе структура этогого запроса.

Привычность структуры от перемены мест не поменяется, а вот читаемость — улучшится.
Не надо будет бегать вверх-вниз по тексту.

VD>Что за новый стандарт?

Относительно новый, CTE, кажется, есть уже в 99.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[11]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Ты решарпер пробовал ставить? Если пробовал, то должен понять чем отличается нормальный интеллисенс от VA.


Ради спроведливости нужно заметить, что как раз угадывание Ассиста очень и очень эффективно. Оно работает там где нет никакого контекста и угадывает с одной-двух букв. Это не замена комплиту, но отличное расширение. Иногда с ним набор кода превращается в нажатие одной буквы и нажатие на энтер.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, Merle, Вы писали:

M>Ну не надо тут на психику давить, фраза "Дай из ящика карандаш" звучит не чуть не хуже.


Ага. Вот только "дай" соотвествует английскому "select". А в твоей интерпретации это будет звучать "Из ящика дай карандаш". В общем, Ёдовщина какая-то. Уродование языка.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 00:25
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Я ленив...


Это иногда хорошо. Но это не тот случай.

GZ> А вообще AST дерево тут фактически не помогает.


А, ну-ну.

GZ> Семантика SQL вообще не кладется в дерево.


И ты сможешь чем-то подтвердить это свое утверждение?

GZ> Это некоторая граф в котором есть корневые объекты(а самое главное алиасы) из from от которых идут дуги на поля и взаимосвязи между ними. Вобщем жутко неприятно и AST на основе синтаксиса не сильно нужен.


Ты несешь ахинею. AST — это ациклический направляенный граф. И он прекрасно подходит для семантического анализа любого современного языка программирования. Не даром такие построители парсеров как АНТЛР предоставляют декларативный синтаксис для простроения АСТ.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 24.12.05 00:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. Вот только "дай" соотвествует английскому "select". А в твоей интерпретации это будет звучать "Из ящика дай карандаш". В общем, Ёдовщина какая-то. Уродование языка.

Какого языка? Разговорного — возможно (хотя это еще вопрос, сдается мне Хайлсберг английский знает лучше тебя ), а вот SQL-я вовсе нет.
Я уже говорил — смысл в фразу вкладывается другой и смысловые акценты надо ставить в других местах, вот и язык получается совсем не разговорный.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[11]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.05 01:06
Оценка: +1 -1 :)
Здравствуйте, Merle, Вы писали:

M>Какого языка? Разговорного — возможно (хотя это еще вопрос, сдается мне Хайлсберг английский знает лучше тебя ), а вот SQL-я вовсе нет.


Выражения SQL полностью соотвествуют правилам английского языка. Адонз тут верно заметил, что первое название SQL-я было "Структурированный Английский Язык Запросов".

M>Я уже говорил — смысл в фразу вкладывается другой и смысловые акценты надо ставить в других местах, вот и язык получается совсем не разговорный.


Ненадо выдумывать оправдания явной лаже.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Язык запросов: from в начале
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 17:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Ты несешь ахинею.


Просьба уважительнее относиться к собеседникам.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[8]: Язык запросов: from в начале
От: vdimas Россия  
Дата: 25.12.05 20:06
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>На самом деле это пожалуй его единственное достоинство. Сам факт наличия сложнейших оптимизаторов с SQL серверах говорит о том, что между SQL запросом и тем как он выполняется пропасть.


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

Т.е. даже без оптимизации, выполнение SQL-запросов, это, в первую очередь, перевод из декларативного в императивное.
Re[10]: Язык запросов: from в начале
От: vdimas Россия  
Дата: 25.12.05 20:10
Оценка:
Здравствуйте, adontz, Вы писали:

AVK>>SQL тут не при чем. Оптимизатор (по крайней мере в MSSQL) не работает с текстом запроса. Он даже не работает с его AST. Оптимизатор работает с набором абстракций, описывающих некие атомарные операции собственно движка БД.


A>Я может не совсем точно выразился, ту скорее даже парсер наверное, а не оптимизатор.

A>Вобщем я о том, что один и тот же SQL запрос может быть выполнен очень по-разному не из-за наличия или отсутствия оптимизации,а просто потому что может быть по-разному разобран

Как именно выполняется запрос зависит от структуры данных и более ни от чего. Дальнейшая оптимизация применяет статистику и выборку по индексам, где возможно, и зачастую меняя ПОРЯДОК сканирования таблиц с целью минимизации кол-ва данных на каждом следующем шаге выполнения плана запроса. Причем, что характерно, кол-во данных — это не только кол-во строк.
Re[10]: Язык запросов: from в начале
От: GlebZ Россия  
Дата: 26.12.05 11:57
Оценка:
Здравствуйте, VladD2, Вы писали:

GZ>> Семантика SQL вообще не кладется в дерево.

VD>И ты сможешь чем-то подтвердить это свое утверждение?
Да легко.
select a.* from a where a.id in (select b.id from b where b.id=a.ref_id)
select a.* from a, b, c where a.id=b.id and a.id=c.id and c.id=b.id


GZ>> Это некоторая граф в котором есть корневые объекты(а самое главное алиасы) из from от которых идут дуги на поля и взаимосвязи между ними. Вобщем жутко неприятно и AST на основе синтаксиса не сильно нужен.

VD>AST — это ациклический направляенный граф.
Ага. С выделенной вершиной забыл. А так верно. Только граф здесь подразумевает циклы.

VD>И он прекрасно подходит для семантического анализа любого современного языка программирования.

Вторым проходом по AST? Можно. Но первым никак.
Ну например
select a.*, b.*, c.* from A a, B b

Как определить ошибку в ходе LL разбора?

VD>Не даром такие построители парсеров как АНТЛР предоставляют декларативный синтаксис для простроения АСТ.

Для построение AST — легко. А вот для построения аттрибутивной семантики для интерпретации, нет.
Берем простой случай
select a.f, b.f from a, b where a.id=b.id

Это можно интерпретировать
1. Взять отношения a и b
2. Выполнить реляционную операцию соединения по предикату a.id=b.id и присвоить новому отношению res
3. Выполнить реляционную операцию проэкции — res->a.f, b.f
Следовательно, по правильному должна быть выполнена следующая последовательность.
from a, b where a.id=b.id select a.f, b.f

Д. Кнут при формализации семантических деревьев вывода определял два типа аттрибутов — синтезированные и унаследованные. Пока строка select находится вначале запроса, они не являются ни тем ни другим. Транзитивные замыкания в данном случае вообще не обойдешь. Там своя специфика.

Для оптимизации, AST дерево вообще непригодно. Операция проeкции(то что лежит в select) такая же реляционная операция как и другие. Задача самой оптимизации в основном можно определить как нахождение оптимального пути в цикличном графе. Что есть NP задача.

Должен сказать что были попытки оптимизации на уровне SQL. Знаменитые работы Кима(логические оптимизации) были как раз основаны на оптимизации SQL строк. Но из-за бардака в самой семантики SQL подобные экзерцисы на групповых операциях оказались не совсем верные и даже ошибочные. В дальнейшем, была введена дополнительная расширенная реляционная алгебра и все встало на свои места.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Язык запросов: from в начале
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.12.05 15:31
Оценка:
Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, GlebZ, Вы писали:


GZ>> Проводились исследования как лучше и читабельней сделать SQL. Была проведена достаточно большая работа. Даже была выпущена достаточно известная в некоторых проф. кругах работа по данному исследованию(кажется это была тематика психологов).


R3>Интересно, а они учитывали, что понятие "взять карандаш из ящика" в реальной жизни человеческому мозгу гораздо проще расшифровать, т.к. понятия "карандаш" и "ящик" в мозг вбиты в виде аксиом? Ведь совсем другое дело, когда "карандаш" и "ящик" лежит в БД — приходится постоянно трансформировать понятия из человеческого мира в мир БД.

Мозг вообще работает очень забавно. Нет никакого последовательного разбора и прочей ерунды. Выделяются сразу блоки, причем различного размера, и проводится очень быстрый поиск максимального правдоподобия. Только если цельный образ воспринять не удалось, происходит постепенный анализ фрагментов.
Это касается вообще всего. Для текста, конечно, есть некоторое принудительное упорядочивание разбора, но оно весьма далеко от полного.
Поэтому человек способен читать и справа налево, и слева направо. Фразу "возьми из ящика карандаш" человек воспринимает целиком, поэтому порядок слов не очень важен. При восприятии большого объема незнакомой информации линейная упорядоченность начинает играть большее значение для упрощения разбора.
Хотя еще большую роль играет возможность нормально структурировать код.
Это как раз то, чего катастрофически не хватает обычному SQL. Когда у нас возникает жуткий метод на шарпе, мы делим его на части так, чтобы в методе осталось читаемое описание алгоритма. В SQL мы должны писать все подряд. Немного помогают параметризованные view, которых, к слову, в ANSI (насколько я его знаю) нет.
LINQ как раз позволяет описывать предикат постепенно. Можно повторно использовать фрагменты. Это должно повысить читаемость запросов. Влад конечно молодец насчет того, что читается код гораздо чаще, чем пишется.
Но я периодически встречаю в своей практике отчеты с SQL кодом на пару сотен строк, которые прочитать без поллитры невозможно. Я в таких случаях пользуюсь еще и просмотром плана, чтобы понять что где происходит, и порядок from и select там совершенно неважен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.05 23:52
Оценка: -2
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, VladD2, Вы писали:


GZ>>> Семантика SQL вообще не кладется в дерево.

VD>>И ты сможешь чем-то подтвердить это свое утверждение?
GZ>Да легко.
GZ>
GZ>select a.* from a where a.id in (select b.id from b where b.id=a.ref_id)
GZ>select a.* from a, b, c where a.id=b.id and a.id=c.id and c.id=b.id
GZ>


А. Ну, то серьезный аргумент. На него можно ответить только тем же. Вот моая аргументация:

!@#$%^&*()P_{@#$%^&*()_@#$%^&*()_




А если серьзено, то погляди вот это AST SQL Grammar

GZ>Ага. С выделенной вершиной забыл. А так верно. Только граф здесь подразумевает циклы.


Вершина, точнее корень, в графе вещь условная. Просто всегда удобно смореть на AST как на дерево с одним корнем. Это проще для мозга.

VD>>И он прекрасно подходит для семантического анализа любого современного языка программирования.

GZ>Вторым проходом по AST? Можно. Но первым никак.

Количество проходов по AST мало кого трогает. Это же очень быстро. Ты можешь за 100 милисекунд обойти тысячу раз AST SQL-запроса. Этого никто не заметит.

GZ>Ну например

GZ>
GZ>select a.*, b.*, c.* from A a, B b
GZ>

GZ>Как определить ошибку в ходе LL разбора?

Ошибок здесь нет. Это синтаксически верная конструкция. Ну, а онаружить семантические ошибки легко. Разбирашь запрос в AST и строишь таблицу символов. Классика, однко!

VD>>Не даром такие построители парсеров как АНТЛР предоставляют декларативный синтаксис для простроения АСТ.

GZ>Для построение AST — легко. А вот для построения аттрибутивной семантики для интерпретации, нет.
GZ>Берем простой случай
GZ>
GZ>select a.f, b.f from a, b where a.id=b.id
GZ>


Ой, опять ты громкими словами пользушся. В общем, ты меня извини, но твои сомнения надуманы. Ести тебе интересно, то можешь скачать какой-нить парсер SQL-я и побаловаться.

GZ>Д. Кнут при формализации семантических деревьев вывода определял два типа аттрибутов — синтезированные и унаследованные.


Кнут? Ты ничего не путашь?

GZ> Пока строка select находится вначале запроса, они не являются ни тем ни другим. Транзитивные замыкания в данном случае вообще не обойдешь. Там своя специфика.


И как SQL-серверы справляются? Видимо они телепаты.

GZ>Для оптимизации, AST дерево вообще непригодно.


Уууу...

GZ> Операция проeкции(то что лежит в select) такая же реляционная операция как и другие. Задача самой оптимизации в основном можно определить как нахождение оптимального пути в цикличном графе. Что есть NP задача.


GZ>Должен сказать что были попытки оптимизации на уровне SQL. Знаменитые работы Кима(логические оптимизации) были как раз основаны на оптимизации SQL строк. Но из-за бардака в самой семантики SQL подобные экзерцисы на групповых операциях оказались не совсем верные и даже ошибочные. В дальнейшем, была введена дополнительная расширенная реляционная алгебра и все встало на свои места.


Я не знаю причем тут какие-то оптимизации. Речь шала кажется о комплите для SQL-я. Задача не только что решаемая, но и решенная не раз. Мне понадобилось две минуты чтобы надыбать в Интеренете довольно приличный варинта подобного решения. Можешь ознакомиться http://www.promptsql.com .

Еогда будешь глядеть обрати особое внимание на то как эта штука работает с джоинами. Это просто песня. Если бы это чудо было бы бесплатнм и если бы умело еще комплитиль и ключевые слова (как редактор C# в VS 2005), то цены бы ему небыло. А так есть — $25.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.05 23:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Мозг вообще работает очень забавно. Нет никакого последовательного разбора и прочей ерунды.


Вот именно! И не нужно рассказыват про последовательное чтение символов. А то я расскажу про проглатывание базацев.

S>Поэтому человек способен читать и справа налево, и слева направо. Фразу "возьми из ящика карандаш" человек воспринимает целиком, поэтому порядок слов не очень важен.


Жаль это наблюдение не совсем точно. Ведь фраза "из ящика возьми карандаш" читается совсем погано.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 27.12.05 01:04
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

VD>Вот именно! И не нужно рассказыват про последовательное чтение символов. А то я расскажу про проглатывание базацев.


Ты полхо валедешь пердметом. Преуувю и псолдеюню бквуы ндао отсалвтяь на сових метсах, а тсаовать те, что вунтри.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Язык запросов: from в начале
От: WolfHound  
Дата: 27.12.05 06:50
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Жаль это наблюдение не совсем точно. Ведь фраза "из ящика возьми карандаш" читается совсем погано.

А мне пофигу... наверное я Йода...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Язык запросов: from в начале
От: GlebZ Россия  
Дата: 27.12.05 10:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А. Ну, то серьезный аргумент. На него можно ответить только тем же. Вот моая аргументация:

VD>

!@#$%^&*()P_{@#$%^&*()_@#$%^&*()_

VD>
Конструктивно.

VD>А если серьзено, то погляди вот это AST SQL Grammar

Мы говорим о семантике или о синтаксисе?

GZ>>Ага. С выделенной вершиной забыл. А так верно. Только граф здесь подразумевает циклы.

VD>Вершина, точнее корень, в графе вещь условная. Просто всегда удобно смореть на AST как на дерево с одним корнем. Это проще для мозга.
Нет. Не условная. Определение грамматики Наума Хомского:
Порождающей грамматикой Хомского G называется четверка объектов: G=(T,N,S,R), где:
T — терминальный словарь
N — нетерминальный словарь
S — начальный символ
R — конечное непустое множество правил(продукций)
Так что начальный символ — он всегда есть. Собственно он и есть начало грамматики.

VD>>>И он прекрасно подходит для семантического анализа любого современного языка программирования.

GZ>>Вторым проходом по AST? Можно. Но первым никак.
VD>Количество проходов по AST мало кого трогает. Это же очень быстро. Ты можешь за 100 милисекунд обойти тысячу раз AST SQL-запроса. Этого никто не заметит.
Чего-то много написал. Особенно если время ответа БД может достигать 10ms.

GZ>>Ну например

GZ>>
GZ>>select a.*, b.*, c.* from A a, B b
GZ>>

GZ>>Как определить ошибку в ходе LL разбора?
VD>Ошибок здесь нет. Это синтаксически верная конструкция. Ну, а онаружить семантические ошибки легко. Разбирашь запрос в AST и строишь таблицу символов. Классика, однко!
Ага, вторым проходом. Потому как первым проходом такое не сделаешь.
VD>Ой, опять ты громкими словами пользушся. В общем, ты меня извини, но твои сомнения надуманы. Ести тебе интересно, то можешь скачать какой-нить парсер SQL-я и побаловаться.
Опять. Синтаксис и семантика — не одно и тоже. Весь вопрос в том, можем ли проверить семантику в процессе парсинга синтаксиса. Для SQL — это нельзя.

GZ>>Д. Кнут при формализации семантических деревьев вывода определял два типа аттрибутов — синтезированные и унаследованные.

VD>Кнут? Ты ничего не путашь?
D. E. Knuth, Semantics of context free languages. Math. Systems Theory 2 (June 1968) 127-146.
Аттрибутная семантика — классика. Он не только толстые книжки писал.

GZ>> Пока строка select находится вначале запроса, они не являются ни тем ни другим. Транзитивные замыкания в данном случае вообще не обойдешь. Там своя специфика.

VD>И как SQL-серверы справляются? Видимо они телепаты.
Нет. Они работают изначально в графах. Однако у меня несколько другая задача.

GZ>>Для оптимизации, AST дерево вообще непригодно.

VD>Уууу...

GZ>> Операция проeкции(то что лежит в select) такая же реляционная операция как и другие. Задача самой оптимизации в основном можно определить как нахождение оптимального пути в цикличном графе. Что есть NP задача.


GZ>>Должен сказать что были попытки оптимизации на уровне SQL. Знаменитые работы Кима(логические оптимизации) были как раз основаны на оптимизации SQL строк. Но из-за бардака в самой семантики SQL подобные экзерцисы на групповых операциях оказались не совсем верные и даже ошибочные. В дальнейшем, была введена дополнительная расширенная реляционная алгебра и все встало на свои места.


VD>Я не знаю причем тут какие-то оптимизации. Речь шала кажется о комплите для SQL-я.

Вообще-то, об этом ты разговаривал с другими. Я всего лишь писал о порядке select-from и о разборе семантики.Re[6]: Чего не хватает в C#?
Автор: GlebZ
Дата: 20.12.05

VD>Задача не только что решаемая, но и решенная не раз. Мне понадобилось две минуты чтобы надыбать в Интеренете довольно приличный варинта подобного решения.
TOAD для Oracle имеет автокомплит. Но фиговый.
VD>Можешь ознакомиться http://www.promptsql.com .
Класс. На первой же странице деманструха. И что интересно, select * from уже вбито.

VD>Еогда будешь глядеть обрати особое внимание на то как эта штука работает с джоинами. Это просто песня.

Судя по демонструхе, он обрубает количество предложенных таблиц согласно foreing key. А это не всегда хорошо.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Язык запросов: from в начале
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.05 00:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Жаль это наблюдение не совсем точно. Ведь фраза "из ящика возьми карандаш" читается совсем погано.

WH>А мне пофигу... наверное я Йода...

Видимо. Но не расстраивайся, ты не одинок.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Язык запросов: from в начале
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.12.05 04:28
Оценка: 41 (4) :)
Здравствуйте, adontz, Вы писали:

A>Ты уж покажи тогда как замечательно всё подставиться если SELECT в конце.

ОК.
У меня никак нет времени попробовать сам link, поэтому проведем умственный эксперимент с обратным SQL. Вот результирующее выражение:
from (mytable group by id select id, max(value) as maxvalue) t  inner join myOtherTable k on k.id = t.id select t.id, maxvalue, name


Итак, начинаем набирать:

  1. from |

    В этот момент уже можно нажать Ctrl+Space и получить список таблиц. Но мы нажмем скобку, потому что знаем, что собираемся вводить временное выражение:
    from (|

  2. и только здесь выбираем mytable из списка по первым трем буквам
    from (mytable g|

  3. Теперь у нас есть выбор из нескольких определенных ключевых слов: order by/group by/where. А также возможность набрать произвольный псевдоним. Мы ограничимся выбором group by
    from (mytable g group by i|

  4. Тут совершенно понятно, что доступны только поля из таблички mytable. Без малейшей ошибки мы двигаемся дальше:
    from (mytable g group by id s|

  5. Здесь мы могли бы поставить запятую и добавить другое поле для группировки. Но мы так не сделали, что оставляет нам выбор из select, order by и having. Нетрудно видеть, что по первой букве мы легко опознаем выбор
    from (mytable g group by id select i|

  6. здесь нам опять же заранее известно, что ввести можно только имя одного из критериев группировки, либо агрегатную функцию. На i ни одна из функций не начинается:
    from (mytable g group by id select id, ma|

  7. За нас дописывает интеллисенс:
    from (mytable g group by id select id, max(|

  8. Очевидно, что список полей таблички, не попавших в group by, достаточно краток и мы быстро выбираем value и дописываем к нему псевдоним (при этом intellisense нам не мешает, т.к. знает, что это не его время):
    from (mytable g group by id select id, max(value) as maxvalue) |

  9. Здесь мы опять же можем ввести алиас либо group by/order by/where/left join/right join/inner join/full join. Вводим псевдоним, сужаем список до ключевых слов. Смотрите, как удобно — у нас все они начинаются с разных букв, значит ввести inner join мы можем за три нажатия: i Ctrl+Space Space
    from (mytable g group by id select id, max(value) as maxvalue) t inner join |

  10. Опять получаем список таблиц и выбираем myOtherTable
    from (mytable g group by id select id, max(value) as maxvalue) t inner join MyOtherTable k on |

  11. Интеллисенсу видно определение t и k. Поэтому для построения выражений предлагаются поля из них, а также выбор из встроенных функций. Ничего лишнего, максимально быстрый ввод.
    from (mytable g group by id select id, max(value) as maxvalue) t inner join MyOtherTable k on k.id = t.id s|

  12. Что характерно, здесь мы можем только продолжить выражение, введя AND, OR, или перейти к одному из ключевых слов group by/order by/where/left join/right join/inner join/full join. Мы выбираем select, и нам дают повыбирать поля из точно определенного списка. Причем доступны как оба алиаса t и k, так и те поля, которые не дублируются и позволяют указание без алиаса (id к ним не относится). В итоге мы легко и непринужденно добиваем список до конца:
    from (mytable group by id select id, max(value) as maxvalue) t  inner join myOtherTable k on k.id = t.id select t.id, maxvalue, name
A> А то у тебя странно как-то выходит, вместо того чтобы похвалить новое, ты почему-то ругаешь старое Чем новое-то лучше?
Полной определенностью. Вопрос о том, читается ли это хуже, чем оригинал, я оставляю открытым. Лично мне кажется, что лучше, потому что не надо прыгать взад-вперед для понимания структуры.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Язык запросов: from в начале
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.12.05 19:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

from (mytable group by id select id, max(value) as maxvalue) t  inner join myOtherTable k on k.id = t.id select t.id, maxvalue, name


Честно говоря я не очень понял зачем ты оперируешь с однобуквенными именами.
Я уж приведу тогда свой пример, который ИМХО более реалистичен. Собственно это даже не пример, а реальный запрос, так что он очень реалистичен.

SELECT forum_message_list.message_id, forum_message_list.parent_id, forum_message_list.thread_id, forum_message_list.forum_id,
forum_message_list.access_view, forum_message_list.access_edit, forum_message_list.access_reply, forum_message_list.access_mark,
forum_message_list.mark_message, forum_message_list.mark_thread, forum_message_list.class, forum_message_list.depth,
forum_message_list.timestamp_message, forum_message_list.timestamp_thread,
forum_message_list.title,
forum_user_list.user_id, forum_user_list.nickname, forum_message_list.user_host
FROM forum_message_list
INNER JOIN forum_user_list ON forum_user_list.user_id = forum_message_list.user_id
WHERE (message_id = 117) AND ((access_view & 15) <> 0)


S>Итак, начинаем набирать:


Угу. Давай

  1. Набрали SELECT. После этого перечисляем поля, которые хотим выбрать.
    SELECT

  2. Нажимаем Ctrl+Space (даже ничего не вводя) получаем список таблиц. Выбираем нужную, набирается имя таблицы, точка и выплывает список полей
    SELECT forum_message_list.▐

  3. Выбираем нужное поле. Вводятся так же запятая и пробел.
    SELECT forum_message_list.message_id, ▐

  4. Иван Бодягин утвержадет, что MRU бесполезен, но это не так. В дальнейшем, чтобы набрать "forum_message_list." мы нажимаем Ctrl+Space, Enter, потому что список таблиц сохраняет выделение. Если же поля перечислять в том же порядке в каком они идут в списке (а это может быть не только алфавитный порядок, но, что в данном случае ИМХО удобнее, и физический порядок), то для набора следующего поля надо нажать Ctrl+Space, Enter, Стрелка Вниз, Enter, потому что список полей тоже сохраняет выделение. То есть ни одной алфавитно-цифровой клавиши нажимать не надо.
    SELECT forum_message_list.message_id, forum_message_list.parent_id, forum_message_list.thread_id, forum_message_list.forum_id,
    forum_message_list.access_view, forum_message_list.access_edit, forum_message_list.access_reply, forum_message_list.access_mark,
    forum_message_list.mark_message, forum_message_list.mark_thread, forum_message_list.class, forum_message_list.depth,
    forum_message_list.timestamp_message, forum_message_list.timestamp_thread,
    forum_message_list.title,
    forum_user_list.user_id, forum_user_list.nickname, forum_message_list.user_host▐

  5. Набираем FROM после чего выплывает предложение вставить блоки FROM и INNER JOIN (информации для из вставки в уже набранном тексте и FK ограничениях достаточно). Как генерировать GROUP BY надо подумать, но я не вижу ничего не решаемого.
    SELECT forum_message_list.message_id, forum_message_list.parent_id, forum_message_list.thread_id, forum_message_list.forum_id,
    forum_message_list.access_view, forum_message_list.access_edit, forum_message_list.access_reply, forum_message_list.access_mark,
    forum_message_list.mark_message, forum_message_list.mark_thread, forum_message_list.class, forum_message_list.depth,
    forum_message_list.timestamp_message, forum_message_list.timestamp_thread,
    forum_message_list.title,
    forum_user_list.user_id, forum_user_list.nickname, forum_message_list.user_host
    FROM forum_message_list
    INNER JOIN forum_user_list ON forum_user_list.user_id = forum_message_list.user_id▐

  6. Осталось ручками (ну таблицы и их поля выплывают) набрать WHERE
    SELECT forum_message_list.message_id, forum_message_list.parent_id, forum_message_list.thread_id, forum_message_list.forum_id,
    forum_message_list.access_view, forum_message_list.access_edit, forum_message_list.access_reply, forum_message_list.access_mark,
    forum_message_list.mark_message, forum_message_list.mark_thread, forum_message_list.class, forum_message_list.depth,
    forum_message_list.timestamp_message, forum_message_list.timestamp_thread,
    forum_message_list.title,
    forum_user_list.user_id, forum_user_list.nickname, forum_message_list.user_host
    FROM forum_message_list
    INNER JOIN forum_user_list ON forum_user_list.user_id = forum_message_list.user_id
    WHERE (message_id = 117) AND ((access_view & 15) <> 0)▐
Итого, мы нажали клавиш (по пунктам)
  1. 7
  2. 2 + ?(пока выбрали таблицу forum_message_list, пусть будет 20) + 1
  3. ?(пока выбрали поле message_id, путь будет 5) + 1
  4. (14 + 3) * 4 + 2 + ?(пока выбрали таблицу forum_user_list, пусть будет 10) + 1
  5. 5 + 1(tab для автогенерации FROM) + 1(tab для автогенерации INNER JOIN)
  6. 54 (пусть ввели без подстказок)
Итого мы нажали 178 клавиш чтобы ввести текст в 726 символов, то есть иммем выгоду в 4 раза. К числам просьба не придираться плюс-минус 1-3 нажатия ничего не решают, да и от оформления кода это сильно зависит. Пусть адже будет не в 4, а в 2 раза.

По моим же расчётам для набора твоего запроса потребуется ну никак не меньше 80 нажатий клавиш, что при длине в 132 символа составляет выгоду в 1.5 раза. Весьма и весьма скромно, формально 65% текста всё таки придёться набрать, в том время как у меня 25%-50%.
Так что утверждения что select надо ставить назад потому что иначе не получится нормальный intellisence мне кажутся неубедительными. MRU делают своё дело куда лучше, чем эти странные изменения языка.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Язык запросов: from в начале
От: Merle Австрия http://rsdn.ru
Дата: 31.12.05 11:16
Оценка:
Здравствуйте, adontz, Вы писали:

A>Честно говоря я не очень понял зачем ты оперируешь с однобуквенными именами.

Потому как их читать удобнее.

A> Собственно это даже не пример, а реальный запрос, так что он очень реалистичен.

Мне жать тебя, если ты так пишешь запросы..

A>
  • Нажимаем Ctrl+Space (даже ничего не вводя) получаем список таблиц. Выбираем нужную, набирается имя таблицы, точка и выплывает список полей
    От указания полного имени таблицы, вместо алиаса, я отказался на втором в своей жизни SQL запросе. Это первое, а второе — до написания джойна далеко не всегда можно представить с какими именно таблицами ты будешь иметь дело.
    Так что твой пример очень далек от реальности, Тохин существенно ближе, посчитай нажатия в нем.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
  • Мы уже победили, просто это еще не так заметно...
    Re[11]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 31.12.05 11:21
    Оценка: +1
    Здравствуйте, Merle, Вы писали:

    A>>Честно говоря я не очень понял зачем ты оперируешь с однобуквенными именами.

    M>Потому как их читать удобнее.

    Однобуквенные имена лучше? Да уж, я рыдаю. Извини, это новогодняя шутка?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[12]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 31.12.05 12:44
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Однобуквенные имена лучше? Да уж, я рыдаю. Извини, это новогодняя шутка?

    Да какие уж тут шутки.
    Ром, расскажи, ты как переменную цикла обзываешь? for (i=... ) или for (variableWhichIterateThruMyCollection= ...)?
    А потом еще раз поговорим про недостатки однобуквенных имен.
    Поясню, если мысль не очевидна: Все однобуквенные имена, которые использовал Антон в своем запросе имеют смысл только для этого запроса.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[13]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 31.12.05 13:13
    Оценка:
    Здравствуйте, Merle, Вы писали:


    M>Ром, расскажи, ты как переменную цикла обзываешь? for (i=... ) или for (variableWhichIterateThruMyCollection= ...)?


    Нет, так я делал в школе, потому что i, j, k используются в математике

    Сейчас если цикл один и переменная используется для индексации массива я её называю index, если несколько вложенных циклов, то index с суффиксом по смыслу, типа indexRow, indexColumn, если переменная используется не для индексации в массиве, то как-то по-другому. Я никогда не использую однобуквенные имена. Более того, после первого же рефакторинга вычищаются все непонятные сокращения. Например, недавно, я использовал суффиксы E и O для обозначения чётных и нечётных числел (Even, Odd), после первого же переписывания набело они были заменены на полные слова, как малопонятные и неподдерживаемые.
    Код читается гораздо чаще, чем пишется ну так далее. Это обычно Владовская песня, у него больше опыта в дискуссиях, пусть он скажет Я просто соглашусь.

    M>Поясню, если мысль не очевидна: Все однобуквенные имена, которые использовал Антон в своем запросе имеют смысл только для этого запроса.


    То что алиас вешь локальная я знаю, не волнуйся. Я просто считаю, что однобуквенные имена в частности и непонятные сокращения вообще не имеют смысла и их применение зло. Я никогда не пользуюсь алиасами для сокращения имён (так же как и typedef и прочими подобными вещами), но могу его использовать чтобы новое имя лучше отражало смысл в контексте запроса.

    Вот такие пироги
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[13]: Язык запросов: from в начале
    От: Anton Batenev Россия https://github.com/abbat
    Дата: 31.12.05 14:21
    Оценка: +1
    Здравствуйте, Merle, Вы писали:

    A>>Однобуквенные имена лучше? Да уж, я рыдаю. Извини, это новогодняя шутка?

    M>Да какие уж тут шутки.
    M>Ром, расскажи, ты как переменную цикла обзываешь? for (i=... ) или for (variableWhichIterateThruMyCollection= ...)?

    Одно дело цикл, а другое дело имена таблиц.

    M>А потом еще раз поговорим про недостатки однобуквенных имен.


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

        select
               ID                 = e.ID,
               OriginateSubscriberID = s1.ID,
               --CardNumber         = a1.number,
               TerminateSubscriberID = s2.ID,
               TariffPlanName     = tpn1.name,
               SelfTariffPlanName = tpn2.name,
               CurrencyCode       = cur1.Code,
               CurrencyID         = ga1.currencyID,
               SelfCurrencyCode   = cur2.Code,
               SelfCurrencyID     = ga2.CurrencyID,
               SourcePort         = sp.VoicePort,
               DestPort           = dp.VoicePort,
               CodeDest           = ap.Code,
               RateDest           = case when apt.Price < 0 then 0 else apt.Price end,
               CurrRate  = 1,
               SelfCurrRate = 1
         from IPCallEvent e
          left outer join Account a1 on a1.ID = e.OriginateAccID
          left outer join Subscriber s1 on s1.ID = a1.SubscriberID
          left outer join Account a2 on a2.ID = e.TerminateAccID
          left outer join Subscriber s2 on s2.ID = a2.SubscriberID
          left outer join TariffPlan tp1 on tp1.ID = e.TariffPlanID
          left outer join TariffPlanName tpn1 on tpn1.ID = tp1.TariffPlanNameID
          left outer join TariffPlan tp2 on tp2.ID = e.SelfCostTariffPlanID
          left outer join TariffPlanName tpn2 on tpn2.ID = tp2.TariffPlanNameID
          left outer join GroupAccount ga1 on ga1.ID = a1.ParentID
          left outer join GroupAccount ga2 on ga2.ID = a2.ParentID
          left outer join Currency cur1 on cur1.ID = tp1.CurrencyID
          left outer join Currency cur2 on cur2.ID = tp2.CurrencyID
          left outer join VoicePortUsage sp on sp.ID = e.SourceVoicePortID
          left outer join VoicePortUsage dp on dp.ID = e.DestVoicePortID
          left outer join TimePeriod   tipe on tipe.ID = e.TimePeriodID
          left outer join AccessPoint ap on ap.ID = e.AccessPointID
          left outer join AccessPointTariff apt on apt.TimePeriodNameID = tipe.TimePeriodNameID and apt.AccessPointID = e.AccessPointID
         where (e.SetupTime between @From and @To
              )
          and (@TariffPlanID is null or e.TariffPlanID = @TariffPlanID or e.SelfCostTariffPlanID = @TariffPlanID)
          and (@AccessPointID is null or e.AccessPointID is null and @AccessPointID=0 or e.AccessPointID = @AccessPointID)
          and (@AccessPointName is null or e.AccessPointID is null and @AccessPointName=@resOther or
                e.AccessPointID in (select ID from accessPoint where name = @AccessPointName))
          and (@confID is null or e.ConfID like @confID + '%')
          and (@DisconnectCause is null or @DisconnectCause = e.DisconnectCause)
          and (@IPAddress is null or @IPAddress = e.originateIPAddr or @IPAddress = e.TerminateIPAddr)
          and (@called is null or @called = e.called)
          and (@VoicePort is null or sp.voicePort like @VoicePort or dp.voicePort like @VoicePort)
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[14]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 31.12.05 14:35
    Оценка: +2 -1
    Здравствуйте, Anton Batenev, Вы писали:

    AB>Одно дело цикл, а другое дело имена таблиц.

    Совершенно однофигственное.

    AB>Алиасы, конечно же, не однобуквенные, но исправить недолго.

    Вот ты в другую сторону исправь. Напиши полные имена таблиц вместо алиасов и посмотри как отлично это будет читаться.

    AB> Использование однобуквенных алиасов мне кажется крайне нецелесообразным.

    Одно-вух-трех — не принципиально, лишь бы не полные имена таблиц, если те не автогенеренные. На моей практике, от написания полных имен севший писать запросы всерьез отказывается максимум на третий день.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[15]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 31.12.05 14:46
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>На моей практике, от написания полных имен севший писать запросы всерьез отказывается максимум на третий день.


    Ну если делать выводы из твоих суждений об IntelliSence, становится ясно, что нормального IntelliSence для SQL ты и не видел никогда
    Как я уже показал набрать полное имя таблицы в моём варианте занимало 3 нажатия клавиши (Ctrl+Space, Enter) и получается нормальное имя, а не tbl34.fld47.
    Если же вручную набирать, то конечно не сладко.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[16]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 31.12.05 15:09
    Оценка: -1
    Здравствуйте, adontz, Вы писали:

    A>Ну если делать выводы из твоих суждений об IntelliSence, становится ясно, что нормального IntelliSence для SQL ты и не видел никогда

    Конечно не видел... Хотя перепробовал уже штук 7, просто их нет. Почему нет и как это должно выглядеть на самом деле — мы уже обсудили.

    A>Если же вручную набирать, то конечно не сладко.

    Во-первых, речь не о наборе, а о чтении того что набрали, это, кстати, ваш любимый аргумент. А во-вторых, еще раз повторю, до написания джойна ты еще не знаешь наверняка какие именно таблицы будут в запросе.
    Тебе надо сначала определиться откуда ты будешь брать, и каким образом, а уже потом решать что именно — и тут мы опять-таки приходим к тому, что select должен быть в конце.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[17]: Язык запросов: from в начале
    От: Anton Batenev Россия https://github.com/abbat
    Дата: 31.12.05 16:48
    Оценка: 36 (1) +2
    Здравствуйте, Merle, Вы писали:

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


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

    З.Ы. GMT +07:00 С Новым Годом!
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[14]: Язык запросов: from в начале
    От: IT Россия linq2db.com
    Дата: 31.12.05 21:28
    Оценка: +2
    Здравствуйте, Anton Batenev, Вы писали:

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


    Жуткий код, но вовсе не из-за алиасов. Что бы сделать его нормально читаемым достаточно правильно расставить отступы в джоинах. А так действительно нужно долго и нудно разбираться что к чему. И, кстати, с полными именами таблиц тут бы был полный дуром.
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[15]: Язык запросов: from в начале
    От: Anton Batenev Россия https://github.com/abbat
    Дата: 01.01.06 16:38
    Оценка: +1
    Здравствуйте, IT, Вы писали:

    IT> И, кстати, с полными именами таблиц тут бы был полный дуром.


    Думаю, что в данном конкретном случае, дурдом с полными именами таблиц воспринимается легче, нежели с алиасами — по крайней мере, смотря на полное имя таблицы можно понять о каких данных идет речь. Естественно, этот код не мешало бы нормально отформатировать и добавить комментарии.

    Тем не менее, все же есть случаи, в которых я считаю использование алиасов целесообразным:

    а) количество таблиц ограничено 1-3 (для меня 3 — максимум) и на выборку накладывается огромное количество условий — такое малое количество алиасов вполне можно держать в голове разбирая условие.
    б) таблицы запроса содержат данные о схожих сущностях — например {общий трафик, HTTP трафик, почтовый трафик}.

    Возможно, что что-то еще, но на вскидку не могу вспомнить.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[7]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 12:55
    Оценка:
    Здравствуйте, GlebZ, Вы писали:

    GZ>Но более всего убило примерно такое:

    GZ>хорошо было бы
    GZ>"SELECT" [table '.'] column_name ...
    GZ>а приходится делать
    GZ>"SELECT" table ['.' column_name] ...
    GZ>Естественно и table_name и column_name — один и тот же токен. То же самое со схемами. Думаю семантику легче будет сделать вторым проходом, или перейти уйти с COCO/R что делать лениво.

    Не обратил внимания не смысл этих слов ранее. Сейчас вдумался и долго-долго ржал. Я конечно все понимаю, но так красочно описывать проблему устранения левой рекусрии — это что-то. Так же позабавило и "Естественно и table_name и column_name — один и тот же токен.". Ёжику понятно один. Идентификатор и в Африке идентификатор.

    В общем, это проблемы разбора SQL, то дальше можно было бы и не разговаривать.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 12:55
    Оценка: -1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    Мне понадобилось 5 минут в гугле чтобы найти отличную реализацию интелисенса для SQL-я.
    Знакомься http://www.promptsql.com
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.01.06 13:22
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    VD> Мне понадобилось 5 минут в гугле чтобы найти отличную реализацию интелисенса для SQL-я.

    VD>Знакомься http://www.promptsql.com

    С новым годом. По поводу этого интеллисенса я (и не только я) уже высказывался.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[11]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 13:37
    Оценка: +2
    Здравствуйте, Merle, Вы писали:


    M>От указания полного имени таблицы, вместо алиаса, я отказался на втором в своей жизни SQL запросе. Это первое, а второе — до написания джойна далеко не всегда можно представить с какими именно таблицами ты будешь иметь дело.

    M>Так что твой пример очень далек от реальности, Тохин существенно ближе, посчитай нажатия в нем.

    Знаеш ли. Однобуквенные алиасы — это очень плохо. Нафига делать из своей головы хэш-таблицу? Не проще ли давать хоть сколь-нибудь осмысленные алисасы? А то и просто давать емкие имена таблицам?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 13:37
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Да какие уж тут шутки.

    M>Ром, расскажи, ты как переменную цикла обзываешь? for (i=... ) или for (variableWhichIterateThruMyCollection= ...)?

    Вань, аналогии в доказательствах не катят. "i" — это принятое, еще с Фортрана, сокращение для индексов. Никакх же принятых соглашений в предметной области быть не может по определнию.

    M>А потом еще раз поговорим про недостатки однобуквенных имен.


    А про них можно и так говорить. Если из имени не ясно, что оно олицетваряет — это очень плохо. Если запрос небольшой, то сокращение по первой букве еще куда не шло. Но в больших запросах с большим количеством таблиц хорошо бы иметь более менее понятные имена. Хотя бы какие-нибудь "usr" или "msg". Ну, или в на худой конце двух-трех буквенные по первым именам слов.

    M>Поясню, если мысль не очевидна: Все однобуквенные имена, которые использовал Антон в своем запросе имеют смысл только для этого запроса.


    Это не важно. Мена параметров и локальных переменных тоже локальных в пределах функций. Но вот что-то не очень радует "математический" стиль когда вместо осознанных имен переменных встречаются "a", "b", "c" и т.п.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 13:37
    Оценка: +1 -1
    Здравствуйте, Merle, Вы писали:

    AB>>Алиасы, конечно же, не однобуквенные, но исправить недолго.

    M>Вот ты в другую сторону исправь. Напиши полные имена таблиц вместо алиасов и посмотри как отлично это будет читаться.

    Откровенно говоря такие мега-запросы — это показатель неумения производить декомпозицию. По хорошему такой запрос нужно было бы разбить на представления или функции возвращающие таблицы. Тогда он бы хорошо читался бы в любом стиле. Но уж однобуквенные идентификаторы в таких монстрах — это уж точно ужасно.

    Поясню почему.


    Дело в том, что средний индивидум способен держать 5-9 сущьностей в голове (короткой памяти). Другими словами у него есть 5-9 (в среднем 7) слотов короткой памяти которые он может использовать эффективно. Отсюда 7 цветов радуги, 7 дрей недели и т.п. В общем, с 7 объектами работать удобно!

    Так вот, короткие имена смысла не имеют. По этому эти самые 7 слотов короткой памяти приходится использовать как замену хэш-таблицы хранящей соотвествие между реальными именами таблиц (точнее их смыслом выражающемся через имена) и алиасами.

    Пока алиасов немного, у человека остаются еще свободные слоты и он способен эффективно анализировать запрос. Но как только у их количество превышает 7 (5-9 для разных индивидумов), то сразу происходит серьезное падение производительности мозга. Мозг начинает концентрироваться на подзадачах (отдельном джоине, выборке полей из отдельного подзапроса и т.п.). При этом остальной контекст попросту вылетает из головы.

    В таких условиях человек вынужден то и дело обращаться к списку алиасов и т.п. выгружая и освобождая те самые 7 слотов. Естественно, что при этом возрастает объем работы мозга. Но главно, что при этом человек уже не способен смотреть на запрос или большие его части как на высокоуровневую абстракцию.

    В итое человек начинает быстро чувствовать усталость, перегруженность мозга и т.п.

    Наличие осмысленных имен позволяет реже перезагружать эти буферы и тем самым упрощает анализ проблемы.

    Короткие же идентификаторы дают исключительно компактность записи. Однако пока запрос влезает на экран толк от компактности не велик. А когда он вылезает за его пределы, уже давно пора заняться декомпозицией.

    Так приведенный выше пример наверно лучше было бы разбить на пару функций или представлений.


    Тогда бы запрос выглыдел совсем просто и был бы коротким.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 13:37
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Конечно не видел... Хотя перепробовал уже штук 7, просто их нет. Почему нет и как это должно выглядеть на самом деле — мы уже обсудили.


    Попробуй еще этот http://www.promptsql.com/
    Думаю, твое предубеждение быстро пройдет.

    A>>Если же вручную набирать, то конечно не сладко.

    M>Во-первых, речь не о наборе, а о чтении того что набрали, это, кстати, ваш любимый аргумент.

    Ваш? Это мой аргумент. И читать однобуквенные идентификаторы ой как неудобно. Но об этом я уже высказался.

    M> А во-вторых, еще раз повторю, до написания джойна ты еще не знаешь наверняка какие именно таблицы будут в запросе.

    M>Тебе надо сначала определиться откуда ты будешь брать, и каким образом, а уже потом решать что именно — и тут мы опять-таки приходим к тому, что select должен быть в конце.

    Думаю, любой кто пишет не тривиальный запрос постоянно переходит из select-а во from, из from-а в group by и обратно (в хаотичесоком порядке). Так что совершенно пофигу какая из конструкций пишется первой. Я лично готов поставить "*" и вернуться к полям позже (так и делаю).

    А вот если вспомнить мой любимый аргумент... читатья хочу запрос по чловечески, а не по Ёдски.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 13:37
    Оценка: -1
    Здравствуйте, IT, Вы писали:

    IT>Жуткий код, но вовсе не из-за алиасов. Что бы сделать его нормально читаемым достаточно правильно расставить отступы в джоинах. А так действительно нужно долго и нудно разбираться что к чему. И, кстати, с полными именами таблиц тут бы был полный дуром.


    Отступы тут не помогут. Это случай где нужен рефакторинг. Такие монструозные запросы нужно разбивать на подзапросы (ну, представления, такм, функции, разные...).

    И тогда полные имена не будут жутью.

    ЗЫ

    Кстати, в этом запросе имена хоть двух-ртрехбуквенные. А бвывает что дествительно "t", "a" и т.п. Вот это уже полная задница.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 13:47
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>>>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    VD>> Мне понадобилось 5 минут в гугле чтобы найти отличную реализацию интелисенса для SQL-я.

    VD>>Знакомься http://www.promptsql.com

    AVK>С новым годом.


    И тебя с тем же.

    AVK> По поводу этого интеллисенса я (и не только я) уже высказывался.


    Ага. Я заметил (жирным выделено). Вот только я тебе дал ссылку полностью опровергающую твои слова. Если потратишь 5 минут на инсталляцию, то сможешь расстаться с одним своим заблуждением.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 13:50
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Попробуй еще этот http://www.promptsql.com/

    VD>Думаю, твое предубеждение быстро пройдет.
    Я его пробовал, когда он еще беттой был.

    VD> Так что совершенно пофигу какая из конструкций пишется первой. Я лично готов поставить "*" и вернуться к полям позже (так и делаю).

    А я нет.

    VD>А вот если вспомнить мой любимый аргумент... читатья хочу запрос по чловечески, а не по Ёдски.

    С from впереди и будет по человечески. Почему — я уже неоднократно говорил.
    Ты же сам, в соседнем форуме рассказывал как надо бороться с привычками — чуть-чуть попишегь SQL по человечески и сам не поймешь, как ты раньше мог select в переди ставить.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[14]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 13:50
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Вань, аналогии в доказательствах не катят. "i" — это принятое, еще с Фортрана, сокращение для индексов. Никакх же принятых соглашений в предметной области быть не может по определнию.

    Во-первых данная аналогия здесь более чем уместна, а во-вторых — не знаю как там на счет определений, но для SQL-я "t" для вложенных запросов такой же стандарт, как и "i" для циклов, да и история этого сокращения не меньше чем у "i".
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[12]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 13:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Знаеш ли. Однобуквенные алиасы — это очень плохо. Нафига делать из своей головы хэш-таблицу? Не проще ли давать хоть сколь-нибудь осмысленные алисасы? А то и просто давать емкие имена таблицам?

    Re[14]: Чего не хватает в C#?
    Автор: Merle
    Дата: 31.12.05
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[16]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 02.01.06 14:18
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Кстати, в этом запросе имена хоть двух-ртрехбуквенные. А бвывает что дествительно "t", "a" и т.п. Вот это уже полная задница.


    Тут даже не в длине дело, а в смысле. Две недели назад я закатил серьёзный скандал (не для всех закончившийся хорошо) после разгребания очередной пачки переменных label38, text17, button22...
    И идентификатор temporary_table_for_subquery делу не поможет, потому что суть хранящихся данных из него не видна.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[15]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 02.01.06 14:21
    Оценка: -2
    Здравствуйте, Merle, Вы писали:

    M>Во-первых данная аналогия здесь более чем уместна, а во-вторых — не знаю как там на счет определений, но для SQL-я "t" для вложенных запросов такой же стандарт, как и "i" для циклов, да и история этого сокращения не меньше чем у "i".


    Ну на самом деле i, j, k не из Фортрана пришли, а из математики, а t это просто сокращение от table. Но даже если бы у t была бы суперистория на 278 страниц использование однобуквенных идентификаторов это никак не оправдывает. for (i = 0;... тоже зло и ничуть не меньшее.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:12
    Оценка: -1
    Здравствуйте, Merle, Вы писали:

    VD>>Попробуй еще этот http://www.promptsql.com/

    VD>>Думаю, твое предубеждение быстро пройдет.
    M>Я его пробовал, когда он еще беттой был.

    А когда он релизом стал пробовал? Ну, и что тебя в нем не устраивает?

    VD>> Так что совершенно пофигу какая из конструкций пишется первой. Я лично готов поставить "*" и вернуться к полям позже (так и делаю).

    M>А я нет.

    И как же ты живешь то на свете?

    VD>>А вот если вспомнить мой любимый аргумент... читатья хочу запрос по чловечески, а не по Ёдски.

    M>С from впереди и будет по человечески. Почему — я уже неоднократно говорил.

    Да? Ну, тогда извини. Тут спорить не о чем. Если уж полностью перевернутая фраза становится нормальной, то значит желание настоять на своем куда больше чем желание разобраться в чем-то конструктивно.

    M>Ты же сам, в соседнем форуме рассказывал как надо бороться с привычками — чуть-чуть попишегь SQL по человечески и сам не поймешь, как ты раньше мог select в переди ставить.


    Это не привычка, а язык. Можно конечно сказать, что язык — это привычка, но это слишком глобальная привычка. Это все человечество переучивать прийдется. Тут проще рацаонализаторам по рукам линейкой насучать.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:12
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Тут даже не в длине дело, а в смысле. Две недели назад я закатил серьёзный скандал (не для всех закончившийся хорошо) после разгребания очередной пачки переменных label38, text17, button22...

    A>И идентификатор temporary_table_for_subquery делу не поможет, потому что суть хранящихся данных из него не видна.

    Согласен. Хотя давать осмысленные имена индексам в циклах я лично не стал бы.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:12
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Во-первых данная аналогия здесь более чем уместна,


    Вань, на будующее... Аналогии вообще неуместны ни для чего кроме как для пояснений. То есть ты можешь сказать "синяя как небо" или "колючий как ежик". Но любая попытка доказать что-то по аналогии является обманом.

    M> а во-вторых — не знаю как там на счет определений, но для SQL-я "t" для вложенных запросов такой же стандарт, как и "i" для циклов, да и история этого сокращения не меньше чем у "i".


    Да? Можно источник информации?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:12
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Ну на самом деле i, j, k не из Фортрана пришли, а из математики, а t это просто сокращение от table.


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

    A> Но даже если бы у t была бы суперистория на 278 страниц использование однобуквенных идентификаторов это никак не оправдывает. for (i = 0;... тоже зло и ничуть не меньшее.


    Вот тут, ну, хоть убей не вижу смысла. Какая разница между i и index? Особенно если цикл один и других индексов по близости нет. Наоборот подчеркивает, что индекс из for-а.

    Точно так же бессмысленно давать длинные имена координатам. Ну, какое еще имя можно дать коорденате x или y?

    Мне кажется тут, как и в других случаях, не нужно перегибать палку. И однобуквенные имена для всех переменных, и длинные имена для бессмысленных работчих переменных — это перебор. Просто с разных сторон.

    Во всем нужно чувство меры. Вложенную таблицу лучше назвать неким именем которое хоть какие-то ассоциации вызвает, но и с пол страницы имя тоже давать не следует.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 02.01.06 15:27
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Вот тут, ну, хоть убей не вижу смысла. Какая разница между i и index? Особенно если цикл один и других индексов по близости нет. Наоборот подчеркивает, что индекс из for-а.


    Если цикл один, то не очень много. Тут у меня скорее привычка. Пока набираю ndex думаю об условиях завершения цикла. Параллелизм однако

    VD>Точно так же бессмысленно давать длинные имена координатам. Ну, какое еще имя можно дать коорденате x или y?


    X и Y это уже предметная область, а не чистое программирование. X и Y даже при желании длинее не запишешь. Но вот догадываться, что rtlx это верхняя левая координата прямоугольника это уж увольте.

    VD>Мне кажется тут, как и в других случаях, не нужно перегибать палку. И однобуквенные имена для всех переменных, и длинные имена для бессмысленных работчих переменных — это перебор. Просто с разных сторон.


    Не всегда. Например (буквально из написанного 5 минут тому назад делаю пример) увидев это
    egy[i, j] = (1 - k) * egy[i, j] + e

    придёться лазить глазами вверх и вниз чтобы понять что это, зато строчка ниже понятна сама по себе
    energy[indexFrequency, indexSample] = (1 - fade) * energy[indexFrequency, indexSample] + energyCurrent;


    Ну можно ещё iFreq, iSample использовать, например, если выражение слишком уж большим выходит. Меру конечно же надо знать.

    VD>Во всем нужно чувство меры. Вложенную таблицу лучше назвать неким именем которое хоть какие-то ассоциации вызвает, но и с пол страницы имя тоже давать не следует.


    +1
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[8]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.01.06 15:28
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ага. Я заметил (жирным выделено). Вот только я тебе дал ссылку полностью опровергающую твои слова.


    А я тебе на это уже отвечал, что я не считаю такой интеллисенс нормальным.

    VD>Если потратишь 5 минут на инсталляцию, то сможешь расстаться с одним своим заблуждением.


    Я видело его. А помимо него видел (и какое то время даже работал) еще c PL/SQL Developer, еще видел какой то прототип от МС. Нету там интеллисенса, который я бы хотел иметь (и который примерно описал Антоха).
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[20]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.01.06 15:32
    Оценка: -2
    Здравствуйте, VladD2, Вы писали:

    Минус за переход на личности.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[20]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 15:46
    Оценка: +2
    Здравствуйте, VladD2, Вы писали:

    VD>А когда он релизом стал пробовал?

    Пробовал.

    VD>Ну, и что тебя в нем не устраивает?

    Все уже описано...

    VD>И как же ты живешь то на свете?

    С трудом.

    VD>Тут спорить не о чем.

    Действительно.

    VD> Если уж полностью перевернутая фраза становится нормальной, то значит желание настоять на своем куда больше чем желание разобраться в чем-то конструктивно.

    По поводу разобраться конструктивно — золотые слова! Пойми, здесь нет понятия "фраза перевернута". Это не человеческий язык, не смотря на все попытки сделать его таковым. Смысл в сиквельную фразу вкладывется совсем другой, акценты ставятся в других местах и читается он по другому, и то что ты так упорно не хочешь этого понимать — и есть отсутствие конструктива, так что спорить действительно неочем. Это уже вопрос веры, очевидно что ты все равно будешь называть такой синтаксис "бредовым", а мне совершенно все равно как ты его называешь, главное пользоваться им удобно.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[16]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 15:46
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Вань, на будующее... Аналогии вообще неуместны ни для чего кроме как для пояснений. То есть ты можешь сказать "синяя как небо" или "колючий как ежик". Но любая попытка доказать что-то по аналогии является обманом.

    Влад, на будующее... Я никому, ничего не пытаюсь доказать, мне совершенно безразлично будут ли другие считать этот синтаксис "бредовым" или нет — все равно им придется пользоваться если Хайлсберг введет его в язык именно так.
    Я лишь пытаюсь донести свою точку зрения и пояснить, почему я считаю такой синтаксис удобным, раз уж я ввязался в эту дискуссию. Поэтому совершенно спокойно оперирую удобными мне аналогиями.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[13]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:49
    Оценка:
    Здравствуйте, GlebZ, Вы писали:

    VD>>

    !@#$%^&*()P_{@#$%^&*()_@#$%^&*()_

    VD>>
    GZ>Конструктивно.

    Я демонстрировал конструктивность твоих примеров.

    VD>>А если серьзено, то погляди вот это AST SQL Grammar

    GZ>Мы говорим о семантике или о синтаксисе?

    Мы говорили о возможности ителисенса для SQL-я в том виде в каком он есть в стандарте вроде SQL-92.

    GZ>>>Ага. С выделенной вершиной забыл. А так верно. Только граф здесь подразумевает циклы.

    VD>>Вершина, точнее корень, в графе вещь условная. Просто всегда удобно смореть на AST как на дерево с одним корнем. Это проще для мозга.
    GZ>Нет. Не условная. Определение грамматики Наума Хомского:...

    Эко тебя понесло.

    GZ>Порождающей грамматикой Хомского G называется четверка объектов: G=(T,N,S,R), где:

    GZ>T — терминальный словарь
    GZ>N — нетерминальный словарь
    GZ>S — начальный символ
    GZ>R — конечное непустое множество правил(продукций)
    GZ>Так что начальный символ — он всегда есть. Собственно он и есть начало грамматики.

    А теперт вспомни какое отношение грамматика имеет к AST, и то что в AST есть такие вещи как атрибуты. Например, ссылки на типы. Вместе с ними AST становится грфом. А у графа много чего может быть вершиной дерева.

    VD>>Количество проходов по AST мало кого трогает. Это же очень быстро. Ты можешь за 100 милисекунд обойти тысячу раз AST SQL-запроса. Этого никто не заметит.

    GZ>Чего-то много написал. Особенно если время ответа БД может достигать 10ms.

    Не надо жанглировать цифрами. Думаю, ты понял о чем речь идет. Скорость доступа к БД не сопоставима со скоростью парсинга. Отсюда и возможен динамический SQL.

    VD>>Ошибок здесь нет. Это синтаксически верная конструкция. Ну, а онаружить семантические ошибки легко. Разбирашь запрос в AST и строишь таблицу символов. Классика, однко!

    GZ>Ага, вторым проходом. Потому как первым проходом такое не сделаешь.

    Не вторым проходом, а обходом AST. Причем хоть вторым, хоть 10. Разницы в этом нет.

    VD>>Ой, опять ты громкими словами пользушся. В общем, ты меня извини, но твои сомнения надуманы. Ести тебе интересно, то можешь скачать какой-нить парсер SQL-я и побаловаться.

    GZ>Опять. Синтаксис и семантика — не одно и тоже.

    Видимо кто-то это утверждал, раз ты это подчеркивашь. Не мог бы показать где?

    GZ> Весь вопрос в том, можем ли проверить семантику в процессе парсинга синтаксиса. Для SQL — это нельзя.


    В 99% современных языков невозможно полностью отработать семантику в процессе парсинга. Но это им не мешает.

    Может быть ты пояснишь почему ты прицепился к этому вопросу? Что плохого в отработке семантики по AST?

    GZ>>> Пока строка select находится вначале запроса, они не являются ни тем ни другим. Транзитивные замыкания в данном случае вообще не обойдешь. Там своя специфика.

    VD>>И как SQL-серверы справляются? Видимо они телепаты.
    GZ>Нет. Они работают изначально в графах. Однако у меня несколько другая задача.

    Какая, если не сикрет? Ты еще не забыл, что мы говорили об интелесенсе для SQL? Не уж то полный разбор запросов серверами более прост нежели тот что нужен для интелесенса?

    VD>>Я не знаю причем тут какие-то оптимизации. Речь шала кажется о комплите для SQL-я.

    GZ>Вообще-то, об этом ты разговаривал с другими. Я всего лишь писал о порядке select-from и о разборе семантики.Re[6]: Чего не хватает в C#?
    Автор: GlebZ
    Дата: 20.12.05


    Вообще-то ты начал защищать заявление АВК:

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    И догворился до довольно забавных вещей.

    VD>>Можешь ознакомиться http://www.promptsql.com .

    GZ>Класс. На первой же странице деманструха. И что интересно, select * from уже вбито.

    И что? Там есть "демонструха" в которой комлитят имена таблиц до набора from.

    Но какое это все имеет отношение к делу? Комплит работает? Несомненно! Качественно? Несомненно!

    Так о чем этот бессмысленный разговор? Что ты пыташся доказать, что то что можно скачать и попробывать невозможно в принципе из-за каких-то неразрешимых проблем ("это очень серьезная проблема").
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:49
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>А я тебе на это уже отвечал, что я не считаю такой интеллисенс нормальным.


    И что же тебе в нем не нарвится? Или ты не глядя в этом уверен?

    VD>>Если потратишь 5 минут на инсталляцию, то сможешь расстаться с одним своим заблуждением.


    AVK>Я видело его. А помимо него видел (и какое то время даже работал) еще c PL/SQL Developer, еще видел какой то прототип от МС. Нету там интеллисенса, который я бы хотел иметь (и который примерно описал Антоха).


    И что же тебе нехватает? Не, уж-то прерставленного раком "select"?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:59
    Оценка: -1
    Здравствуйте, Merle, Вы писали:

    VD>>Ну, и что тебя в нем не устраивает?

    M>Все уже описано...

    Где? Ссылочку не затруднит дать?

    M>По поводу разобраться конструктивно — золотые слова! Пойми, здесь нет понятия "фраза перевернута".


    Да? А вот учебник английского языка с тобой хочет поспорить. Да и русского тоже.

    M> Это не человеческий язык,


    Да? "Выбрать ххх из ууу" — это не человеческий язык? Зра, видать, ребята из IBM старались.

    M> не смотря на все попытки сделать его таковым. Смысл в сиквельную фразу вкладывется совсем другой, акценты ставятся в других местах и читается он по другому, и то что ты так упорно не хочешь этого понимать — и есть отсутствие конструктива, так что спорить действительно неочем. Это уже вопрос веры, очевидно что ты все равно будешь называть такой синтаксис "бредовым", а мне совершенно все равно как ты его называешь, главное пользоваться им удобно.


    Вопрос веры? Нда. Я бы сказал о вере у кого-то другого. Причем не веры в некие истины, а веры в дяду который не может ошибаться. Забавно, что будет если дядю все же убедят в том, что удобство реализации интелесенста не стоит усложнения восприятия кода.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 15:59
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Здравствуйте, VladD2, Вы писали:


    VD>>Вань, на будующее... Аналогии вообще неуместны ни для чего кроме как для пояснений. То есть ты можешь сказать "синяя как небо" или "колючий как ежик". Но любая попытка доказать что-то по аналогии является обманом.

    M>Влад, на будующее... Я никому, ничего не пытаюсь доказать, мне совершенно безразлично будут ли другие считать этот синтаксис "бредовым" или нет — все равно им придется пользоваться если Хайлсберг введет его в язык именно так.

    Не пыташся? А как навать фразу:

    Ром, расскажи, ты как переменную цикла обзываешь? for (i=... ) или for (variableWhichIterateThruMyCollection= ...)?
    А потом еще раз поговорим про недостатки однобуквенных имен.



    M>Я лишь пытаюсь донести свою точку зрения и пояснить, почему я считаю такой синтаксис удобным, раз уж я ввязался в эту дискуссию. Поэтому совершенно спокойно оперирую удобными мне аналогиями.


    Ну, вот когда доносишь свою точку зрения, то знай, что аналогии хороши только как иллюстрации. Но не как не для сравнений и доказательств.

    И за одно не нужно утрировать. А то ведь "variableWhichIterateThruMyCollection" явно высасаное из пальца имя. А какие-нибудь "index", "rowIndex" или просто "row" выглядит не так страшно и эффект от аналогии будет совсем не тем.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[10]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.01.06 16:00
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>А я тебе на это уже отвечал, что я не считаю такой интеллисенс нормальным.


    VD>И что же тебе в нем не нарвится? Или ты не глядя в этом уверен?


    Я уже объяснял что. Перечитай топик еще раз.

    VD>И что же тебе нехватает? Не, уж-то прерставленного раком "select"?


    Re[8]: Чего не хватает в C#?
    Автор: Sinclair
    Дата: 28.12.05
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[11]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 16:08
    Оценка: -1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Я уже объяснял что. Перечитай топик еще раз.


    Ну, считай что отмазался. Я вот только из твоих слов поню только это:
    Re[4]: Чего не хватает в C#?
    Автор: AndrewVK
    Дата: 18.12.05

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.

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

    VD>>И что же тебе нехватает? Не, уж-то прерставленного раком "select"?


    AVK>Re[8]: Чего не хватает в C#?
    Автор: Sinclair
    Дата: 28.12.05


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

    ЗЫ

    Так все же ты можешь объяснить, что не так конкретно в этой реализации?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 02.01.06 16:26
    Оценка: +1
    Здравствуйте, Merle, Вы писали:

    M>главное пользоваться им удобно.


    Ты забыл вставить слово "мне"
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[18]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 17:01
    Оценка: -1 :)
    Здравствуйте, VladD2, Вы писали:

    VD>Не пыташся?

    Не пытаюсь.

    VD> А как навать фразу:

    Как хочешь...

    VD>Ну, вот когда доносишь свою точку зрения, то знай, что аналогии хороши только как иллюстрации.

    Именно в этом качестве я ее и использовал.

    VD>Но не как не для сравнений и доказательств.

    Еще раз повторяю — я никому ничего не доказываю, тем более тебе, за очевидной бесперспективностью этого занятия. Это просто не стоит затраченных усилий, особенно в данном вопросе.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[22]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 02.01.06 17:01
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Где? Ссылочку не затруднит дать?

    В этом топике.

    VD>Да? А вот учебник английского языка с тобой хочет поспорить. Да и русского тоже.

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

    VD>Да?

    Да.

    VD>Вопрос веры? Нда. Я бы сказал о вере у кого-то другого. Причем не веры в некие истины, а веры в дяду который не может ошибаться.

    Причем тут какой-то дядя? В предложеном виде мне и писать и читать код будет удобнее, почему — я уже объяснил. Ты можешь с этим не соглашаться, спорить и доказывать, но писать код задом наперед, равно как и читать, удобнее не станет.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[12]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.01.06 18:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>Re[8]: Чего не хватает в C#?
    Автор: Sinclair
    Дата: 28.12.05


    VD>Это слова Синклера.


    И что?

    VD> Опять же являющейся не более чем не верной теорией


    Надеюсь в случае линка это будет практикой.

    VD> не имеющей смысла так как есть работающее приложение прекрасно их опровергающее.


    Видимо ты так и не понял, о чем там писалось.

    VD>Так все же ты можешь объяснить, что не так конкретно в этой реализации?


    Влад, если ты забыл/прочитал по диагонали этот топик это твои проблемы. Все что я хотел сказать я или другие собеседники уже сказали.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[13]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.01.06 19:24
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Это слова Синклера.


    AVK>И что?


    Что? Процетирую тебя:

    Я уже объяснял что. Перечитай топик еще раз.


    Вот и хотелось бы поглядеть на твои объяснения. А то я слышал только удобство набора кода.

    VD>> Опять же являющейся не более чем не верной теорией


    AVK>Надеюсь в случае линка это будет практикой.


    В свою очередь надеюсь, что это будет не так. Иначе лучше было бы вообще не косить под SQL.

    VD>> не имеющей смысла так как есть работающее приложение прекрасно их опровергающее.


    AVK>Видимо ты так и не понял, о чем там писалось.


    Тебе удобно так считать.

    VD>>Так все же ты можешь объяснить, что не так конкретно в этой реализации?


    AVK>Влад, если ты забыл/прочитал по диагонали этот топик это твои проблемы. Все что я хотел сказать я или другие собеседники уже сказали.


    Ясно. Значит начальника транспортного цеха мы так и не услышим. Что-то вы с Мерлом стали ссылаться "в воздух". Ладно, ясно, что аргументов мы тут уже не услышим. "Этого не может быть потому-что не может быть никогда." С такой позицией не поспоришь.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[14]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.01.06 20:27
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>И что?


    VD>Что? Процетирую тебя:

    VD>

    Я уже объяснял что. Перечитай топик еще раз.


    VD>Вот и хотелось бы поглядеть на твои объяснения. А то я слышал только удобство набора кода.


    Синклер объяснил это более доходчиво.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[12]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 03.01.06 03:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Здравствуйте, Merle, Вы писали:


    A>>>Честно говоря я не очень понял зачем ты оперируешь с однобуквенными именами.

    M>>Потому как их читать удобнее.

    A>Однобуквенные имена лучше? Да уж, я рыдаю. Извини, это новогодняя шутка?

    A>
    Я боюсь тебя разочаровать, но как правило имена таблиц должны иметь как можно более понятные названия. Проблема в классическом SQL — в отсутствии неймспейсов. Оно приводит к невозможности разделить наименования нормально, и таблички типа CustomerOrder встречаются только в сэмплах. Таким образом, мы приходим к кошмарным тавтологиям в запросах без алиасов:
    Select customerOrder.Id, customerOrder.amount, customerOrder.shipmentKind from customerOrder.

    Далее, одна таблица может встречаться в одном запросе много раз. Это означает, что без использования алиасов такой запрос ты не напишешь вообще никак.

    Поэтому в промышленности алиасы используются в 100% запросов. Они, конечно, не обязательно однобуквенные. Как правило, их выбирают так, чтобы была понятна роль отношения в данном запросе. Так что твой юмор неуместен.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[16]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 03.01.06 03:40
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Merle, Вы писали:


    AB>>>Алиасы, конечно же, не однобуквенные, но исправить недолго.

    M>>Вот ты в другую сторону исправь. Напиши полные имена таблиц вместо алиасов и посмотри как отлично это будет читаться.

    VD>Откровенно говоря такие мега-запросы — это показатель неумения производить декомпозицию. По хорошему такой запрос нужно было бы разбить на представления или функции возвращающие таблицы. Тогда он бы хорошо читался бы в любом стиле. Но уж однобуквенные идентификаторы в таких монстрах — это уж точно ужасно.

    Хм. Влад, ты не мог бы продемонстрировать это? Я всегда нутром чуял, что надо декомпозировать запросы. Но блин на практике вечно то надо с семеркой совместимость поддерживать, то времени на переписывание нет.
    VD>Поясню почему.
    Да в курсе мы, в курсе. Покажи на примере, а? Ну вот у нас же у всех Northwind стоит. Вот выведи мне табличку с именами заказчиков и суммами заказов по годам.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[16]: Язык запросов: from в начале
    От: Anton Batenev Россия https://github.com/abbat
    Дата: 03.01.06 05:34
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Так приведенный выше пример наверно лучше было бы разбить на пару функций или представлений.

    VD>Тогда бы запрос выглыдел совсем просто и был бы коротким.

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

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

    По этому, чтобы из двух зол не выбрать оба, то и следует как-то "смягчать" головную боль от таких запросов.

    Я не против алиасов и не за полные имена, но (в общем виде)

    SELECT * FROM my_table t
    
    SELECT my_table.* FROM my_table
    
    SELECT t.* FROM my_table t
    
    SELECT my_table.* FROM my_table t


    это клиника и должно быть или вылечено или удалено хирургическим путем.

    Во всем остальном должен быть найден компромисс.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[13]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 03.01.06 14:03
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Я боюсь тебя разочаровать, но как правило имена таблиц должны иметь как можно более понятные названия. Проблема в классическом SQL — в отсутствии неймспейсов.


    Странный аргумент. Неймспейс это такая неинстанциируемая штука которую можно расширять из разных единиц трансляции. Неймспейс же в SQL я себе представляю слабо и разницы между module1::table1 и module1_table1 не вижу, разве что нельзя будет использовать относительные имена написав using module1, но если мы используем несколько неймспейсов (об чём и речь) в которых сущности с одинаковыми именами, то всё равно придётся использовать полные имена... Вобщем я не понял причём тут неймспейсы
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 14:28
    Оценка: -1 :)
    Здравствуйте, Sinclair, Вы писали:

    S>Хм. Влад, ты не мог бы продемонстрировать это? Я всегда нутром чуял, что надо декомпозировать запросы. Но блин на практике вечно то надо с семеркой совместимость поддерживать, то времени на переписывание нет.


    "Семерка" уже имеет нехилые средства для этого. Так что если ты не издевашся, то можешь поглядеть мою старую статью Информационная система и реляционная СУБД
    Автор(ы): Владислав Чистяков
    . Статья в общем-то не о декомпозиции запросов, но там в конце как раз приведен пример декомпозиции довольно сложного запроса.

    VD>>Поясню почему.

    S>Да в курсе мы, в курсе. Покажи на примере, а? Ну вот у нас же у всех Northwind стоит. Вот выведи мне табличку с именами заказчиков и суммами заказов по годам.

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

    И вообще, я не очень понимаю природу твоего писимизма. Любой язык обладающий средствами декомпозиции позволяет ее родимую делать. SQL обладает такими средствами как VIEW и пользовательские функции (в большинстве диалектов). Неуже ли тебя нужно обучать как с их помощью монструозный запрос можно разбить на несколько относительно простых?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 15:18
    Оценка:
    Здравствуйте, Anton Batenev, Вы писали:

    AB>Но тогда бы возникла вторая проблема. Вот открываем мы список ХП / функций / вьюшек и... просто теряемся в их количестве.


    Да, уж сероезная проблема. То ли дело запросы на пол экрана.

    Собственно сто лет назад были придуманы способы структорирования кода. Вводи префиксы разделяющие функци на группы. Формуруй некую идеологию именавания.

    AB>Берем первую попавшуюся ХП, долго смотрим ее код и думаем для чего она нужна, а выясняется, что она нужна для другой, единственной ХП только для того, чтобы не было таких монстроидальных запросов.


    Тоже серьезнейшая проблема, если не писать комментарии и не давать осмысленые имена функциям.

    AB>Не сомневаюсь, Влад, что под словом "декомпозиция" ты имел ввиду декомпозицию на часто используемые общие части (запросы). Однако, выделить частоиспользуемую общую часть практически невозможно или просто нецелесообразно из за еще большего ухудшения читаемости кода.


    Нда, получается декомпозиция ухудшает читаемость. Здорово!

    Не уж. Декомпозиция ее повышает! Декомпозиция это сдерсво выделение абстракций. Запрос созданный из нескольких абстрактных процедур/представлений будет прост и его можно будет лего проанализировать. Ну, а смысл его понятен так как понятно что делает каждая из вызываемых процедур (используемых представлений).
    Если же захочется разобраться с вызываемыми процедурами, то тоже нет проблем. Открываем их по отдельности и изучаем. При этом мы всегда работаем с локальным контекстом который всегда прос и понятен.

    Вобще очень странно, что этому учат в любой книжке по программированию, но применительно к SQL — это вызвает какие-то сомнения.

    AB>По этому, чтобы из двух зол не выбрать оба, то и следует как-то "смягчать" головную боль от таких запросов.


    Ну, есть еще один способ. Писать запросы в некотором построителе запросов, например, встроенном в Студию или в SQL Server Management Studio, ну, а в программе смотреть на запросы как на некие БЛОБ-ы. Но тогда что заморачиваться на длинну идентификаторов?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 15:18
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Синклер объяснил это более доходчиво.


    Ну, а зачем тогда было говорить, что ты объяснял?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 15:18
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Я боюсь тебя разочаровать, но как правило имена таблиц должны иметь как можно более понятные названия. Проблема в классическом SQL — в отсутствии неймспейсов. Оно приводит к невозможности разделить наименования нормально, и таблички типа CustomerOrder встречаются только в сэмплах. Таким образом, мы приходим к кошмарным тавтологиям в запросах без алиасов:

    S>Select customerOrder.Id, customerOrder.amount, customerOrder.shipmentKind from customerOrder.

    Дык никто же не заставляет вообще отказаться от алиасов. Просто пусть они хоть немного осмысленными будут, а не "t" или "a". Лично меня бы устроило "order" или даже "ord". Лиш бы легко ассоциировалось с тем что он представляет.

    S>Далее, одна таблица может встречаться в одном запросе много раз. Это означает, что без использования алиасов такой запрос ты не напишешь вообще никак.


    Ну, а она встречается как нечто осмысленное или просто так засунули до кучи? Если первое, то может передать это в алиасе? Ну, там "cust" для покупателя и "emp" для служещего?

    S>Поэтому в промышленности алиасы используются в 100% запросов. Они, конечно, не обязательно однобуквенные. Как правило, их выбирают так, чтобы была понятна роль отношения в данном запросе. Так что твой юмор неуместен.


    И все же тут вроде как обсуждается, что это правило предлагается заменить на однобуквенные, бессмысленные идентификаторы. Мол а хрен там разбираться все равно на пять миунт имя даем...
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[14]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 15:18
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Странный аргумент. Неймспейс это такая неинстанциируемая штука которую можно расширять из разных единиц трансляции. Неймспейс же в SQL я себе представляю слабо и разницы между module1::table1 и module1_table1 не вижу, разве что нельзя будет использовать относительные имена написав using module1, но если мы используем несколько неймспейсов (об чём и речь) в которых сущности с одинаковыми именами, то всё равно придётся использовать полные имена... Вобщем я не понял причём тут неймспейсы


    А, я вот согласен с Синклером. Мне тоже бы было приятно видеть простраства имен в SQL-е. Хотя владельцев тоже можно за таковых принять. Жаль только много гемороя создавать объекты из под разных владельцев и давать на все объекты права.

    А так было бы просто здоврово разделить таблицы по предметным областаям. Функции по решаемым проблемам и т.п.

    ЗЫ

    Вообще БД отстали от индустрии как-то уж очень сильно. Если бы не декларативный SQL, то вообще не ясно как это чудо дожило до этого времени.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 15:18
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    Синклер, ты меня извини, но это смешно. Какая-то детская пошаговка.

    Все одновременно и проще и сложнее. Парсить слева на правао как ты говоришь в принципе невозможно, так как SQL не LL(1)-язык.

    С другой стороны в нем достаточно уникальных LL(1)-конструкций чтобы выделить унжные части и распарсить их.

    Приводить напальцевое доказательности этого нет ни малейшего желания. Просто скачай http://www.promptsql.com/ и попробуй. Это уже работающий инструмент. И по мне так очень приличный. Если у него и есть неудобства, то они яувно в юзабилити, а не в проблемах парсинга.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 03.01.06 15:48
    Оценка: +3
    Здравствуйте, adontz, Вы писали:

    A>Ты забыл вставить слово "мне"

    Нет, не забыл... Судя по этому топику так будет удобнее тем, кто SQL-ем реально пользуется..
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[14]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 03.01.06 15:48
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Дык никто же не заставляет вообще отказаться от алиасов.

    ....
    VD>И все же тут вроде как обсуждается, что это правило предлагается заменить на однобуквенные, бессмысленные идентификаторы. Мол а хрен там разбираться все равно на пять миунт имя даем...
    Блинский фиг, Влад. Давай ты в следующий раз, прежде чем писать, внимательно прочитаешь все что написали тебе. Может хоть тогда ты будешь спорить с тем что тебе на самом деле сказали, а не сам с собой.
    Мало того, что ты просто не разобрался с тем кто о чем спорит, ты еще и ссылку не прочитал, когда я тебя уже пытался поправить.
    Как раз Рома настаивал на реальных именах таблиц, а мы с Тохой говорим, что надо использовать алиасы, не важно из скольких букв они состоят — одной или больше.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[15]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 16:46
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Блинский фиг, Влад.


    Я не знаю кто такой "Блинский", но я точно не его фиг.

    M>Давай ты в следующий раз, прежде чем писать, внимательно прочитаешь все что написали тебе. Может хоть тогда ты будешь спорить с тем что тебе на самом деле сказали, а не сам с собой.


    Ой, я что-то пропутил? Где?

    M>Мало того, что ты просто не разобрался с тем кто о чем спорит,


    Серьезно?

    M> ты еще и ссылку не прочитал, когда я тебя уже пытался поправить.


    Ссылку? Вань, ты меня извени, но тема обсуждала "что добавить в C#". Ты вней мало того что обсуждашь SQL, но еще и умудряшся меня упрекать, что я видите ли что-то не прочел.

    M>Как раз Рома настаивал на реальных именах таблиц, а мы с Тохой говорим, что надо использовать алиасы, не важно из скольких букв они состоят — одной или больше.


    Как все не совсем та. Ты тут не раз настаивал на то, что однобуквенные алиасы это нармально. С чем собственно и спорим. А вот недавно ты тут даже умудрился не согласиться с тем что чтобы код читался лучше нужно производить его декомпозицию. Ссылки дать или пще помнишь свои слова/действия?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.01.06 16:46
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Нет, не забыл... Судя по этому топику так будет удобнее тем, кто SQL-ем реально пользуется..


    Ой, Вань. Ты действительно считашь, что им пользуется 3 человека и ты в их числе?

    Да, и... Я вот уверен, что если посчитать время которое я пользовался SQL-ем, то оно сильно привысит твое. Но хоть убей из этого никаких выводов сделать не получается.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Язык запросов: from в начале
    От: Anton Batenev Россия https://github.com/abbat
    Дата: 03.01.06 19:05
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AB>>Не сомневаюсь, Влад, что под словом "декомпозиция" ты имел ввиду декомпозицию на часто используемые общие части (запросы). Однако, выделить частоиспользуемую общую часть практически невозможно или просто нецелесообразно из за еще большего ухудшения читаемости кода.

    VD>Нда, получается декомпозиция ухудшает читаемость. Здорово!

    Нет, я не об этом. В общем случае, несомненно, декомпозиция улучшает читаемость и прочая и прочая. Но не об этом я.

    VD>Не уж. Декомпозиция ее повышает! Декомпозиция это сдерсво выделение абстракций. Запрос созданный из нескольких абстрактных процедур/представлений будет прост и его можно будет лего проанализировать.


    Вот в этом-то все и дело. Какая абстракция может быть между

    список групп клиентов -> группа клиентов -> клиент -> список договоров -> договор -> список приложений к договору -> приложение -> типы тарифов -> тариф -> типы зон -> зона -> отношение зон к типам тарифов -> отношение зоны к тарифу клиента -> минуты?

    Да их могут быть сотни на все случаи жизни (особая прелесть — это пункт дополнительные условия, котрые накладываются практически на каждую часть этой цепочки)! А еще большая прелесть, когда ты только поддерживаешь систему и ни название ни список параметров ты поменять не можешь... Только изменить внутренности ХП и вренуть то, что предполагает клиент.

    VD> Ну, а смысл его понятен так как понятно что делает каждая из вызываемых процедур (используемых представлений).


    Вот об этом я и говорю. ХП принимает 10-15 параметров, описывающих все возможные ситуации, занимает 5-10 экранов и использует подобные монстроидальные запросы и все в одной ХП — вся абстрактность в одном флаконе — мы из клиентской части не задумываемся о том, ХП с каким именем вызвать, а просто вызываем ее с нужным списком параметров.

    С учетом того, что из EM от MS-SQL (2000) можно просматривать только одну ХП в каждый момент времени, то татальная декопозиция только усугубит ситуацию. Я же говорю о том, чтобы все необходимые данные были перед глазами и не приходилось держать в памяти мозга 20 алиасов, помнить за что какая табличка / ХП отвечает и т.д. Т.е. пусть запросы будут большими — не вопрос, но они должны быть написаны так, чтобы их можно было быстро понять.

    VD>Если же захочется разобраться с вызываемыми процедурами, то тоже нет проблем. Открываем их по отдельности и изучаем. При этом мы всегда работаем с локальным контекстом который всегда прос и понятен.


    И при это получаем дополнительно 10-15 дополнительных ХП, которые используются только в родительской и нигде больше.

    VD>Вобще очень странно, что этому учат в любой книжке по программированию, но применительно к SQL — это вызвает какие-то сомнения.


    Да, но к третьей форме нормализации это получается как-то плохо применимо...

    AB>>По этому, чтобы из двух зол не выбрать оба, то и следует как-то "смягчать" головную боль от таких запросов.

    VD>Ну, есть еще один способ. Писать запросы в некотором построителе запросов, например, встроенном в Студию или в SQL Server Management Studio, ну, а в программе смотреть на запросы как на некие БЛОБ-ы. Но тогда что заморачиваться на длинну идентификаторов?

    "Код чаще читается нежели пишется" или я что-то пропустил?
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[16]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 03.01.06 21:11
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ой, я что-то пропутил?

    Определенно.

    VD> Где?

    Пол-топика примерно...

    VD>Серьезно?

    Абсолютно.

    VD>Ссылку?

    Именно.

    VD> Ты вней мало того что обсуждашь SQL, но еще и умудряшся меня упрекать, что я видите ли что-то не прочел.

    Ну что я могу поделать, если ты не читаешь? Только упрекать...

    VD>Как все не совсем та.

    Ух-ты. То есть ты лучше меня знаешь, что я имею ввиду и с чем не соглашаюсь. Именно об этом я и говорил, когда упомянул, что беседуешь ты сам с собой, а не с тем что тебе написали.

    VD> Ты тут не раз настаивал на то, что однобуквенные алиасы это нармально.

    Нормально. Так же как и двух, и трех. В контексте нововведений в шарп и SQL-евского интеллисенса (о которых по твоим же словам мы и разговариваем) это не принципиально, важно что это именно алиасы, а не реальные имена таблиц, и именно этот тонкий момент ты почему-то предпочел опустить.

    VD>С чем собственно и спорим.

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

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

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

    VD>Ссылки дать или пще помнишь свои слова/действия?

    Сначала сам топик внимательно прочитай, и воспользуйся ссылками которые тебе дали другие...
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[8]: Язык запросов: from в начале
    От: GlebZ Россия  
    Дата: 03.01.06 23:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    GZ>>Естественно и table_name и column_name — один и тот же токен. То же самое со схемами. Думаю семантику легче будет сделать вторым проходом, или перейти уйти с COCO/R что делать лениво.


    VD>Не обратил внимания не смысл этих слов ранее. Сейчас вдумался и долго-долго ржал. Я конечно все понимаю, но так красочно описывать проблему устранения левой рекусрии — это что-то. Так же позабавило и "Естественно и table_name и column_name — один и тот же токен.". Ёжику понятно один. Идентификатор и в Африке идентификатор.

    Наконец-то ты начал понимать.

    VD>В общем, это проблемы разбора SQL, то дальше можно было бы и не разговаривать.

    В данном случае, я не говорил о проблеме разбора SQL. Я говорил о проблеме COCO/R и его LL(1).(см. выделенное).
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[16]: Язык запросов: from в начале
    От: GlebZ Россия  
    Дата: 03.01.06 23:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Откровенно говоря такие мега-запросы — это показатель неумения производить декомпозицию. По хорошему такой запрос нужно было бы разбить на представления или функции возвращающие таблицы.

    [skipped]

    VD>Тогда бы запрос выглыдел совсем просто и был бы коротким.

    В работе с БД царят другие законы чем в языках программирования. Здесь мы работаем с потенциально большими данными, в потенциально медленном хранилище с наличием потенциально медленных каналов. Здесь важно эффективность выполнения запроса. А иногда, и даже чаще, такое мега-запрос значительно эффективнее чем куча запросов. Через представления часто получается такие-же здоровые запросы, и иногда не очень эффективные. И функции поддерживают далеко не все БД.
    Собственно поэтому, лично мне, и интеллегенс вообще не интересен и даже читабельность. Эффективность для меня — значительно важней.

    С уважением, Gleb.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[14]: Язык запросов: from в начале
    От: GlebZ Россия  
    Дата: 04.01.06 02:08
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    GZ>>Конструктивно.

    VD>Я демонстрировал конструктивность твоих примеров.
    Ну-ну.

    VD>>>А если серьзено, то погляди вот это AST SQL Grammar

    GZ>>Мы говорим о семантике или о синтаксисе?
    VD>Мы говорили о возможности ителисенса для SQL-я в том виде в каком он есть в стандарте вроде SQL-92.
    Странно. Вот об интелисенс я вообще не упоминал. Мне он мало интересен.

    VD>А теперт вспомни какое отношение грамматика имеет к AST, и то что в AST есть такие вещи как атрибуты. Например, ссылки на типы. Вместе с ними AST становится грфом. А у графа много чего может быть вершиной дерева.

    Ну наконец-то. Это уже ближе к теме. Вопрос в том, что при данном построении AST относительно семантики(интерпретации) атрибуты не применимы.

    VD>>>Количество проходов по AST мало кого трогает. Это же очень быстро. Ты можешь за 100 милисекунд обойти тысячу раз AST SQL-запроса. Этого никто не заметит.

    GZ>>Чего-то много написал. Особенно если время ответа БД может достигать 10ms.
    VD>Не надо жанглировать цифрами. Думаю, ты понял о чем речь идет. Скорость доступа к БД не сопоставима со скоростью парсинга. Отсюда и возможен динамический SQL.
    Да нет. С цифрами то как раз худо. Есть понятие семантической оптимизации(изымает лишние инструкции), тоже NP задача. Может делаться еще до построения коньюктивной или дизьюнктивной формы. Поэтому там может исчисляться не тысячами, а больше. И закон тут простой, чем больше успеешь сделать за единицу времени, тем качественнее оптимизация.

    VD>>>Ой, опять ты громкими словами пользушся. В общем, ты меня извини, но твои сомнения надуманы. Ести тебе интересно, то можешь скачать какой-нить парсер SQL-я и побаловаться.

    GZ>>Опять. Синтаксис и семантика — не одно и тоже.
    VD>Видимо кто-то это утверждал, раз ты это подчеркивашь. Не мог бы показать где?
    Странный вопрос. Возьми любой учебник по формальным языкам или интерпретируемым языкам. Увидишь что такое синтаксис, семантика и прагматика.

    GZ>> Весь вопрос в том, можем ли проверить семантику в процессе парсинга синтаксиса. Для SQL — это нельзя.

    VD>В 99% современных языков невозможно полностью отработать семантику в процессе парсинга. Но это им не мешает.
    VD>Может быть ты пояснишь почему ты прицепился к этому вопросу? Что плохого в отработке семантики по AST?
    Она не подходит ни для интерпретации, ни для оптимизации. А самое главное, оно не подошло под мою задачу.

    GZ>>>> Пока строка select находится вначале запроса, они не являются ни тем ни другим. Транзитивные замыкания в данном случае вообще не обойдешь. Там своя специфика.

    VD>>>И как SQL-серверы справляются? Видимо они телепаты.
    GZ>>Нет. Они работают изначально в графах. Однако у меня несколько другая задача.
    VD>Какая, если не сикрет? Ты еще не забыл, что мы говорили об интелесенсе для SQL? Не уж то полный разбор запросов серверами более прост нежели тот что нужен для интелесенса?
    Я говорил об автоматизированной обработке SQL. Чем я только что занимался.

    VD>>>Я не знаю причем тут какие-то оптимизации. Речь шала кажется о комплите для SQL-я.

    GZ>>Вообще-то, об этом ты разговаривал с другими. Я всего лишь писал о порядке select-from и о разборе семантики.Re[6]: Чего не хватает в C#?
    Автор: GlebZ
    Дата: 20.12.05


    VD>Вообще-то ты начал защищать заявление АВК:

    VD>

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.

    VD>И догворился до довольно забавных вещей.
    Честно говоря я не имел ввиду именно intellisence. Но эти проблемы как раз связаны. И связаны именно порядком операторов.

    VD>>>Можешь ознакомиться http://www.promptsql.com .

    GZ>>Класс. На первой же странице деманструха. И что интересно, select * from уже вбито.
    VD>И что? Там есть "демонструха" в которой комлитят имена таблиц до набора from.
    VD>Но какое это все имеет отношение к делу? Комплит работает? Несомненно! Качественно? Несомненно!
    Насчет качественно, то кроме качественной деманструхи ничего не увидел. Он мало отличается от других intellisence.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.01.06 10:57
    Оценка:
    Здравствуйте, Anton Batenev, Вы писали:

    VD>>Не уж. Декомпозиция ее повышает! Декомпозиция это сдерсво выделение абстракций. Запрос созданный из нескольких абстрактных процедур/представлений будет прост и его можно будет лего проанализировать.


    AB>Вот в этом-то все и дело. Какая абстракция может быть между


    AB>список групп клиентов -> группа клиентов -> клиент -> список договоров -> договор -> список приложений к договору -> приложение -> типы тарифов -> тариф -> типы зон -> зона -> отношение зон к типам тарифов -> отношение зоны к тарифу клиента -> минуты?


    К сожалению, я не владею предметной обласью о которой идет речь, так что 100%-ного ответа дать не могу. Но даже по названиям таблиц и джоинам видно, что можно выделить как минимум 3-5 подсушностей.

    AB>Да их могут быть сотни на все случаи жизни


    А вот так не бывает. Все же предметная область, есть предметная область. Там все не ради кличества сущьностей проектировлось.

    AB>А еще большая прелесть, когда ты только поддерживаешь систему и ни название ни список параметров ты поменять не можешь... Только изменить внутренности ХП и вренуть то, что предполагает клиент.


    Если система плохо спроектирована, то я бы предпочел постепенный рефакторинг. Занялся проблемой Х... произвел рефакторинг связанных с ней сщьностей. В итоге через пол годика получишь легко поддерживаемую систему.


    AB>Вот об этом я и говорю. ХП принимает 10-15 параметров,


    Уже настораживает.

    AB> описывающих все возможные ситуации, занимает 5-10 экранов и использует подобные монстроидальные запросы и все в одной ХП — вся абстрактность в одном флаконе — мы из клиентской части не задумываемся о том, ХП с каким именем вызвать, а просто вызываем ее с нужным списком параметров.


    Это называется ламерство. Так позволительно писать только начинающим. И то плохо. Я еще понял бы если бы речь шала о MS SQL 6.5 где были огромные проблемы в передаче данных между процедурами. Но начиная с MS SQL 2000 (а то и с 7-мерки) таких проблем вообще нет.

    AB>С учетом того, что из EM от MS-SQL (2000) можно просматривать только одну ХП в каждый момент времени


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

    AB>, то татальная декопозиция только усугубит ситуацию.


    Тяжело же тебе, наверное, работать.

    AB> Я же говорю о том, чтобы все необходимые данные были перед глазами и не приходилось держать в памяти мозга 20 алиасов, помнить за что какая табличка / ХП отвечает и т.д. Т.е. пусть запросы будут большими — не вопрос, но они должны быть написаны так, чтобы их можно было быстро понять.


    Груда кода в 5 экранов — это "все необходимые данные были перед"? Нет, уж. Увольте.

    AB>И при это получаем дополнительно 10-15 дополнительных ХП, которые используются только в родительской и нигде больше.


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

    А их количество лично меня не волнует. Хоть тысячу. Если у меня будут проблемы с их каталогизацией, я напишу специальную софтину для их редактирования. Или воспользуюсь имеющейся (вроде Студии).

    VD>>Вобще очень странно, что этому учат в любой книжке по программированию, но применительно к SQL — это вызвает какие-то сомнения.


    AB>Да, но к третьей форме нормализации это получается как-то плохо применимо...


    Это перпендикулярные понятия. Одно другому не мешает. Даже более того. Хорошо нормализованная база просто напрашивается для обвязки ее набором функций и представлений, так как иначе получается слишком много громоздких запросов.

    VD>>Ну, есть еще один способ. Писать запросы в некотором построителе запросов, например, встроенном в Студию или в SQL Server Management Studio, ну, а в программе смотреть на запросы как на некие БЛОБ-ы. Но тогда что заморачиваться на длинну идентификаторов?


    AB>"Код чаще читается нежели пишется" или я что-то пропустил?


    Дык, хочешь почитать... копирушь БЛОБ в КБЕ-ху и читашь распознанное представление. Я как бы не старонник такого решения, но оно тоже имеет право на жизнь.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.01.06 10:57
    Оценка:
    Здравствуйте, GlebZ, Вы писали:

    VD>>Тогда бы запрос выглыдел совсем просто и был бы коротким.

    GZ>В работе с БД царят другие законы чем в языках программирования.

    Это отмазки тех кто неумеет применять законы там где это нужно.

    GZ> Здесь мы работаем с потенциально большими данными, в потенциально медленном хранилище с наличием потенциально медленных каналов.


    И какое это отношение может иметь к выделению абстракций, декомпозиции и вообще принципам грамотного программирования?

    GZ> Здесь важно эффективность выполнения запроса.


    И что декомпозиция обязана понижать эффективность? Да будет тебе извесно, современные серверы переписывают запросы перед выполнением. Они не будут "выполятья" представление или функцию. Они восоздадут исходный запрос и выполнят его целиком.

    GZ> А иногда, и даже чаще, такое мега-запрос значительно эффективнее чем куча запросов.


    Это твое умозрительное заключение. На практие все совсем не так.

    GZ> Через представления часто получается такие-же здоровые запросы,


    Значит неграмоно создаются эти самые представления.

    GZ> и иногда не очень эффективные.


    Они и в монструозном виде будут такими же не эффективными.

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

    К тому же СУБД предоставляют средства оптимизации не уродующие абстракции. Среди них есть хинты, индексированные представления, триггеры и т.п. Они дают отличный эффект и в первую очередь задействовать нужно их, а не пытаться подшаманить запрос так чтобы он выполнялся подругому. Надо понимать, что подшаманеный запрос может в любую минуту начать тормозить. Не говоря уже о том, что его сложно поддерживать и вообще не ясно что будет сним на следующей версии SQL-сервера или на другой БД.

    GZ> И функции поддерживают далеко не все БД.


    Да почти все что заслуживают уважения. А в нашем случае вообще речь шла о MS SQL.

    Ну, да в любом случае представления есть везде. И не воспользоваться ими — грех.

    GZ>Собственно поэтому, лично мне, и интеллегенс вообще не интересен и даже читабельность. Эффективность для меня — значительно важней.


    Что я могу сказать?... Очень плохо.
    Эффективности нужно добиваться алгоритмически. Это всегда дает самый большой эффект. А замазки и подмазки — это всегда шаг в ад на земле.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.01.06 10:57
    Оценка: -1
    Здравствуйте, GlebZ, Вы писали:

    VD>>Не обратил внимания не смысл этих слов ранее. Сейчас вдумался и долго-долго ржал. Я конечно все понимаю, но так красочно описывать проблему устранения левой рекусрии — это что-то. Так же позабавило и "Естественно и table_name и column_name — один и тот же токен.". Ёжику понятно один. Идентификатор и в Африке идентификатор.

    GZ>Наконец-то ты начал понимать.

    Что я стал понимать? То что ты как ребенок возмущашься LL(1)-ограничениями и тем, что для анализа серьезных языков требуется строить AST?

    VD>>В общем, это проблемы разбора SQL, то дальше можно было бы и не разговаривать.

    GZ>В данном случае, я не говорил о проблеме разбора SQL. Я говорил о проблеме COCO/R и его LL(1).(см. выделенное).

    Да не проблемы это. Уж реализации интелисенса это никак помешать не может.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.01.06 10:57
    Оценка: -1
    Здравствуйте, GlebZ, Вы писали:

    GZ>Странно. Вот об интелисенс я вообще не упоминал. Мне он мало интересен.


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

    GZ>Ну наконец-то. Это уже ближе к теме. Вопрос в том, что при данном построении AST относительно семантики(интерпретации) атрибуты не применимы.


    Что? Поясни свою мысль по подрьбнее, плиз.

    GZ>>>Опять. Синтаксис и семантика — не одно и тоже.

    VD>>Видимо кто-то это утверждал, раз ты это подчеркивашь. Не мог бы показать где?
    GZ>Странный вопрос. Возьми любой учебник по формальным языкам или интерпретируемым языкам. Увидишь что такое синтаксис, семантика и прагматика.

    Я имел в виду "показать где я говорил, что синтаксис и семантика — это одно и тоже".

    VD>>Может быть ты пояснишь почему ты прицепился к этому вопросу? Что плохого в отработке семантики по AST?

    GZ>Она не подходит ни для интерпретации, ни для оптимизации. А самое главное, оно не подошло под мою задачу.

    Это не правда. И интерпретацию, и поптимизацию на AST делать можно. Но ты уходишь от темы. Еще раз повторяю вопрос:
    Что плохого в отработке семантики по AST?
    И еще раз напоминаю, что речь в этой подветке идет о постраении интелисенса для SQL.

    GZ>Честно говоря я не имел ввиду именно intellisence. Но эти проблемы как раз связаны. И связаны именно порядком операторов.


    Я вообще не понял что ты имел в виду. Ты влез в разговор об интелисенсе и ушел куда-то в даль. И я даже не могу понять цили нашего разговора. О чем мы, Сэр?

    GZ>Насчет качественно, то кроме качественной деманструхи ничего не увидел.


    А ты попробуй.

    GZ> Он мало отличается от других intellisence.


    Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе. А ты полез защищать эту мягко говоря натянутое утверждение.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.01.06 10:57
    Оценка:
    Здравствуйте, Merle, Вы писали:

    VD>> Ты вней мало того что обсуждашь SQL, но еще и умудряшся меня упрекать, что я видите ли что-то не прочел.

    M>Ну что я могу поделать, если ты не читаешь? Только упрекать...

    И все же попросил бы ссылку, на то что я по твоему мнению пропустил.

    Или ты не утверждал что однобугвенные алиасы для таблиц — это нармально? Если так, то извини, я действительно все понял не так.

    VD>>Как все не совсем та.

    M>Ух-ты. То есть ты лучше меня знаешь, что я имею ввиду и с чем не соглашаюсь. Именно об этом я и говорил, когда упомянул, что беседуешь ты сам с собой, а не с тем что тебе написали.

    Ваня, ты открытым текстом говорил о нормальности однобуквенных и полностью бессмысленных алиасов и ставил минус на сообщении в котором высказывалась всего одна мысль "сложные запросы нужно подвергать декомпозиции". Что же тут можно знать хуже тебя?

    Если ты неверно выразился, то скажи об этом. Скажи, что хотел сказать нечто другое. Тогда предмет спора отпадет сам собой. И не нужно перенимать у АВК столь некрасивые методы отмазок "ты лучше меня...". Не дави на чувства. И не нужно обсуждать меня. Лучше обсудить твои слова. А то я ведь все твои слова можно с тем же успехом применить к тебе.

    VD>> Ты тут не раз настаивал на то, что однобуквенные алиасы это нармально.

    M>Нормально. Так же как и двух, и трех.

    Ну, "трех" уже могут иметь осмысленные значения. А вот однобуквенные... это то о чем мы с тобой говорили. И не нужно мне рассказывать сказки, что я что-то где-то пропустил. Все ОК. Вот с этим я и не согласен. Я и сам халтурщик, но не думаю, что поддерживать халтуру хорошо. А уж оправдывать ее точно не дело.

    M> В контексте нововведений в шарп и SQL-евского интеллисенса (о которых по твоим же словам мы и разговариваем) это не принципиально, важно что это именно алиасы, а не реальные имена таблиц, и именно этот тонкий момент ты почему-то предпочел опустить.


    Ну, про алиасы разговор защел уже применительно к обычному SQL-ю. Хотя я тоже как-то не вижу приципиальности в данном вопросе. Может пояснишь, что я тут пропустил? Что такого особенного в алиасах? И почему в LinQ-е им нельзя давать более менее разумные имена?

    VD>>С чем собственно и спорим.

    M>Я примерно понимаю с чем спорят остальные активные участники, но уже с трудом понимаю с чем споришь именно ты.

    В конкретном случае с тем, что однобуквенные алиасы — это нормально. Вот только не не вижу связи между этим и меспоположением select-а.

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

    M>Я несогласился с другим. Я не согласился с тем что декомпозиция так широко применима в SQL-е как тебе того хочется,

    Вот вот. Для меня это спор с очевидными вещами. И минусы без аргументации тут конечно выглядят очень достойны.

    M>но ограничился минусом из тех соображений, что, как ты метко подметил, топик немного не про SQL.


    Ну, это не трдудно исправить. Можно отделить тему.

    VD>>Ссылки дать или пще помнишь свои слова/действия?

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

    Ненадо меня посылать так долеко. Предположим, что я прчитал тему в два раза внимательнее чем ты. Если ты хочшь доказать обратное, то потрудись дать ссылки. Если нет, то прекрати заниматься внушением и навешиванием ярлыков. Задумайся над тем, что ты сам мог неверно что-то понять.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 04.01.06 12:07
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Как раз Рома настаивал на реальных именах таблиц, а мы с Тохой говорим, что надо использовать алиасы, не важно из скольких букв они состоят — одной или больше.


    Я настаивал на использовании осмысленных имён и на использовании алиасов для уточнения смысла в контексте запроса, а не сокращения букв!
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[23]: Язык запросов: from в начале
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 04.01.06 20:24
    Оценка: :))
    Здравствуйте, Merle, Вы писали:

    A>>Ты забыл вставить слово "мне"

    M>Нет, не забыл... Судя по этому топику так будет удобнее тем, кто SQL-ем реально пользуется..

    Молодец. Очень красиво обозвал всех опонентов дилетантами. Но я тебя раскусил и ты меня не убедил.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[18]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 04.01.06 21:27
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>И все же попросил бы ссылку, на то что я по твоему мнению пропустил.

    Легко. Но только после того как ты ответишь на один простой вопрос: Почему я должен в очередной раз тыкать тебя в те места, которые ты пропустил?

    VD>Или ты не утверждал что однобугвенные алиасы для таблиц — это нармально?

    Утверждал, только я нигде не утверждал, что однобуквенные алиасы это всегда нормально. Чувствуешь разницу?

    VD>Ваня, ты открытым текстом говорил о нормальности однобуквенных и полностью бессмысленных алиасов и ставил минус на сообщении в котором высказывалась всего одна мысль "сложные запросы нужно подвергать декомпозиции".

    Передергиваешь. Я нигде не говорил открытым текстом, что однобуквенные алиасы всегда совершенно нормально, и на чем я ставил минус я написал ответом раньше. Или ты это опять пропустил?

    VD> Что же тут можно знать хуже тебя?

    Твоя самоуверенность тебя подводит.

    VD>Если ты неверно выразился, то скажи об этом.

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

    VD> Скажи, что хотел сказать нечто другое. Тогда предмет спора отпадет сам собой.

    Я сказал ровно то что сказал. Если тебе что-то непонятно, то лучше уточни, и воздержись от безапелляционных утверждений.

    VD>А вот однобуквенные... это то о чем мы с тобой говорили.

    Это то о чем ты говорил. Мне совершенно не интересно сколькобуквенным должен быть алиас по твоему мнению, ну тоесть вообще.
    Важно что это именно алиас.

    VD> И не нужно мне рассказывать сказки, что я что-то где-то пропустил.

    Увы, но это не сказки.

    VD> Хотя я тоже как-то не вижу приципиальности в данном вопросе. Может пояснишь, что я тут пропустил?

    Ты пропустил Ромин вариант SQL-ного интеллисенса, который невозможен, если в запросе используются алиасы. Собственно с этого сообщения и зашел разговор про алиасы вообще.

    VD>В конкретном случае с тем, что однобуквенные алиасы — это нормально.

    Байта ради, только не со мной...

    VD>Вот только не не вижу связи между этим и меспоположением select-а.

    Потому что читаешь по диагонали.

    VD>И минусы без аргументации тут конечно выглядят очень достойны.

    Сначала свои безаргументные минусы посчитай, потом поговорим..

    VD>Ненадо меня посылать так долеко.

    А что еще с тобой делать?

    VD> Если ты хочшь доказать обратное, то потрудись дать ссылки.

    Как только ты даш ответ, зачем я должен читать топик вместо тебя. Или у тебя принцип такой — ты не воспринимаешь аргумент, если его повторили менее 8 раз?

    VD>Если нет, то прекрати заниматься внушением и навешиванием ярлыков.

    "Бред" и "полая фигня" — это твои ярлыки, я же не навесил ни одного.

    VD>Задумайся над тем, что ты сам мог неверно что-то понять.

    Например, что?
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[16]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 04.01.06 21:27
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я настаивал на использовании осмысленных имён и на использовании алиасов для уточнения смысла в контексте запроса, а не сокращения букв!

    Проблема в том, что твой вариант интелисенса невозможен при использовании алиасов, а уж для чего ты их будешь использовать — дело десятое.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[18]: Язык запросов: from в начале
    От: GlebZ Россия  
    Дата: 04.01.06 21:37
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    GZ>> Здесь мы работаем с потенциально большими данными, в потенциально медленном хранилище с наличием потенциально медленных каналов.

    VD>И какое это отношение может иметь к выделению абстракций, декомпозиции и вообще принципам грамотного программирования?
    Грамотное программирование в модели данных не такое же как в объектных моделях.

    VD>И что декомпозиция обязана понижать эффективность?

    Декомпозиция, а в реляционке это называется нормализация БД, увеличивают кол-во сущностей экономя пространство, но чаще всего увеличивая накладные расходы на выполнение. При нормализованной базе как раз и получается куча джоинов. Зачастую, объект это всего лишь набор идентификаторов из разных справочников.

    VD>Да будет тебе извесно, современные серверы переписывают запросы перед выполнением. Они не будут "выполятья" представление или функцию. Они восоздадут исходный запрос и выполнят его целиком.

    Насчет представления верно (с некоторыми оговорками, но это к данному вопросу не относится). Насчет функций — не совсем. Не все функции можно безопасно вклеивать в запросы.

    GZ>> А иногда, и даже чаще, такое мега-запрос значительно эффективнее чем куча запросов.

    VD>Это твое умозрительное заключение. На практие все совсем не так.
    Когда-как. Поисковые запросы лучше проводить именно по базе данных, так как используется огромный массив данных. Выгружать и актуализировать его — сипука. Что касается самих запросов, то иногда действительно высокие накладные расходы на join. Иногда наоборот, один предикат отсекает все лишние записи и все грузится молниеносно.

    GZ>> Через представления часто получается такие-же здоровые запросы,

    VD>Значит неграмоно создаются эти самые представления.
    Не-а. Представления мало решают задачу за счет того что они реляционны. А приложения работают уже с логической моделью бизнес-объектов.

    GZ>> и иногда не очень эффективные.

    VD>Они и в монструозном виде будут такими же не эффективными.

    VD>Однако ты заговорил об оптимизации. Оптимизация в большинстве случаев ухудшает декомпозицию и вообще качество кода.

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

    VD>Но оптимизация требуется даего не везде.

    Безусловно. Правда нужна консистентность модели. То есть доступность и непротиворечивость всех данных, которая данная модель содержит.
    VD>И как и в обычном программировании не стоит жертвоват качеством кода везде или заниматься предварительной оптимизацией. Лучше сначала написать качественный код, а уж потом его уродовать оптимизацией.
    Тут есть несколько подходов. Но в основом проблема в том, что очень трудно прогнозировать не имея реальных данных. Эффективность зависит не только от количества данных, но также и от их качества. Поэтому я все-таки предпочитаю сначало делать эвристически, поскольку данные, во первых, не всегда доступны, а во вторых, не всегда существуют(появляются только в процессе эксплуатации).

    VD>К тому же СУБД предоставляют средства оптимизации не уродующие абстракции.

    VD>Среди них есть хинты,
    Ни в коем случае. Если говорить о подсказках оптимизатору, то я давно понял что пользовать их ни в коем случае нельзя. Оптимизатор во первых умнее. Во вторых, при малейшей переделке начинает тормозить. И в третьих, при накачке данных, правильное решение может измениться.
    Это как раз то, о чем ты говоришь позднее — подшаманить запрос.
    VD>индексированные представления,
    Слишком много ограничений
    VD>триггеры и т.п.
    Ага. Если не говорить об instead of — то это очень помогает при сохранении. Но не очень при чтении(что в задачах встречается гораздо чаще).
    VD>Они дают отличный эффект и в первую очередь задействовать нужно их, а не пытаться подшаманить запрос так чтобы он выполнялся подругому. Надо понимать, что подшаманеный запрос может в любую минуту начать тормозить. Не говоря уже о том, что его сложно поддерживать и вообще не ясно что будет сним на следующей версии SQL-сервера или на другой БД.

    GZ>> И функции поддерживают далеко не все БД.

    VD>Да почти все что заслуживают уважения. А в нашем случае вообще речь шла о MS SQL.
    А Oracle — уже не заслуживает уважения?
    Если говорить о stored procedure, то безусловно это очень полезно, поскольку скрывают от нас внутренний sql запрос(ы). Только тогда sql для пользователя вообще не нужен, и это пререгатива базоведа. Поэтому, говоря о SQL нам следует говорить о запросах внутри хранимок.

    VD>Ну, да в любом случае представления есть везде. И не воспользоваться ими — грех.

    GZ>>Собственно поэтому, лично мне, и интеллегенс вообще не интересен и даже читабельность. Эффективность для меня — значительно важней.
    VD>Что я могу сказать?... Очень плохо.
    VD>Эффективности нужно добиваться алгоритмически. Это всегда дает самый большой эффект. А замазки и подмазки — это всегда шаг в ад на земле.
    Современная СУБД — это набор автоматизированных высокоэффективных построителей алгоритмов. Но поскольку существуют задачи которые не могут быть решены автоматизированно, то тут уже идут подпорки (ну например в виде темповых таблиц, денормализации и т.д.). Основной выйгрыш в дает модель, код вторичен. И сильно нормализованная модель тянет за собой большие и ветвистые запросы.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[16]: Язык запросов: from в начале
    От: GlebZ Россия  
    Дата: 04.01.06 21:37
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Тогда странно, что ты влез в эту ветку. Тут как раз о невозможности его реализации для SQL-я говорится. Причем исключительно чтобы оправдать перестановку раздела select в LinQ-е.

    Именно в перестановку я и влез.

    GZ>>Ну наконец-то. Это уже ближе к теме. Вопрос в том, что при данном построении AST относительно семантики(интерпретации) атрибуты не применимы.

    VD>Что? Поясни свою мысль по подрьбнее, плиз.
    Модель выполнения запроса LINQ — это в принципе его компиляция. Почему компилячится выражение языка с ведущим from в С# вполне понятно. Таков С#. Будем говорить о самой компиляции выражения запроса в выражения C#. Кнут выделил два типа аттрибутов для построения семантического дерева вывода. Унаследованный — это когда аттрибут зависит от содержимого его подветок(например аттрибут говорящий о том что он находится в поле from), и синтезированный — это когда он определяется по предыдущим аттрибутам(типы переменных — синтезированные аттрибуты). В данном случае, при парсинге селекта, мы не можем сказать ничего о семантике его полей. Ничего из этого еще не создано. И положить в дерево вывода практически нечего, так как ничего неизвестно. То, что из себя представляет select, какие у него типы, и каким образом нам его компилячить мы даже и предполагать не можем(собственно подобных аттрибутов у Кнута и не описано). Но самое поганое, что теперь полностью всю информацию во from мы тоже не получим. Потому как в выражении "select a.b, b.f from a" мы не можем получить то, что объект b.f вообще не существует. Только через другой проход мы сможем это уточнить и довести до ошибки. Смею предположить, что разработчики компилятора не могли пойти на второй проход (ты по реализации компилятора С# знаешь больше моего, если что уточни).
    Ну ессно примечу что данный вопрос я изучал только в той степени которая мне пригождалась, и возможно что-то есть большее и все это мое IMHO.


    VD>Я имел в виду "показать где я говорил, что синтаксис и семантика — это одно и тоже".

    Ты подразумевал что с помощью AST дерева можно выполнить все операции. У формализованного семантического дерева могут быть совершенно отличные взаимосвязи.

    VD>>>Может быть ты пояснишь почему ты прицепился к этому вопросу? Что плохого в отработке семантики по AST?

    GZ>>Она не подходит ни для интерпретации, ни для оптимизации. А самое главное, оно не подошло под мою задачу.
    VD>Это не правда. И интерпретацию, и поптимизацию на AST делать можно. Но ты уходишь от темы. Еще раз повторяю вопрос:
    VD>Что плохого в отработке семантики по AST?
    Уже написал сверху.
    VD>И еще раз напоминаю, что речь в этой подветке идет о постраении интелисенса для SQL.
    Ну так уже все описали. При построении select информация практически равна нулю.
    Для справки. У меня в районе 500 таблиц и вьюх на текущем проекте. Количество процедур еще больше. А они еще начинаются на по одинаковому на MSSQL. В Oracle хоть хорошо — пакаджи есть.

    GZ>>Честно говоря я не имел ввиду именно intellisence. Но эти проблемы как раз связаны. И связаны именно порядком операторов.

    VD>Я вообще не понял что ты имел в виду. Ты влез в разговор об интелисенсе и ушел куда-то в даль. И я даже не могу понять цили нашего разговора. О чем мы, Сэр?
    А то что intellisence выполняет задачу построения запроса по доступной информации о семантике.

    GZ>>Насчет качественно, то кроме качественной деманструхи ничего не увидел.

    VD>А ты попробуй.
    Да уже пробовал.

    GZ>> Он мало отличается от других intellisence.

    VD>Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе. А ты полез защищать эту мягко говоря натянутое утверждение.
    Не думаю что он такое утверждал. Он утверждал — качественный интелесенст невозможен.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 05.01.06 13:47
    Оценка:
    Здравствуйте, Merle, Вы писали:

    VD>>И все же попросил бы ссылку, на то что я по твоему мнению пропустил.

    M>Легко. Но только после того как ты ответишь на один простой вопрос: Почему я должен в очередной раз тыкать тебя в те места, которые ты пропустил?

    Потому-что ты меня (а не я тебя) в чем-то пыташся обвинить. Пойдешь искать ссылочки и глядишь сам носом тыкнешся.

    VD>>Или ты не утверждал что однобугвенные алиасы для таблиц — это нармально?

    M>Утверждал, только я нигде не утверждал, что однобуквенные алиасы это всегда нормально. Чувствуешь разницу?

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

    VD>>Ваня, ты открытым текстом говорил о нормальности однобуквенных и полностью бессмысленных алиасов и ставил минус на сообщении в котором высказывалась всего одна мысль "сложные запросы нужно подвергать декомпозиции".

    M>Передергиваешь.

    Нисколько.

    M> Я нигде не говорил открытым текстом, что однобуквенные алиасы всегда совершенно нормально,


    А где я употреблял слово всгда? Читай внимательнее. Всегда — это конечно же уже полная клиника.

    M>и на чем я ставил минус я написал ответом раньше. Или ты это опять пропустил?


    Начнем с того, что этот ответ я писал до твоего объяснения. А закочим тем, что твое объяснение тоже показательно в свете обсуждаемого вопроса.

    VD>> Что же тут можно знать хуже тебя?

    M>Твоя самоуверенность тебя подводит.

    Зато тебе она всегда к лицу.

    VD>>Если ты неверно выразился, то скажи об этом.

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

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

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

    VD>> И не нужно мне рассказывать сказки, что я что-то где-то пропустил.

    M>Увы, но это не сказки.

    Ссылок нет, так что будетм считать это утверждение головсловным и проигнорируем его.

    VD>> Хотя я тоже как-то не вижу приципиальности в данном вопросе. Может пояснишь, что я тут пропустил?

    M>Ты пропустил Ромин вариант SQL-ного интеллисенса, который невозможен, если в запросе используются алиасы. Собственно с этого сообщения и зашел разговор про алиасы вообще.

    Я не пропускал Ромин вариант. Просто с Ромой я тоже не вполне согласен в данном вопросе. Ни алиасы не мешают парсингу, ни плохого в них в общем-то ничего нет, если у них разумные имена.

    VD>>Вот только не не вижу связи между этим и меспоположением select-а.

    M>Потому что читаешь по диагонали.

    Не. Потому что у кого-то аргументация притянута за уши. Мне достаточно моиз познаний в теории парсинга, граматике SQL и наличии вполне себе неплохо работающих реализаций автодополнения, чтобы не принимать в рассчет высказывания противоречащие этим фактам.

    VD>>И минусы без аргументации тут конечно выглядят очень достойны.

    M>Сначала свои безаргументные минусы посчитай, потом поговорим..

    Я сатавлю минус когда полностью не согласен со всем сказанным в сообщении. Или поясняю после минуса, с чем собственно не согласен. Это опчень помогает пониманию.

    VD>>Ненадо меня посылать так долеко.

    M>А что еще с тобой делать?

    А разве обязательно со мной что-то делать? Я же ведь с тобой ничего плохого делать не пытаюсь.

    VD>> Если ты хочшь доказать обратное, то потрудись дать ссылки.

    M>Как только ты даш ответ, зачем я должен читать топик вместо тебя.

    Моя версия — я читал его лучше тебя, а твои обвинения в мой адрес голословны.

    M>Или у тебя принцип такой — ты не воспринимаешь аргумент, если его повторили менее 8 раз?


    Нет. Я не воспримаю на веру.

    VD>>Если нет, то прекрати заниматься внушением и навешиванием ярлыков.

    M>"Бред" и "полая фигня" — это твои ярлыки, я же не навесил ни одного.

    Я в разговоре с тобой исползовал эти слова? Это такая попытка подменить предмет разговора?

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

    VD>>Задумайся над тем, что ты сам мог неверно что-то понять.

    M>Например, что?

    Например, все. Ну, там, что не очень хорошо использовать однобуквенные идентификаторы в огромных запросах, ну, и сами огромные запросы...
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 07.01.06 21:39
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе.


    Гон. Потрудись перечитать что я утверждал, прежде чем делать подобные заявления.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[17]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 00:31
    Оценка: -1
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе.


    AVK>Гон. Потрудись перечитать что я утверждал, прежде чем делать подобные заявления.


    Re[4]: Чего не хватает в C#?
    Автор: AndrewVK
    Дата: 18.12.05

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    Так что конечно "гон", но с твоей стороны.

    ЗЫ

    На извинения не недеюсь. Подобного прицедента еще небыло. Ну, хоть отмазку услышать.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Язык запросов: from в начале
    От: Дьяченко Александр Россия  
    Дата: 08.01.06 03:34
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, AndrewVK, Вы писали:


    VD>>>Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе.


    AVK>>Гон. Потрудись перечитать что я утверждал, прежде чем делать подобные заявления.


    VD>Re[4]: Чего не хватает в C#?
    Автор: AndrewVK
    Дата: 18.12.05

    VD>

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    VD>Так что конечно "гон", но с твоей стороны.


    VD>ЗЫ


    VD>На извинения не недеюсь. Подобного прицедента еще небыло. Ну, хоть отмазку услышать.


    А ты не находимшь что фразы 1 и 2 по смыслу сильно отличаются (ключевое отличие я выделил жирным)?

    1 Твоя

    Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе.

    2 АВК

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    PS Извеняйте что встреваю в ваши разборки
    ... << RSDN@Home 1.2.0 alpha rev. 618>>
    Re[18]: Язык запросов: from в начале
    От: vdimas Россия  
    Дата: 08.01.06 09:50
    Оценка: -1
    Здравствуйте, VladD2, Вы писали:

    VD>И вообще, я не очень понимаю природу твоего писимизма. Любой язык обладающий средствами декомпозиции позволяет ее родимую делать. SQL обладает такими средствами как VIEW и пользовательские функции (в большинстве диалектов). Неуже ли тебя нужно обучать как с их помощью монструозный запрос можно разбить на несколько относительно простых?


    Только очень малую часть запросов можно декомпозировать предложенным способом. Причем, наиболее простую по характеру часть всех SQL-запросов, где и без композиции не заблудишься. Тем не менее в большинстве нормальных проектов эта часть прекрасно декомпозирована и без наших советов. В подавляющем большинстве "трудности" SQL-запросов состоят в сложных связях "внешних" и "внутренних" выражений. И именно эти связи не дают провести декомпозицию.
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 13:11
    Оценка: -1
    Здравствуйте, Дьяченко Александр, Вы писали:

    Оверквотить то зачем?

    ДА>А ты не находимшь что фразы 1 и 2 по смыслу сильно отличаются (ключевое отличие я выделил жирным)?


    ДА>1 Твоя

    ДА>

    Типа студийного? Гы-гы. О том и речь! АВК утверждал, что ителисенст для SQL невозможен в приципе.

    ДА>2 АВК
    ДА>

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


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

    ЗЫ

    Еще раз процитирую слова GlebZ:

    Насчет качественно, то кроме качественной деманструхи ничего не увидел. Он мало отличается от других intellisence.


    Над чем я и от души посмеялся, так как если интелисенс в http://www.promptsql.com . мало чем отличается от других, а значит и от судийного чье качество вряд ли вызвает нарекания, то он априори нормальный. А именно возможность создания этого и отрицает АВК, обосновывая это какиеми-то не поддающемися описанию "очень серьезными проблемами".

    ЗЗЫ

    Я вообще не понимаю как можно отрицать столь очевидные вещи! Продукт можно скачать и попробовать. Это не теоритические размышления. Это реально существующий продукт который с успехом можно использовать на практике!

    Что характерно никакой конкретной его критики нет. Есть банальное отрицание фактов. В общем, тятор абсурда.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 08.01.06 14:36
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>Гон. Потрудись перечитать что я утверждал, прежде чем делать подобные заявления.


    VD>Re[4]: Чего не хватает в C#?
    Автор: AndrewVK
    Дата: 18.12.05

    VD>

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


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

    VD>На извинения не недеюсь. Подобного прицедента еще небыло. Ну, хоть отмазку услышать.


    Пока что жду извинений от тебя.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[13]: Язык запросов: from в начале
    От: retn нет
    Дата: 08.01.06 15:03
    Оценка: +1
    Здравствуйте, Merle, Вы писали:

    M>Здравствуйте, adontz, Вы писали:


    A>>Я конечно не гуру БД, но даже я первое к чему себя приучил это писать SELECT, WHERE, FROM, GROUP BY, ORDER BY с новой строки, а если запрос большой то и с пропуском строки.

    M>Молодец. Только читать при этом приходится сначала FROM, потом ниже, а потом возвращаться глазами на верх или даже прокручивать, что совсем не удобно.

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

    Но вот насчет IntelliSense тут есть два момента
    1. Реализовать это дело действительно так, что бы помогало, а не мешало(и было intelli а не просто sense).
    2. Менять или не менять при этом порядок слов в предложениях запроса.
    и мне кажется не надо их мешать.

    То что для полезного подсказывание надо иметь "умный" список чего предложить это понятно,
    поэтому получение информации о том откуда мы будем брать(сервер, база, таблица) и под какими алиасами(с алиасами точно придется возвращаться к селект секции и править её) предпочтительнее. А иначе это будет confusesense а не intelli.

    Можно пойти путем, когда вначале пишем откуда, затем имея таблицы(алиасы), поля, intelli подсказываем что и почем в остальных секциях запроса.
    Т.е. перекраиваем "веками" сложившийся конструктив предложений SQL запросов.

    И второй путь, не трогаем синтаксис, т.е. например, так, если написан select всплывает окошко(в стиле подсказок) и предлагает оформить
    откуда секцию(при этом в нем тоже может работать IntelliSense). После выяснения откуда, IDE пишет откуда секцию и перебрасывает нас к selecty
    select [курсор находится здесь]
    from tablea ta inner join tableb tb on ta.[id] = tb.[id]

    Или вообще можно вызывать какай-нибудь простой но толковый query builder.
    Т.е. красиво решить проблему latedefinition не трогая при этом структуру select предложения.

    И наверное найдется много людей которым привычнее читать сначала откуда, затем что,
    а так же много будет тех(наверное даже больше первых) кому категорически не понравится перекройка предложений.
    Поэтому наверное вернее не менять порядок секций в предложении селект(хотя мне нравится вариант с from вначале).
    (Может проголосуем по этому поводу?)


    К вопросу о необходимости синтаксической похожести ЯП и языка общения.

    Одна из целей языка высокого уровня — "дружественность"(в разумных пределах).
    И похожесть синтаксиса и лексики ЯП с ЯО — элементы "дружественности".
    Т.е. синтаксическая дружественность и лексическая дружественность(она выше синтаксической).
    И думаю, порой приходится жертвовать этой дружественностью ради помощи компилятору или ради иных целей связаных с концепцией.
    Тут опять кому что важнее и ближе. Кому то какой-то ФЯ(Хаскел тот же) с его синтаксисом ближе и он просто балдеет от его синтаксиса.
    Ну а кто-то никогда не полюбит Лисп.
    Наверное можно даже выделить группы по ориентированости(как синтаксической так и лексической) ЯП.
    Т.е. например для химика было бы идеально если бы он написав формулу увидел на экране результат эксперимента,
    для математика своё как и для физика-ядерщика.
    Так что думаю для "общих" ЯП имеет смысл следовать похожести с синтаксисом ЯО(хотя одного языка — англ).
    Вопрос чем мы готовы за что платить, я за качественный Intellisense отсутствием синтаксической похожести легко, я не домохозяйка.(Хотя наверное кому как)
    Вот только вопрос совместимости не должен страдать.
    И наверное именно синтаксическая строгость английского языка роднит его с ЯП.
    ... << RSDN@Home 1.2.0 alpha rev. 627>>
    Re[20]: Язык запросов: from в начале
    От: Дьяченко Александр Россия  
    Дата: 08.01.06 15:05
    Оценка: 18 (1)
    Здравствуйте, VladD2, Вы писали:

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


    Нормальным = достаточно близким к идеалу что бы с ним приятно было работать

    Забегая вперед говорю что прогу не скачивал, только посмотрел демку в которой у всех запросов между select и from стоит *. Если судить по демке то он лучше чем я думал, но хуже чем мечтал . Спорить с тем что для части от from и далее построить интелисенс можно, основные споры были посвящены части между select и from, но поскольку ты не раз говорил что тебе не напряжно поставить звездочку а потом к ней вернуться, то этот экземпляр интелисенса тебя более чем устраивает. Меня эта ситуация напрягает посему я (да видимо и не только я но и AndrewVK) не считаю его идеалом хотя еще раз повторюсь он мне понравился.

    Я прекрасно понимаю что то каким бы я хотел его видеть (то есть полностью линейным без простовления звездочек и матаний обратно) его сделать нельзя потому что информацию о том что я напишу после from ему взять еще неоткуда.

    Вы уже переломали где-то тут недалеко пару рощиц на копья на тему порядка следования слов (конструкций) в LinQ (C# 3.0) при котором можно сделать интелисенс гораздо ближе к идеалу чем он находиться сейчас, а по сему предлагаю заканчивать этот кусок филосовской беседы (Особенно в виду субъективности определения нормальный)

    VD>ЗЫ


    VD>Над чем я и от души посмеялся, так как если интелисенс в http://www.promptsql.com . мало чем отличается от других, а значит и от судийного чье качество вряд ли вызвает нарекания, то он априори нормальный. А именно возможность создания этого и отрицает АВК, обосновывая это какиеми-то не поддающемися описанию "очень серьезными проблемами".


    Сильно подозреваю что имелось в виду он мало отличается от других интелисенсов для SQL.

    VD>ЗЗЫ


    VD>Я вообще не понимаю как можно отрицать столь очевидные вещи! Продукт можно скачать и попробовать. Это не теоритические размышления. Это реально существующий продукт который с успехом можно использовать на практике!

    VD>Что характерно никакой конкретной его критики нет. Есть банальное отрицание фактов. В общем, тятор абсурда.

    Я разве спорил что его можно применять на практике? На практике можно применять многое... И то что этот продукт намного лучше чем блокнот, да и то что я видел до этого я полностью согласен .
    ... << RSDN@Home 1.2.0 alpha rev. 618>>
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 15:21
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Re[4]: Чего не хватает в C#?
    Автор: AndrewVK
    Дата: 18.12.05

    VD>>

    Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    AVK>Я просил перечитать, а не скопировать. Для облегчения задачи нужное я выделил.


    Ну, вот и отмазался. Ну, почти. Осталось объяснить, что же такого не нормального в PromptSql. Ну, или дать новую трактовку слову "нормальный". Последнее, естественно, проще.

    VD>>На извинения не недеюсь. Подобного прицедента еще небыло. Ну, хоть отмазку услышать.


    AVK>Пока что жду извинений от тебя.


    Нда... Нет слов.

    ЗЫ

    Может быть все же признашь свою не правоту, или потрудишся дать хоть какое-то обоснование своему мнению о невомзможности "Нормальный intellisence в SQL невозможен в принципе"?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 15:45
    Оценка: -2
    Здравствуйте, Дьяченко Александр, Вы писали:

    ДА>Нормальным = достаточно близким к идеалу что бы с ним приятно было работать


    Для начинающих лингвистов... "достаточно близким к идеалу" — это "почти идеальный", а не "номральный".

    ДА>Забегая вперед говорю что прогу не скачивал,


    Как это похоже на классические слова "сам я стихов автора не читал, но как и весь советский народ осуждаю...".

    ДА>только посмотрел демку в которой у всех запросов между select и from стоит *.


    А что это мешает вводу? Я тебе более того скажу. Эти ребята реализовали довольно забавную вещь. Если после оформления запроса со звездочкой ты решил вручную задать список полей, то тебе достаточно поставить курсор за звездочку и нажать Tab. При этом она превращается в список доступных полей. Остается только удалить лишние.

    ДА> Если судить по демке то он лучше чем я думал, но хуже чем мечтал .


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

    ДА>Спорить с тем что для части от from и далее построить интелисенс можно, основные споры были посвящены части между select и from, но поскольку ты не раз говорил что тебе не напряжно поставить звездочку а потом к ней вернуться, то этот экземпляр интелисенса тебя более чем устраивает. Меня эта ситуация напрягает


    И чем же она напрягает то? Ты и в обычных языках программирования не можешь делать многие вещи последовательно. Почему тебя это не напрягает? Ну, например, почему не напрягает, то что перед тем как объявить переменную нужно пофти и объявить ее тип?

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

    ДА> посему я (да видимо и не только я но и AndrewVK) не считаю его идеалом хотя еще раз повторюсь он мне понравился.


    А об идеале разговора и не было. Я уже устал повторять, что речь идет о принципиальной возможности или не возможности создать интелисенс. Я лично виже, что кто-то пытается сделать хорошую мину при плохой игре. Сначала сделал опрометчивое заявление, а потом стремится сделать вид, что он совоеобразно интерпретирует слова "нормальный". Это в свою очередь приводит к абсурду вроде не признания очевидных фактов.

    ДА>Я прекрасно понимаю что то каким бы я хотел его видеть (то есть полностью линейным без простовления звездочек и матаний обратно) его сделать нельзя потому что информацию о том что я напишу после from ему взять еще неоткуда.


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

    ДА>Вы уже переломали где-то тут недалеко пару рощиц на копья на тему порядка следования слов (конструкций) в LinQ (C# 3.0) при котором можно сделать интелисенс гораздо ближе к идеалу чем он находиться сейчас, а по сему предлагаю заканчивать этот кусок филосовской беседы (Особенно в виду субъективности определения нормальный)


    Я конечно все понимаю. И при огромном желании можно предраться к любой мелочи и объявить ненормальным все что угодно. Но при этом надо быть последовательным. А то ведь почему-то ввод forech-а почему-то не напрягает, хотя в нем тоже сначало приходится вписввать, что, а потом откуда.

    ДА>Сильно подозреваю что имелось в виду он мало отличается от других интелисенсов для SQL.


    Если, то так. То сильно подозреваю, что это очередная попытка выдать желаемое (причем явно от вредности) за действительное. Ведь достоточно скачать и попробовать.

    ДА>Я разве спорил что его можно применять на практике? На практике можно применять многое... И то что этот продукт намного лучше чем блокнот, да и то что я видел до этого я полностью согласен .


    В общем, я могу подытожить все это дело и заключить следующее.

    Комплит/инетелисенс для SQL более чем реален. Нормальный, удобнй комплит резко упрощающий работу программиста. Никаких физический проблем необходимость пропускать стадию перечисления полей при риеальной работе не вызвает. И упавать на это не чесно.

    Никаких "очень серьезных проблем" в создании комплита нет. Это все выдумки.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 08.01.06 15:54
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Потому-что ты меня (а не я тебя) в чем-то пыташся обвинить.

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

    VD>Достаточно утверждения, что это нормально.

    Достаточно для чего?
    В моем понимании "нормально", означает, что есть некоторые ситуации, когда можно использовать однобуквенный алиас.
    Ты с этим споришь, значит потвоему алиас никогда не должен быть однобуквенным — байта ради, меня это мало волнует, как я уже писал — не о том разговор.

    VD>Нисколько.

    Еще как.

    VD>Начнем с того, что этот ответ я писал до твоего объяснения.

    Начнем с того, что это и есть причина ругани с тобой. Ты не утруждаешь себя прочтением сообщения полностью, прежде чем начать на него отвечать — объяснение было ровно в том сообщении на которое ты отвечал.

    VD>Зато тебе она всегда к лицу.

    Время от времени...

    VD> Мы вроде в твоих высказываниях разбирались.

    Да ладно? Я что-то вот все больше в твоих никак разобраться немогу.

    VD> И твои апелляции к моей невнимательности и т.п. ну, никак не делают тебя правым, а меня нет.

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

    VD> Я прекрасно понял твою позицию по всем трем вопросам

    Сомневаюсь.

    VD>Я не пропускал Ромин вариант.

    Ну значит ты его не сразу осознал.

    VD>Не. Потому что у кого-то аргументация притянута за уши.

    Для тебя любая аргументация притянута за уши, если она не совпадает с твоей (кстати о ярлыках).

    VD> Мне достаточно моиз познаний в теории парсинга, граматике SQL и наличии вполне себе неплохо работающих реализаций автодополнения, чтобы не принимать в рассчет высказывания противоречащие этим фактам.

    Пойми простую вешь. Все твои гигантские знания в теории парсинга, грамматике SQL, цене огурцов на стамбульском базаре на прошлой неделе и курса бакса относительно уругвайского песо — не изменят того печального факта, что пользоваться любым современным sql-ным интелисенсом неудобно.

    VD>Я сатавлю минус когда полностью не согласен со всем сказанным в сообщении.

    Именно так я и сделал.

    VD> Или поясняю после минуса, с чем собственно не согласен. Это опчень помогает пониманию.

    Видишь ли Влад. Твое сообщение, конечно, можно истолковать двояко — как абстрактную оду декомпозиции и как применимость оной декомпозиции к SQL-ю вообще и T-SQL-ю в частности. Однако ввиду того, что речь в той подветке ветке шла сугубо о SQL-е и даже о конкретном запросе, то для того воспринять нескогласие с твоим высказыванием как несогласие с принципами декомпозиции вообще — надо специально этого хотеть. Поэтому твои придирки в этом вопросе я воспринимаю как однознаное передергивание.

    VD>Нет. Я не воспримаю на веру.

    Ну так проверь.

    M>>"Бред" и "полая фигня" — это твои ярлыки, я же не навесил ни одного.

    VD>Я в разговоре с тобой исползовал эти слова?
    Да.

    VD>Это такая попытка подменить предмет разговора?



    VD> Ты вместо того чтобы спорить с моими словами, противоречащеми твоим,

    Именно с этим я и спорю.

    VD> Ну, там, что не очень хорошо использовать однобуквенные идентификаторы в огромных запросах,

    Найди пожалуйста место, где я говорил про огромные запросы и однобуквенные идентификаторы в оных.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[20]: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 08.01.06 16:00
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>потрудишся дать хоть какое-то обоснование своему мнению о невомзможности "Нормальный intellisence в SQL невозможен в принципе"?

    Тебе уже давали, не раз, и не только AVK. Но ты все-таки либо не читаешь, либо не воспринимаешь что прочитал.
    ... [RSDN@Home 1.2.0 alpha rev. 619]
    Мы уже победили, просто это еще не так заметно...
    Re[22]: Язык запросов: from в начале
    От: Дьяченко Александр Россия  
    Дата: 08.01.06 16:03
    Оценка:
    Вобщем ИТОГО:

    1. Под утверждением "Интелисенс для SQL сделать можно" — я подписываюсь

    2. Под утверждением "Можно сделать такой что пользоваться им будет намного удобней чем блакнотом" — я тоже подписываюсь

    3. Под утверждением "Сложность реализации идеального интелисенса для SQL приближается к бесконечности" (идеального так как я его понимаю) — я подписыавюсь

    Давай лучше пива попьем :
    ... << RSDN@Home 1.2.0 alpha rev. 618>>
    Re[20]: Чего не хватает в C#?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 08.01.06 18:31
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ну, вот и отмазался. Ну, почти. Осталось объяснить, что же такого не нормального в PromptSql.


    Он не способен делать то, что описал Синклер.

    VD>>>На извинения не недеюсь. Подобного прицедента еще небыло. Ну, хоть отмазку услышать.


    AVK>>Пока что жду извинений от тебя.


    VD>Нда... Нет слов.


    Именно что. Переврать мои слова и умудриться еще и на меня стрелки перевести, это сильно.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[21]: Чего не хватает в C#?
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.01.06 18:45
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

    VD>>>>На извинения не недеюсь. Подобного прицедента еще небыло. Ну, хоть отмазку услышать.

    AVK>>>Пока что жду извинений от тебя.
    VD>>Нда... Нет слов.
    AVK>Именно что. Переврать мои слова и умудриться еще и на меня стрелки перевести, это сильно.

    Я думал вы меня не любите, а вы оказывается по жизни такие
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 20:35
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Только очень малую часть запросов можно декомпозировать предложенным способом. Причем, наиболее простую по характеру часть всех SQL-запросов, где и без композиции не заблудишься. Тем не менее в большинстве нормальных проектов эта часть прекрасно декомпозирована и без наших советов. В подавляющем большинстве "трудности" SQL-запросов состоят в сложных связях "внешних" и "внутренних" выражений. И именно эти связи не дают провести декомпозицию.



    SQL это такой же декларативный язык как любой, например, функциональный. И как и любой другой язык он допускает декомпозицию. Клинические случае вроде Эксеса конечно встречаются. Но и он кое что позволяет.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 20:35
    Оценка:
    Здравствуйте, Дьяченко Александр, Вы писали:

    ДА>3. Под утверждением "Сложность реализации идеального интелисенса для SQL приближается к бесконечности" (идеального так как я его понимаю) — я подписыавюсь


    Вот с этия я не согласен. В чем проблема то?

    ДА>Давай лучше пива попьем :

    ДА>

    С этим тоже. Ну, его на фиг пиво. Особенно в морозы. Лучше чего по крепче.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 20:35
    Оценка:
    Здравствуйте, Merle, Вы писали:

    VD>>потрудишся дать хоть какое-то обоснование своему мнению о невомзможности "Нормальный intellisence в SQL невозможен в принципе"?

    M>Тебе уже давали, не раз, и не только AVK. Но ты все-таки либо не читаешь, либо не воспринимаешь что прочитал.

    Так ты моещь поянить, что ненормального в интелесенсе для SQL? Что поставить звездочку в начале работы — это непреодолимое препятсвие?
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Чего не хватает в C#?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.01.06 20:35
    Оценка: -2
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Ну, вот и отмазался. Ну, почти. Осталось объяснить, что же такого не нормального в PromptSql.


    AVK>Он не способен делать то, что описал Синклер.


    Синклер много описывал. Что конкретно он не позволяет сделать?

    VD>>Нда... Нет слов.


    AVK>Именно что. Переврать мои слова и умудриться еще и на меня стрелки перевести, это сильно.


    Ты лучше бы со своими словами определился бы. А то выглядит это все ой как не красиво. Делашь громкие заявления, а когда их цитируют в кусты наровишь уйти.
    ... << RSDN@Home 1.2.0 alpha rev. 620>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Чего не хватает в C#?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 08.01.06 20:40
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    Все, мне надоело. Продолжай без меня.
    ... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
    AVK Blog
    Re[24]: Язык запросов: from в начале
    От: Дьяченко Александр Россия  
    Дата: 09.01.06 00:39
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Дьяченко Александр, Вы писали:


    ДА>>3. Под утверждением "Сложность реализации идеального интелисенса для SQL приближается к бесконечности" (идеального так как я его понимаю) — я подписыавюсь


    VD>Вот с этия я не согласен. В чем проблема то?


    Вобщем хватит воевать черт с ним с идеальным интелисенсом все равно я SQL не занимаюсь столько чтоб это было критично .

    ДА>>Давай лучше пива попьем :

    ДА>>

    VD>С этим тоже. Ну, его на фиг пиво. Особенно в морозы. Лучше чего по крепче.


    Ну у нас не так и холодно, особенно в квартире . Плюс покрепче это что — водка? Ну ее нафигг я ее не потребляю. Вот если вина хорошего это можно .
    ... << RSDN@Home 1.2.0 alpha rev. 627>>
    Re: Язык запросов: from в начале
    От: Тычеблин Китай  
    Дата: 09.01.06 09:05
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Здравствуйте, ie, Вы писали:


    ie>>IntelliSense — вряд ли.


    AVK>Не вряд ли, а так и есть. Информация из первых рук.


    ie>>Почему-то с foreach таких заморочек небыло, а тут на тебе. А в для редактора эти проблемы должны решаться с помощью код-сниппетов, а не с помощью дескриминации читаемости выражений.


    AVK>Нормальный intellisence в SQL невозможен в принципе, это очень серьезная проблема. И никакие сниппеты не спасают.


    Под конкретно данный случай есть такое предложение, немного изменить сам вид интеллисенса.

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

    на первом уровне названия таблицы, на втором раскрывается список её полей. при выборе поля одновременно, можно дописывать все то, что должно быть после from
    Re[20]: Язык запросов: from в начале
    От: vdimas Россия  
    Дата: 09.01.06 11:14
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, vdimas, Вы писали:


    V>>Только очень малую часть запросов можно декомпозировать предложенным способом. Причем, наиболее простую по характеру часть всех SQL-запросов, где и без композиции не заблудишься. Тем не менее в большинстве нормальных проектов эта часть прекрасно декомпозирована и без наших советов. В подавляющем большинстве "трудности" SQL-запросов состоят в сложных связях "внешних" и "внутренних" выражений. И именно эти связи не дают провести декомпозицию.



    VD>SQL это такой же декларативный язык как любой, например, функциональный. И как и любой другой язык он допускает декомпозицию. Клинические случае вроде Эксеса конечно встречаются. Но и он кое что позволяет.


    Ты так и не понял о чем речь. Реши задачку Синклера из этой подветки, она очень простая. Ключевой момент в своем пред. сообщении я выделил. В запросе с перекрестными связями декомпозиция невозможна. И твои минусы — не аргумент
    Re[21]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.01.06 12:37
    Оценка:
    Здравствуйте, vdimas, Вы писали:


    V>Ты так и не понял о чем речь. Реши задачку Синклера из этой подветки, она очень простая. Ключевой момент в своем пред. сообщении я выделил. В запросе с перекрестными связями декомпозиция невозможна. И твои минусы — не аргумент


    Что значит "с перекресными связями" и чем может помещать выделению подзапроса?
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.01.06 12:37
    Оценка: +2
    Здравствуйте, Тычеблин, Вы писали:

    Т>на первом уровне названия таблицы, на втором раскрывается список её полей. при выборе поля одновременно, можно дописывать все то, что должно быть после from


    Более того. Замену имени таблицы на алиас можно осуществлять отдельной процедурой рефакторинга.
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Чего не хватает в C#?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.01.06 11:35
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я думал вы меня не любите, а вы оказывается по жизни такие

    Да ты что! В сети мы еще очень сильно фильтруем э-э-э... беседу. В RL дискуссии проходят намного жоще
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[3]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.01.06 11:35
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Тычеблин, Вы писали:


    Т>>на первом уровне названия таблицы, на втором раскрывается список её полей. при выборе поля одновременно, можно дописывать все то, что должно быть после from


    VD>Более того. Замену имени таблицы на алиас можно осуществлять отдельной процедурой рефакторинга.

    Кроме случаев, когда одна табличка встречается в запросе более чем однажды
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[4]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.01.06 11:44
    Оценка: -1
    Здравствуйте, Sinclair, Вы писали:

    VD>>Более того. Замену имени таблицы на алиас можно осуществлять отдельной процедурой рефакторинга.

    S>Кроме случаев, когда одна табличка встречается в запросе более чем однажды

    Спокойно. Таких случаев в корректном запросе быть не может. Точнее всегда есть контекст в рамках которого можно выделить таблицу и точно понять к чему она относится. Это как имена переменных в ИЯ. Если программа кооректная, то рефакторер может определить где она определена и все ее вхождения.
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Язык запросов: from в начале
    От: SteMage Россия  
    Дата: 10.01.06 11:53
    Оценка:
    Здравствуйте, Merle, Вы писали:

    M>Здравствуйте, Anton Batenev, Вы писали:


    AB>>Одно дело цикл, а другое дело имена таблиц.

    M>Совершенно однофигственное.

    AB>>Алиасы, конечно же, не однобуквенные, но исправить недолго.

    M>Вот ты в другую сторону исправь. Напиши полные имена таблиц вместо алиасов и посмотри как отлично это будет читаться.

    AB>> Использование однобуквенных алиасов мне кажется крайне нецелесообразным.

    M>Одно-вух-трех — не принципиально, лишь бы не полные имена таблиц, если те не автогенеренные. На моей практике, от написания полных имен севший писать запросы всерьез отказывается максимум на третий день.

    А так жде через год другой снова к этому возвращается.
    Re[5]: Язык запросов: from в начале
    От: Тычеблин Китай  
    Дата: 10.01.06 12:29
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Sinclair, Вы писали:


    VD>>>Более того. Замену имени таблицы на алиас можно осуществлять отдельной процедурой рефакторинга.

    S>>Кроме случаев, когда одна табличка встречается в запросе более чем однажды

    VD>Спокойно. Таких случаев в корректном запросе быть не может. Точнее всегда есть контекст в рамках которого можно выделить таблицу и точно понять к чему она относится. Это как имена переменных в ИЯ. Если программа кооректная, то рефакторер может определить где она определена и все ее вхождения.


    точно, точно! а интеллисенс должен разрулить такую ситуацию и при появлениии неоднозначностей добавить выще еще один уровень (например название базы) на котором эта неоднозначность пропадает,
    да и вообще интеллисенс можно сделать по образцу поиска в окне Object Browser в Visual Studio 2005

    где и иерархия сохраняется и подсвечивается причина попадания элемента в список
    Re[18]: Язык запросов: from в начале
    От: SteMage Россия  
    Дата: 10.01.06 12:45
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, GlebZ, Вы писали:


    VD>>>Тогда бы запрос выглыдел совсем просто и был бы коротким.

    GZ>>В работе с БД царят другие законы чем в языках программирования.

    VD>Это отмазки тех кто неумеет применять законы там где это нужно.


    GZ>> Здесь мы работаем с потенциально большими данными, в потенциально медленном хранилище с наличием потенциально медленных каналов.


    VD>И какое это отношение может иметь к выделению абстракций, декомпозиции и вообще принципам грамотного программирования?


    GZ>> Здесь важно эффективность выполнения запроса.


    VD>И что декомпозиция обязана понижать эффективность? Да будет тебе извесно, современные серверы переписывают запросы перед выполнением. Они не будут "выполятья" представление или функцию. Они восоздадут исходный запрос и выполнят его целиком.


    Не знаю по поводу теории, но переписывание запросов с выбрасыванием всех использованных View привело к 10 кратному ускорению работы ряда запросов. Это для MS SQL 2000. Оказалось, что если нам надо выбрать одну запись, MS SQL сервер строил весь View. Может, что-то где-то мы не так сделали. Но факт есть факт.
    Re[5]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.01.06 13:38
    Оценка: +2
    Здравствуйте, VladD2, Вы писали:

    VD>Спокойно. Таких случаев в корректном запросе быть не может.

    Это как так? Вот тебе корректный запрос:
    select Source.name, Flight.ID, Destination.Name
    from Flight 
    inner join Airport as Source on Source.ID = Flight.SourceID
    inner join Airport as Destination on Destination.ID = Flight.DestinationID

    Ты не мог бы написать его без алиасов, а потом продемонстрировать замену имени таблицы Airport на алиас, осуществив отдельную процедуру рефакторинга? А то я че-то никак не врублюсь.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[19]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.01.06 14:40
    Оценка: +2
    Здравствуйте, SteMage, Вы писали:

    SM>Не знаю по поводу теории, но переписывание запросов с выбрасыванием всех использованных View привело к 10 кратному ускорению работы ряда запросов. Это для MS SQL 2000. Оказалось, что если нам надо выбрать одну запись, MS SQL сервер строил весь View. Может, что-то где-то мы не так сделали. Но факт есть факт.

    Факт в том, что для тюнинга запросов под любой движок надо брать специалиста. Код, написанный по книжке "SQL для чайников" к жизни в продакшн непригоден. Самый умный движок можно свалить коряво написанными запросами. Независимо от наличия либо отсутствия view.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[19]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.01.06 20:35
    Оценка:
    Здравствуйте, SteMage, Вы писали:

    SM>Не знаю по поводу теории, но переписывание запросов с выбрасыванием всех использованных View привело к 10 кратному ускорению работы ряда запросов. Это для MS SQL 2000. Оказалось, что если нам надо выбрать одну запись, MS SQL сервер строил весь View. Может, что-то где-то мы не так сделали. Но факт есть факт.


    "View" сиквел не "строит". Он мог выбрать нехороший план выполнения запроса. Однако это лечится хинтами и разными фичами вроде индексированных представлений. План конечно может изменитья от изменения содержимого запроса (без изменения его семантики), но это уже плохой способ решать проблемы.

    В общем, как всегда все решают руки и голова.

    Плохие руки не могут вообще решить проблему.
    Средние руки могут решить проблему хоть как-то. Например, жертвуя простотой и легкостью поддержки/расширерия.
    Хорошие руки решают проблему при этом не ничем не жертвуя.
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.01.06 20:35
    Оценка:
    Здравствуйте, SteMage, Вы писали:

    Оверквоть поменьше.
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.01.06 20:35
    Оценка:
    Здравствуйте, SteMage, Вы писали:

    Оверквотинг поскипан.

    M>>Одно-вух-трех — не принципиально, лишь бы не полные имена таблиц, если те не автогенеренные. На моей практике, от написания полных имен севший писать запросы всерьез отказывается максимум на третий день.


    SM>А так жде через год другой снова к этому возвращается.
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.01.06 20:35
    Оценка: -1
    VD>>Спокойно. Таких случаев в корректном запросе быть не может.
    S>Это как так? Вот тебе корректный запрос:
    S>
    S>select Source.name, Flight.ID, Destination.Name
    S>from Flight 
    S>inner join Airport as Source on Source.ID = Flight.SourceID
    S>inner join Airport as Destination on Destination.ID = Flight.DestinationID
    S>

    S>Ты не мог бы написать его без алиасов, а потом продемонстрировать замену имени таблицы Airport на алиас, осуществив отдельную процедуру рефакторинга? А то я че-то никак не врублюсь.

    Не мог бы. Потому и проблем быть не может. Еще раз потворяю, корректный запрос не допускает подобных ситуаций. Корректный рефакторер должен заметить, что запрос не корректный и дать предупреждение. Это полностью аналогично сегодняшней ситуации для рефакторинга в C#. Если я объявлю две переменные в одной области видимости, то рефакторинг матернется, "что — мол — вы такое тварите?".

    В случае с этим запросом будет все очень просто. Как только тебе потребуется вторая копия таблицы, ты тут же произведешь рефакторинг введя алиас.
    ... << RSDN@Home 1.2.0 alpha rev. 628>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.01.06 03:48
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>В случае с этим запросом будет все очень просто. Как только тебе потребуется вторая копия таблицы, ты тут же произведешь рефакторинг введя алиас.

    А, понял.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re: Язык запросов: from в начале
    От: Merle Австрия http://rsdn.ru
    Дата: 18.01.06 10:41
    Оценка: 94 (5)
    Здравствуйте, AndrewVK, Вы писали:

    Ну, простите, что возвращаюсь, но тут попалось на глаза объяснение самого Хайлсберга, почему сделано именно так.

    Собственно вот:

    There are a multitude of reasons why select comes at the end and not the beginning of a query in C# 3.0. The more important ones are:

    (1) Statement completion (Cyrus' blog has a good explanation).

    (2) Order of execution. The C# query syntax lists operations in the order they are executed.

    (3) Scope of "from" variables. SQL is strange in that scope flows both upward and downward. In C#, scope extends from the point of introduction to the end of the query, which seems much more intuitive.

    (4) Large select expressions. In SQL, because results are rectangular rowsets, select clauses tend to be fairly simple. However, when querying objects and XML it is quite common to have large select expressions that construct entire object graphs, possibly with multiple nested queries. Trying to understand a large select expression written in terms of variables that haven't been introduced yet (and may not even be visible on the screen) is quite confusing.

    (5) Even if we picked SQL's ordering, the similarity would be skin deep. There are lots of other differences. For example, C#'s built-in operators and quite different from those of SQL. I actually think the different ordering is a benefit because it makes it quite clear that this is not SQL.

    Note that XQuery's FLWR ("flower") expressions have the same ordering as C#'s query expressions--I suspect for some of the same reasons.

    Anders

    Оригинал искать здесь: http://forums.microsoft.com/msdn/showpost.aspx?postid=91256&amp;siteid=1
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Мы уже победили, просто это еще не так заметно...
    Re[2]: Язык запросов: from в начале
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.01.06 10:55
    Оценка: +1
    Здравствуйте, Merle, Вы писали:

    M>Собственно вот:


    То же самое, что здесь и говорилось.
    ... << RSDN@Home 1.2.0 alpha rev. 631>>
    AVK Blog
    Re[2]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.01.06 22:35
    Оценка: :)
    Здравствуйте, Merle, Вы писали:

    Что же. Это не первые грабли в Шарпе сделаные по глупости. Был уже "деструктор" неимеющие отношения к деструкторам. Теперь будет и "SQL" не имеющий отноешния к SQL.

    Причем в обосновании в основно перечисленны технические проблемы. О потнятности и логичности не слова. И при этом постоянные разговоры о понятности.

    Собственно, что уж были высказаны все мнения приведу мнение VB-шной команды выбравшей синтаксис SQL:

    Speaking from the VB team perspective...

    As is already obvious from this thread, Select/From ordering is going to be another one of those religious issues like case insensitivity that people are going to be arguing about for the next twenty years and beyond. As with case sensitivity, both sides can marshal perfectly reasonable arguments as to why their choice is the One True Way(tm) and why the other side is Consorting With the Devil(tm). I say this knowing that nothing I say now can influence that outcome and that this discussion (in the larger sense) must always end in tears, recriminations and Godwin's law. But it's worth saying nonetheless.

    With that out of the way, I think this thread has already covered many of the relevant points relating to why VB chose to say Select/From instead of From/Select:

    * For many, many programmers and for many, many VB programmers, specifically, SQL is a very familiar language. Leveraging a huge existing base of knowledge (and programmed muscle memory) makes the LINQ support more understandable and usable straight out of the gate.

    * The SQL ordering of clauses is a time-tested convention that has been in continuous use for decades.

    * VB emphasizes English readability. As noted in the beginning of the thread, the SQL ordering is more English readable than the obverse.

    Anders raises some objections to the SQL ordering, but on the balance, we believe that the benefits outweigh the limitations. Specifically, I'd say:

    * Statement completion is a significant question. We have a bunch of ideas as to how we could finesse this in the IDE, but we haven't reached a point of being really able to try them out. This may be a real sticking point, time is just going to tell.

    * I don't agree with Anders's points about the difficulty of understanding SQL's clause ordering. Although some variants of SQL have invented phenomenally complex and bizarre sets of rules about how binding works, the basic rules about binding seem to have been graspable by millions of SQL programmers over the years without too much pain and suffering. As long as the rules remain relatively simple and straightforward, there don't appear (to me, at least) to be major hurdles in implementing a very understandable Select statement where From is in the middle of the statement. Reasonable people can disagree on this point, however.

    * Ultimately, we don't believe that people will be confused as to whether this syntax is SQL because it will become almost immediately obvious that it isn't once a programmer works with it for more than a few minutes. It's a problem that will sort itself out on its own relatively quickly.

    I would close by saying that the VB team, overall, values practicality over dogmatism. From a pure syntatic perspective, clause ordering is not fixed in stone — one could support both a Select/From order and a From/Select order without much difficulty. Indeed, we'd like to look at how clauses such as Where and Order By can be used on their own without requiring a Select or, perhaps, even a From. So while we will continue to support Select/From, other possibilities may be investigated if it becomes obvious that they make the language more usable in some strong way.

    That's about it. We now return you to your regularly scheduled religious debate...

    Paul
    VB Team


    Особенно порадовало последнее выделеное жирным.
    ... << RSDN@Home 1.2.0 alpha rev. 631>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 19.01.06 08:37
    Оценка: +3
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Merle, Вы писали:


    VD>Что же. Это не первые грабли в Шарпе сделаные по глупости. Был уже "деструктор" неимеющие отношения к деструкторам. Теперь будет и "SQL" не имеющий отноешния к SQL.


    VD>Причем в обосновании в основно перечисленны технические проблемы. О потнятности и логичности не слова.

    Просто фантастика, Влад, как ты ухитряешься пропускать слова, которые тебе противоречат. Упоминания про понятность и логичность выделены болдом:

    There are a multitude of reasons why select comes at the end and not the beginning of a query in C# 3.0. The more important ones are:

    (1) Statement completion (Cyrus' blog has a good explanation).

    (2) Order of execution. The C# query syntax lists operations in the order they are executed.

    (3) Scope of "from" variables. SQL is strange in that scope flows both upward and downward. In C#, scope extends from the point of introduction to the end of the query, which seems much more intuitive.

    (4) Large select expressions. In SQL, because results are rectangular rowsets, select clauses tend to be fairly simple. However, when querying objects and XML it is quite common to have large select expressions that construct entire object graphs, possibly with multiple nested queries. Trying to understand a large select expression written in terms of variables that haven't been introduced yet (and may not even be visible on the screen) is quite confusing.

    (5) Even if we picked SQL's ordering, the similarity would be skin deep. There are lots of other differences. For example, C#'s built-in operators and quite different from those of SQL. I actually think the different ordering is a benefit because it makes it quite clear that this is not SQL.

    Поясняю: слова intuitive, confusing, и clear относятся не к компилятору, а к человеку.
    Так что мы видим отсылки к понятности и логичности в трех из пяти аргументов.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[12]: Язык запросов: from в начале
    От: Трурль  
    Дата: 19.01.06 08:40
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    VD>Ага. Точно. Конечно ниже. Надо в комитет по SQL-ю об этом сказать. Вы им глаза просто таки откроете!


    VD>Конечно читать: Из таблиц ..., при условии ..., сгрупировав по ..., выбрать ... Куда удобнее и проще чем: Выбрать ..., из таблиц ..., при условии..., сгрупировав по ...


    А что. Привыкли же мы писать "фигура нарисовать" вместо "нарисовать фигуру".
    Re[4]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 19.01.06 16:09
    Оценка: :))
    Здравствуйте, Sinclair, Вы писали:

    S>Просто фантастика, Влад, как ты ухитряешься пропускать слова, которые тебе противоречат. Упоминания про понятность и логичность выделены болдом:


    Я ничего не пропускаю. Просто эти слова откровенно притянуты за уши. Разбором полетов заниматься не счинаю нужным, так как ответ ВБТимовца считаю исчпрпывающим.
    ... << RSDN@Home 1.2.0 alpha rev. 631>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.01.06 04:26
    Оценка: +1 :)))
    Здравствуйте, Трурль, Вы писали:

    Т>А что. Привыкли же мы писать "фигура нарисовать" вместо "нарисовать фигуру".

    Плохо переводишь "Горшочек, вари!".
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[2]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.01.06 04:26
    Оценка: 1 (1) +2
    Здравствуйте, Merle, Вы писали:
    M>Оригинал искать здесь: http://forums.microsoft.com/msdn/showpost.aspx?postid=91256&amp;siteid=1
    Кстати, еще по поводу weird scope flow: вспомнилось мне чегой-то, как я в свое время пытался понять, где что можно употреблять. Ну то есть меня, к примеру, очень раздражало, что нельзя написать так:
    select Name, DateDiff(year, Birthdate, GetDate()) Age from Person where Age>27

    зато вот так — можно:
    select Name, DateDiff(year, Birthdate, GetDate()) Age from Person order by Age>27


    На мой взгляд, совершенно неочевидная штука. Когда мы пишем вот так, все становится понятным:
    from Person where DateDiff(year, Birthdate, GetDate())>27 
    --                ^ здесь еще нету никаких Age                                                              
      select Name, DateDiff(year, Birthdate, GetDate()) Age order by Age>27
    --                                                  ^ а вот мы его ввели
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[3]: Язык запросов: from в начале
    От: SteMage Россия  
    Дата: 20.01.06 07:47
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, Merle, Вы писали:


    Не знаю, как кто. Но я для начало пытаюсь понять, что вообще делает ЭТОТ кусок кода на SQL. Он может быть апдейт делает, у может что-то удаляет. Я бы еще мог согласится на вариант.

    SELECT from Person where DateDiff(year, Birthdate, GetDate())>27 
      FIELDS Name, DateDiff(year, Birthdate, GetDate()) Age order by Age>27


    Но вначале должно быть, что мы делаем, а потом над чем. Иначе, я сначала нахожу, какое непосредственно действие.

    Лично мой алгоритм действий.

    1. Что делает этот кусок SQL кода. (SELECT, UPDATE, INSERT, DELETE). Более того часто после выяснения, что этот код делает я теряю к нему интерес, поскольку мне нужен другой код.
    2. С чем работает этот кусок SQL кода. И здесь частенько работа заканчивается, поскольку становится понятно, что нужен другой код.
    3. Дальше какой результат работы этого SQL кода в интересующих меня ситуациях.
    4. Обдумывание возможных граблей.

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

    Уж лучше бы не трогали SQL, чеи убрали из начала указание на то что этот код делает.
    Re[4]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.01.06 09:29
    Оценка:
    Здравствуйте, SteMage, Вы писали:

    SM>Но вначале должно быть, что мы делаем, а потом над чем. Иначе, я сначала нахожу, какое непосредственно действие.


    SM>Лично мой алгоритм действий.


    SM>1. Что делает этот кусок SQL кода. (SELECT, UPDATE, INSERT, DELETE). Более того часто после выяснения, что этот код делает я теряю к нему интерес, поскольку мне нужен другой код.

    SM>2. С чем работает этот кусок SQL кода. И здесь частенько работа заканчивается, поскольку становится понятно, что нужен другой код.
    Что значит "с чем работает"? С какой табличкой? Ну так это как раз во from, join, и т.п.
    SM>3. Дальше какой результат работы этого SQL кода в интересующих меня ситуациях.
    SM>4. Обдумывание возможных граблей.

    SM>Поскольку мы всегда знаем, что SQL работает с базой данных и как правило мы знаем с какой базой данных он работает. То работа с SQL несколько отличается от работы с исходным кодом.

    Этот пассаж я не понял. Исходный код обвчно тоже работает в некотором контексте, и мы как правило знаем в каком.
    SM>Уж лучше бы не трогали SQL, чеи убрали из начала указание на то что этот код делает.
    Интересный поинт. Я подумаю.
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[3]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.01.06 09:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    Ой, прошу прощения — в секст всралась очепятка. Конечно же,
    select Name, DateDiff(year, Birthdate, GetDate()) Age from Person order by Age
     
    from Person where DateDiff(year, Birthdate, GetDate())>27 
      select Name, DateDiff(year, Birthdate, GetDate()) Age order by Age
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[3]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 23.01.06 09:50
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>зато вот так — можно:

    S>
    S>select Name, DateDiff(year, Birthdate, GetDate()) Age from Person order by Age>27
    S>


    Давно я на SQL не писал. Незнал что такой бред работает. Ты в этом уверен?

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

    Думаю, что функционально поддержка "SQL" и в Васике и Шарпе будет идентичной. Но при этом лично мне будет проще читать запрос в Васике, так как он сохраняет нормальное звучание и не меняет страдиции (перестраивать сознание не надо).
    ... << RSDN@Home 1.2.0 alpha rev. 631>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: Язык запросов: from в начале
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 24.01.06 03:09
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Давно я на SQL не писал. Незнал что такой бред работает. Ты в этом уверен?

    Влад, я три дня назад эту ошибку исправил
    Автор: Sinclair
    Дата: 20.01.06
    . У тебя опять избирательное зрение работает?
    1.1.4 stable rev. 510
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[5]: Язык запросов: from в начале
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.01.06 15:33
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    VD>>Давно я на SQL не писал. Незнал что такой бред работает. Ты в этом уверен?

    S>Влад, я три дня назад эту ошибку исправил
    Автор: Sinclair
    Дата: 20.01.06
    . У тебя опять избирательное зрение работает?


    Я читаю последовательно. И телепатией не обладаю.
    ... << RSDN@Home 1.2.0 alpha rev. 631>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.