Второе дыхание SQL. Техническое ессе.

[Dmitry67]

С чего Вы это взяли ? Про Юкон почитали

Ага!

Я собстевенно ничего не имею против stored proc не .NET. Но они нужны чтобы писать вещи не-SQLные. Обработка изображений, отпечатков пальцев итд

Что же происходит на практике ? Брошен клич - Yukon рулит, даешь процедуры на .Net. Больше не надо знать этот ужасный SQL ! Многие уже заняли низкий старт. Это те кто не может мыслить в терминах базы данных.

Я ничего плохого о них сказать не хочу. Обычные программисты. Всю жизнь пишут на языках ОО. И просто мыслить в иных терминах не умеют. Когда им надо написать

Code: Select all

insert into TABa select x,y from Z where N=@var and y>0

то они могут мыслить только так. Берем значит один элемент. Проверяем y. Если больше нуля то пишем в таблицу. Цикл занчит
Вот что выходит в итоге:

Code: Select all

declare @x int, @y int
declare hl cursor for select x,y from Z where N=@var
open hl
fetch next from hl into  @x,@y
while @@FETCH_STATUS <> -1 begin
  if @@FETCH_STATUS <> -2 begin
    if @y>0
      insert into TABa select @x,@y
  end
  fetch next from hl into  @x,@y
end
close hl
deallocate hl 

Это в лучшем случае
Знаете сколько я такого кода переписал ?

Что будет с приходом Юкона ? Они будут писать то же самое на .Net Забудут все join, view итд, Вместо этого радостно будут читать все записи в DataSet и потом крутить свои ужасные циклы. И главное обрывки SQL пореаторов в таких процедурах все равно будут.

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

[zVlad]

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

Понятно. Спасибо. Я читал что в ДВ2 делается сначала преобразование в некую внутренную форму - более пригодную для дальшей оптимизации и выполнения, но никогда этой формы не видел и естественно не пользовался. Можно наверное заключить что SQL - это своего рода дань человеческим особенностям видеть и понимать, не таким как в случае строгого матиматического построения.

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

[zVlad]

............

Мудро, Дима. Полностью с Вами солидарен. Я бы так перефразировал то что Вы изрекли:

Незнание SQL и принципов работы RDB не освобождает вас от ответственности за плохо написанные продукты.

[tengiz]

Вот что выходит в итоге:

Code: Select all

declare @x int, @y int
declare hl cursor for select x,y from Z where N=@var
open hl
fetch next from hl into  @x,@y
while @@FETCH_STATUS <> -1 begin
  if @@FETCH_STATUS <> -2 begin
    if @y>0
      insert into TABa select @x,@y
  end
  fetch next from hl into  @x,@y
end
close hl
deallocate hl

Как Вы блестяще только что доказали, для того чтобы писать ужасные программы, которые ни фига не настоящий SQL, ничего другого, кроме самого настоящего SQL не нужно

дотнет тут врядли что-то принципиально изменит.

[f_evgeny]

Раз такая дискуссия, надо и Линуксоидам высказаться, донести, так сказать до элиты IT, что по этому поводу думают рабочие и крестьяне, оторвавшись на минуточку от сохи.
Итак, по поводу смерти SQL.
Что такое SQL - это интерфейс к реляционным базам данных. Свою функцию он выполняет неплохо, и его достаточно просто объяснять, что есть большой плюс.
Давно говорят, что на смену реляционным базам данных должны объектно ориентированные базы. Попробуем разобраться. Что такое товарищи реляционные и что такое объектно-ориентированные? В пределе, мне это видится так, реляционные - это где данные организованны в виде таблиц, объектные - в виде дерьевьев.
Чем хороши таблицы, и чем плохи деревья?
Предположим, что мы имеем много данных, лежит перед нами такая большая куча объектов. Как мы будем с ними разбираться? Простой, рабоче-крестьянский подход говорит следующее - выделяем набор признаков, совокупность которых определяет объект. Что получилось? Правильно, таблица, в которой строки соответствуют объектам, столбцы - признакам.
Теперь попробуем ту же самую кучу проклассифициоровать при помощи деревьев. Получаем в пределе для каждого объекта свое дерево признаков. И как теперь с этим $*#*: разбираться?
Мне это представляется проблематичным.
Вот как мне кажется главная причина, по которой реляционные БД так и будут хранить данные, а обектные - обсуждаться в кулуарах.

[Srdjan Levic]

Действительно, законы природы не дадут сделать процессор быстрее 10Ghz.

А чаво ?
Елехтроны так быстро бегать не умеють

Научная общественность сейчас пугает нас опытными разработками "оптических процессоров". Не знаю, как насчет оптических ЦП, но перевод шинных архитектур на оптику точно дал бы большой толчок увеличению производительности.
Кроме того, нужен такой же прорыв в области систем хранения - нужно чего-то новое и оч.быстрое, а также оч.емкое. Емкое еще туда-сюда просто, а вот чтобы оно еще было реально быстрым - быстро считывало и быстро писало - т.е. "диски" работающие со скоростями оперативной памяти.

[Srdjan Levic]

Вообще, чисто со стороны (я не программист) наблюдаю, что объектное расширение Oracl-а еще со времен выхода 8-ки в 97-ом и по сей день как-то не прижилось - народ продолжает использовать привычную парадигму - обычные структуры таблиц, SQL/PLSQL и в принципе не хоч.связываться с объектами. По кр.мере в наших (около-телекомовских вещах - биллинг всякий itd.). Я не хочу сводить на обсуждение Оракла, так, чисто для примера.
Imho, SQL еще долго проживет.

[Strannik223]

Я собстевенно ничего не имею против stored proc не .NET. Но они нужны чтобы писать вещи не-SQLные. Обработка изображений, отпечатков пальцев итд
...
Перефразируя известное изречение, программист ! Если ты работаешь с SQL и пишешь процедуры на .Net, то и то и другое ты делаешь плохо :)

А давайте разделим мух и мясо.
А давайте не будем путать собственно SQL и Transact-Sql.
Или вы считаете те языковые конструкции IF, WHILE, etc, нормальным языком?
Упрвление ощибками про помощи SET XACT ON это красиво?
Или проверка @@errorcode после каждого стейтмета, которая засоряет саму процедуру это замечательно?

TransactSQL это живое ископаемое.

Дмитрий, без наездов, но помоему ваша священная война с .net in Yukon связана с ложным впечатленим что он идет заменять SQL тогда как на самом деле он призван заменить Transact-Sql.

А ламеры которые о при написании sql мыслят в терминах записей а не множеств всегда будет полно. И ничего с приходом .net тут не поменяется.

[Dmitry67]

Он не идет заменять Transact SQL
Усли Вы заметили в TSQL появился Try
В свою очередь Вы считаете что следующая синтаксическая шелуха

Code: Select all

using System.Data.Sql;
using System.Data.SqlServer;
 
/// <summary>
/// This is my first .NET routine.
/// </summary>

public class MyNETRoutines
{ 
     public static void FirstProc()
      { 
           SqlPipe myPipe = SqlContext.GetPipe();
           myPipe.Send("Hello World");
           SqlCommand cmd = SqlContext.GetCommand();
           cmd.CommandText ="select * from product";
           myPipe.Send(cmd.ExecuteReader());
     }
}

после каждого оператора это хорошо ?

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

[Strannik223]

Он не идет заменять Transact SQL
Усли Вы заметили в TSQL появился Try
В свою очередь Вы считаете что следующая синтаксическая шелуха

......
после каждого оператора это хорошо ?

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

У меня перед глазами несколько иной пример.
На одной из фирм где я работал мы испытывали проблемы с производительностья в посдсисеме отчетов.
Я писал просто таки вируозные SQL которые выжимали все что только было можно, но требования к отчетам были слишком широки что бы удовлетворить и скорость и функциональность. И тогда американцы наняли для редизайна системы какого-то SQL гуру. Когда я взглянул на ее (да, это была женщина) прототип, у меня волосы встали дыбом. Фактически она написала псевдокомпилятор на TSQL. Это просто надо было видеть. Я пообщался с ней, и понял что дело в том что она никаких других языков не знает, от моих предложений переписать бизнес логику на c# отбивалась такими отмазками что когда я запостил логи мессенжора в список рассылки то это было предметом шуток всю следующую неделю. Она на TSQL анализировала структуру отчета и по ней генерировала SQL который будет исполнятся, как стринг естественно. Через какое то время она наткнулась на то, что она не может сгенерить стринг с SQL длиннее 8К, что случалось когда юзер задавал много полей. Тогда она начала хачить структуру базы что бы была возможность бить запросы на куски. Тогда полезли проблемы с фильтрами которые юзер мог наложить на запрос. Хотя надо сказать что структуру таблиц она очень неплохо переделала, но это отдельная история так как мы пеерешли от одной базы к двум, оперативной и Warehouse.
Чем это закончилось я не знаю так как как раз в это время я уезжал в Канаду.

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

А вообще SQL очень резко отличается от иных языков програмирования. Неким рубиконом для себя я опеределил момент когда ты начинаешь мыслить в терминах множеств.
И среди програмистов общего профиля очень немного тех кто "чувствует" sql.

[Sergey___K]

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

Вот вы ответили на вопрос "а нафига это нужно?"

[katit]

И среди програмистов общего профиля очень немного тех кто "чувствует" sql.

Не знаю общего я или не общего но порой тяжело написать запрос
приходится идити в microsoft.sqlserver.programming.
там ребята за 2 секунды делают.

[flip_flop]

Ooops...

[flip_flop]

Действительно, законы природы не дадут сделать процессор быстрее 10Ghz.

А чаво ?
Елехтроны так быстро бегать не умеють

Научная общественность сейчас пугает нас опытными разработками "оптических процессоров". Не знаю, как насчет оптических ЦП, но перевод шинных архитектур на оптику точно дал бы большой толчок увеличению производительности.
Кроме того, нужен такой же прорыв в области систем хранения - нужно чего-то новое и оч.быстрое, а также оч.емкое. Емкое еще туда-сюда просто, а вот чтобы оно еще было реально быстрым - быстро считывало и быстро писало - т.е. "диски" работающие со скоростями оперативной памяти.

Товарищи /господа программисты и иже с ними,
Завераю Вас, что старый добрый, но несколько усовершeнствованный силикон и даже его ширпотребная версия в виде CMOS технологии, потянет и 10 и 20 GHz в будущем. А также > 10 Gbit/s/channel для последовательных интерфейсов для chip-to-chip interconnect по обычной меди на плате. Закон Мура все еще работает.

A так вы вообще отрицаете в корне прaвo на мое существование, придумывая новые законы природы

[smitin]

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