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

AVK>>Подобные фокусы в случае C# ныне лучше делать при помощи expression tree.
P>В целом expression tree будет такого же объема

В смысле? Больше объема исходников? Нет конечно, существенно меньше, особенно на сложных запросах

P>, но вот будет ли он при этом проще выглядеть... не знаю...

Не знаю насчет проще, но, как минимум, компилятор проверит типы.

P>Плюс, там в Expression tree проиходит компиляция, а пройтись по этому дереву можно?

Вот как раз expression tree тем и характерен, что, в отличие от обычной лямбды, не компилируется.

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

AVK>Вот как раз expression tree тем и характерен, что, в отличие от обычной лямбды, не компилируется.

Возможно, я смотрел не те примеры... в примерах он как раз компилируется... :hz:
Плюс, мы говорим, что должна присутвовать генерация SQL запроса, а я что-то себе не представляю как по Expression tree оно будет генерится...

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

P>Возможно, я смотрел не те примеры... в примерах он как раз компилируется... :hz:

Наверно.

P>Плюс, мы говорим, что должна присутвовать генерация SQL запроса, а я что-то себе не представляю как по Expression tree оно будет генерится...

Ну вот как то Linq2SQL генерирует.

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

AVK>Ну вот как то Linq2SQL генерирует.
Да, глянул, прикольно, но все равно нет клево как DSL... =)

Plague wrote:
> C>AFAIR, Ebay использует какую-то свою распределенную систему, где даже
> join'ы вручную оптимизируются.
> здесь можно посмотреть что у них и как
> <http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf&gt;
Ну да, они там с базы почти всю нагрузку снимают — никакой ссылочной
целостности, триггеров, бизнес-логики и минимальные транзакции.

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

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.
P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>Что думает по этому поводу народ?
Лично я думаю, что в SQL все-таки маловато выразительности, что и приводит к раздуванию текстов и ухудшению читаемости.
Основные проблемы:
1. Главное препятствие декомпозиции — отсутствие в стандарте параметризованных view. В итоге, вместо того, чтобы легким манием руки приджойнить EmployeeOrders(Name) мы пишем join EmployeeOrders where EmployeeName = Name.
2. Второе препятствие декомпозиции — отсутствие в стандарте способа задания открытых view. В итоге совершенно невозможно написать ничего подобного этому:

create view InProgress(TaskTable @tablename) as
select * from @tableName where status in ("open", "assigned", "verifying")

И применять ко всем подходящим таблицам.

3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения. Ну вот нахрена вот это все:

select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
 where DatePart(w, saleDate) between @startWeek and @endWeek
 group by DatePart(w, saleDate)
 order by 1 desc

? Да, есть альтернатива:

select WeekNumber, WeekTotal from
(select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
 group by DatePart(w, saleDate)
)
 where WeekNumber between @startWeek and @endWeek
 order by 1 desc

Но она ненамного лучше. И это еще короткий список полей. В чуть более реалистичном случае экономии на алиасах практически не будет из-за нудных перечислений под Select.

4. Жутко многословный синтаксис джойнов. Нет, я понимаю всю красоту идеи, но 99% джойнов — это equality join по foreign key. Синтаксис этого никак не отражает. Поддержка упрощенного синтаксиса FK-джойнов была бы офигенным улучшением, сокращающим большинство запросов на порядок. Примерно так:

select o.*, ow.Name from orders o
join constraint Owner as ow// === inner join Employee on Employee.ID = Order.EmployeeID

Это я предполагаю, что в таблице Orders есть именованный constraint:

foreign key constraint Owner(EmployeeID) references Employee(ID)

Или вообще вот так:

select o.*, o.Owner.Name from orders o

Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.

Других идей у меня пока нет.

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

S>3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения. Ну вот нахрена вот это все:
S>

S>select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> where DatePart(w, saleDate) between @startWeek and @endWeek
S> group by DatePart(w, saleDate)
S> order by 1 desc
S>

S>? Да, есть альтернатива:
S>

S>select WeekNumber, WeekTotal from
S>(select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> group by DatePart(w, saleDate)
S>)
S> where WeekNumber between @startWeek and @endWeek
S> order by 1 desc
S>

S>Но она ненамного лучше. И это еще короткий список полей. В чуть более реалистичном случае экономии на алиасах практически не будет из-за нудных перечислений под Select.

Можно еще with для этого использовать.

Здравствуйте, Lloyd, Вы писали:
L>Можно еще with для этого использовать.
Принципиальной разницы это не обеспечивает.

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

L>>Можно еще with для этого использовать.
S>Принципиальной разницы это не обеспечивает.

Это позволяет использовать alias.

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

L>Это позволяет использовать alias.
Это принципиально только для рекурсивных запросов. Попробуй переписать мой пример с CTE и убедишься, что это всего лишь перестановка мест слагаемых.

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

L>>Это позволяет использовать alias.
S>Это принципиально только для рекурсивных запросов. Попробуй переписать мой пример с CTE

Переписал

WITH XXX(WeekNumber, orderTotal) AS
(
    DatePart(w, saleDate), orderTotal from orders
)
SELECT WeekNumber, SUM(orderTotal) AS WeekTotal 
FROM XXX
WHERE WeekNumber between @startWeek and @endWeek
GROUP BY WeekNumber
ORDER BY WeekNumber

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

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

Есть варианты SQL без этих проблем. Например Q.

S>1. Главное препятствие декомпозиции — отсутствие в стандарте параметризованных view. В итоге, вместо того, чтобы легким манием руки приджойнить EmployeeOrders(Name) мы пишем join EmployeeOrders where EmployeeName = Name.

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

S>2. Второе препятствие декомпозиции — отсутствие в стандарте способа задания открытых view. В итоге совершенно невозможно написать ничего подобного этому:
S>

S>create view InProgress(TaskTable @tablename) as
S>select * from @tableName where status in ("open", "assigned", "verifying")
S>

S>И применять ко всем подходящим таблицам.

Эта задача решается функциями:
InProgress:{select from x where status in `open`assigned`verifying

S>3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения. Ну вот нахрена вот это все:
S>

S>select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> where DatePart(w, saleDate) between @startWeek and @endWeek
S> group by DatePart(w, saleDate)
S> order by 1 desc
S>

S>? Да, есть альтернатива:
S>

S>select WeekNumber, WeekTotal from
S>(select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> group by DatePart(w, saleDate)
S>)
S> where WeekNumber between @startWeek and @endWeek
S> order by 1 desc
S>

S>Но она ненамного лучше. И это еще короткий список полей. В чуть более реалистичном случае экономии на алиасах практически не будет из-за нудных перечислений под Select.

Тут, я так понял, идет речь и чисто текстовом алиасе, поскольку WeekNumber в select совсем не тот, что DatePart(..) в where. Набор данных они обозначают разный. В Q таких алиасов нет, но можно использовать функции, если выражение сложное или забить, поскольку group все равно нет.
[quote]
f:{DatePart(w,x)}
desc select WeekTotal: sum orderTotal by WeekNumber:f[saleDate] from orders where f[saleDate] within (startWeek;endWeek)

or

desc select from (select WeekTotal:sum orderTotal by WeekNumber:DatePart(w,saleDate)) where WeekNumber within (startWeek;endWeek)
[/quote]

S>4. Жутко многословный синтаксис джойнов. Нет, я понимаю всю красоту идеи, но 99% джойнов — это equality join по foreign key. Синтаксис этого никак не отражает. Поддержка упрощенного синтаксиса FK-джойнов была бы офигенным улучшением, сокращающим большинство запросов на порядок. Примерно так:
S>

S>select o.*, ow.Name from orders o
S>join constraint Owner as ow// === inner join Employee on Employee.ID = Order.EmployeeID
S>

S>Это я предполагаю, что в таблице Orders есть именованный constraint:
S>

S>foreign key constraint Owner(EmployeeID) references Employee(ID)
S>

S>Или вообще вот так:
S>

S>select o.*, o.Owner.Name from orders o
S>

S>Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.

Именно так и сделано в Q:
Если у t1 ключ a и еще есть столбец b, а у t2 есть foreign key a ссылающийся на t1.a и столбец с, то можно писать так:
select c, a.b from t2 where a.b>10

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


L>Переписал
L>

L>WITH XXX(WeekNumber, orderTotal) AS
L>(
L>    DatePart(w, saleDate), orderTotal from orders
L>)
L>SELECT WeekNumber, SUM(orderTotal) AS WeekTotal 
L>FROM XXX
L>WHERE WeekNumber between @startWeek and @endWeek
L>GROUP BY WeekNumber
L>ORDER BY WeekNumber
L>

L>Не убедился.
Ну и в чем разница-то между твоим и этим:

SELECT WeekNumber, SUM(orderTotal) AS WeekTotal 
FROM (SELECT DatePart(w, saleDate) as WeekNumber, orderTotal from orders) XXX
WHERE WeekNumber between @startWeek and @endWeek
GROUP BY WeekNumber
ORDER BY WeekNumber

??? Один select поменяли на один with. Ажно две буквы сэкономили! Дупа-то в том, что нам только ради введения WeekNumber пришлось вводить отдельный select statement.

Sinclair wrote:

> Т.е. употребление конструкции o.Owner *автоматически* приджойнивает
> таблицу, указанную в соответствующем FK.
Вроде всё такое HQL умеет.

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

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

Q>Звучит очень сложно. Наверно, это очень дорого писать мегаумные анализаторы и многоуровневые кеши на все случаи жизни. Гораздо легче прикупить сотню гигабайт оперативной памяти и дать легкий эффективный и прозрачный движок для БД. А всем, кому это не нравится (дяде Васе с овощного склада) показать на дверь.

А если объёмы данных дорастут до терабайта?

Ужас какой.
В таких случаях, на сколько я знаю, для отчётов изобретаются промежуточные хранилища данных, оптимизированные именно для построения отчётов. Как производить синхронизацию таких хранилищ (как впрочем любых денормализованных данных) — отдельная песня.

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

VGn>А если объёмы данных дорастут до терабайта?

Террабайт — это, в принципе, не много.

Q>Террабайт — это, в принципе, не много.

Для оперативной памяти?

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

Q>>Террабайт — это, в принципе, не много.

VGn>Для оперативной памяти?

Нет, для БД. У нас пара десятков террабайт БД и 64 гигабайт памяти для нее, в принципе, хватает.