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

[zVlad]

...... Если Вам интересно - дайте знать, могу переслать копию.

Причина по которой SQL не пользуется большим почётом у специалистов - резкий контраст между формальной строгостью реляционной терории и тем, что получилось из SQL.

Это на самом деле очень интересно. Я впервые услышал о каком-то нетрадиционном отношении "отцов-основателей" к SQL. бегло пробежал по имеющейся у меня книге Дейта "ДВ2. Руководство по реляционной базе данных". Не нашел ничего чтобы намекало на критику SQL. Такое впечатление что принято за данность.
Без посылки копии тех статей Кодда не могли бы Вы, Tengiz, кратко изложить, для всех, чем Кодд аргументирует свою неприязнь к SQL?
Вот Вы говорите: "...Причина по которой SQL не пользуется большим почётом у специалистов - резкий контраст между формальной строгостью реляционной терории и тем, что получилось из SQL".

А я читаю у Дейта:

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

Напрашивается мысль о критическом отношении к современному Дейту и Кодду состоянии SQL (1984) когда еще не было утверждения JOIN и других конструкций (рекурсивного SELECT-а например. Common expression в ДВ2). Но не понятно что сегодня можно сегодня отнести к "...резкий контраст между формальной строгостью реляционной терории и тем, что получилось из SQL"

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

[zVlad]

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

Absolutely. Хочу добавить.
Теория реляционных структур более удачный, чем другие модели данных, компромис между тем что есть в реальном мире (информацию о чем собственно и хранят в базах данных) и тем что требуют имеющиеся технические средства.
Поэтому эта теория и ее программное воплощение успешно конкурирует с новомодными течениями типа ООБД.
ООБД, на мой взгляд, неудачная попытка (если вообще это можно назвать попыткой, поскольку на дне ООБД мы как правил находим традиционную RBD, или какую-нибудь другую) применить мощную методологию программирования в области хранения данных. Так сказать "головокружение от успехов". Об этом Дейт писал уже много лет назад.

[tengiz]

Без посылки копии тех статей Кодда не могли бы Вы, Tengiz, кратко изложить, для всех, чем Кодд аргументирует свою неприязнь к SQL? Вот Вы говорите: "...Причина по которой SQL не пользуется большим почётом у специалистов - резкий контраст между формальной строгостью реляционной терории и тем, что получилось из SQL".

Самая главная претензия - операции языка SQL не является замкнутыми, т.е. производя манипуляции над множествами строк вы необязательно на выходе получите множество строк когда результатом операции не является скаляр. Самый яркие примеры, на мой взгляд, - необходимость иметь ключевое слово DISTINCT и наличие UNION ALL. Да, имейте в виду - я ничего не имею против SQL как языка практичекого программирования доступа к реляционным базам данных (как впрочем и против Вижуал Бейзика), но не нужно путать практическую полезность и удобство (которым наплевать на индукцию с дедукцией) с формальной чистотой. Именно поэтому упоминание теоремы Пифагора и неуместно.

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

Вы, я полагаю, плохо себе представляете, что такое Вижуал Бейзик. Претензии к нему как к языку программирования начались намного раньше, чем в нём появились элементы объектно-ориентированного языка. Главная претензия - невозможность сделать чёткую классификацию базовых конструкций, как это более-менее сделано, например, в другом сугубо практическом и очень популярном языке - C.

[zVlad]

......... но не нужно путать практическую полезность и удобство (которым наплевать на индукцию с дедукцией) с формальной чистотой. Именно поэтому упоминание теоремы Пифагора и неуместно.

..............Претензии к нему как к языку программирования начались намного раньше, чем в нём появились элементы объектно-ориентированного языка. Главная претензия - невозможность сделать чёткую классификацию базовых конструкций, как это более-менее сделано, например, в другом сугубо практическом и очень популярном языке - C.

.... А есть ли альтернатива SQL? Пусть хоть в нераспространенной форме.

..... Я об ВБ сужу по его уровню на эдак 1997-98 год. Тогда он был весьма псевдо-объектноориентированным хотя утверждалось конечно иное. Может что сильно изменилось с тех пор? Я не знаю.

[tengiz]

.... А есть ли альтернатива SQL? Пусть хоть в нераспространенной форме.

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

Я об ВБ сужу по его уровню на эдак 1997-98 год. Тогда он был весьма псевдо-объектноориентированным хотя утверждалось конечно иное. Может что сильно изменилось с тех пор? Я не знаю.

Проблемы вижуал бейзика о которых я говорю начались намного раньше, чем он стал мерять объектно-ориетнированные одёжки и они намного хуже, чем псевдо-ООП, в котором его теперь обвиняют.

[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 запись речь идти не может.
Относительно объектных баз данных - поверьте бывшему информикс саппорт инженеру - мало кто их использует. Несмотря на все преимущества. Все-таки хранение в пасмяти и хранение на диске -две разные вещи.

[Merle]

В пределе, мне это видится так, реляционные - это где данные организованны в виде таблиц, объектные - в виде дерьевьев.

Не совсем, все-таки не в виде деревьев, а в виде иерархии объектов. Упрощать это дело до деревьев все-таки нельзя.

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

Нет, разбираься-то как раз проще всего с объектами. В идеале вообще не надо будет переводить объект в проскую таблицу и обратно.
Скажем Запрос в объектной системе мог бы выглядеть примерно так:

Code: Select all

    IEmployer CompanyEmployer = new (SELECT IEmployer Emp WHERE Emp.Salary>1000 AND (IManager)Emp.IsCustomer('Microsoft'))

На выходе я получил бы коллекцию объектов типа IEmployer, содержащюю всех менеджеров занимающихся MS, с окладом больше штуки. При этом никокой ORM и прочая низкоуровневая лабуда не тревожила бы вообще никого - у меня есть уже готовый объект или коллекция объектов нужного типа, с которой я могу делать вообще все что угодно.
Но на сколько я себе представляю, на данном этапе развития БД это невозможно реализовать с приемлемой скоростью.
Хотя бы потому, что это сходу упирается в невозможность использовать индексы. Внутренняя реализация метода IsCustomer недоступна ввиду инкапсуляции, а значит невозможно предположить результат вызова этого метода если не вызвать его явно для каждого объекта.
Теоретически, можно придумать хитрые метаданные, описывающие методы и строить индексы на основе этих метаданных, но это не самый простой путь и об удачных реализациях я не слышал.
Далее, то же приведение типов, а-ля (IManager)Emp, радости индексам опять-таки не добавит.
И так далее, вообщем куда не плюнь - всюду проблемы.
Поэтому пока и рулит реляционный движек. С одной стороны он очень универсален, а с другой - обладает на редкость хорошей производительностью.

[zVlad]

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

Может, имеет место быть и всегда так было на МФ. С сотней каналов ввода-вывода и тысячами диском достигается соотношение 1 процессор - много записей/чтений одновременно.

[f_evgeny]

В пределе, мне это видится так, реляционные - это где данные организованны в виде таблиц, объектные - в виде дерьевьев.

Не совсем, все-таки не в виде деревьев, а в виде иерархии объектов. Упрощать это дело до деревьев все-таки нельзя.

Не совсем понимаю, абстрагируйтесь от ООП, мы же про организацию данных.
Моя мысль примерно такая, когда данных много, их надо систематизировать. Систематизацию больших объемов данных (в самом общем виде) лично я могу себе представить только в виде таблиц.
Есть другие виды организации - древовидные. Иерархия - это тоже древовидная организация, деревья ведь вовсе не обязательно должны быть бинарными.
Примеры табличной организации данных, например бухгалтерские записи, прейскуранты, массивы в программировании и т.д.
Примеры древовидной организации данных - оглавление книги, всевозможные классификации, дерево иерархии объектов программы в ООП.
Можно заметить, что как только объектов данных становиться много, становиться удонее с ними работать, применяя к ним таблицы.
Возьмем теперь Ваш пример с объектами. Все, что Вы получаете, легко получить, если объекты лежат в таблице с колонками "Занимается MS" и "Величина оклада". Таблицу можно легко обработать в цикле, используя одну и ту же процедуру и инструментальные средства, в том числе и индексы.
Но предположим, Вы организовали эти же данные в виде деревьев (обектов), как Вы их собираетесь обрабатывать? Когда их например 10^9. Ну предположим обработали, выбрали то, что надо, получили 10^4 объектов. Как теперь с ними разбираться?
В общем мой взгляд на эти вещи такой. Когда в данных имеется >10-100 объектов, хочешь не хочешь, надо запихивать эти данные в таблицу. Иначе кирдык.

[vc]

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

The relational calculi are based on the first-order (predicate) logic and SQL itself is based, loosely speaking, on the relational calculus (TRC). Whilst SQL is not "closed" in the same sense as its relational algebra interpretion operations are, it's likely to be "relationally complete". However, one can limit oneself to a carefully chosen SQL subset (avoiding nulls and duplicates) which will be "closed".

The primary motivation for letting SQL operate with bags(multisets) rather than with sets was (and still is) efficiency. The state-of-the-art in the quasi-relational database technology is such (stone age) that the decision appears to have been a reasonable engineering compromise.

All this being said, SQL whilst being a useful practical tool, as a language, has a host of problems:

o lack of support for hierarchical queries;

o syntactical inconsistency (e.g. the expression a join b is allowed but a union b is illegal, a and b being relations);

o redundancy (e.g. the HAVING clause);

o impossibility to split a complex query into manageable named pieces (the WITH clause partially corrects it);

o unnecessary COBOL-like verbosity;

etc, etc...

In brief, as someone said, Structured Query Language is neither language nor structured. There are some weak attempts to offer alternative "truly relational" language(s) (see "The Third Manifesto" by Date et al; www.alphora.com) which most likely will fail due to lack of interest from industry and the universally exhibited ignorance of practitioners of the trade.


VC

[Merle]

Не совсем понимаю, абстрагируйтесь от ООП, мы же про организацию данных.

Не, про ООП не я первый заговорил. Либо ООП, либо иерархия, просто объекты до банальной иерархии сводить нельзя, не так удобно получается.

Моя мысль примерно такая, когда данных много, их надо систематизировать. Систематизацию больших объемов данных (в самом общем виде) лично я могу себе представить только в виде таблиц.

Да в каком угодно виде, систематезировать их будет машина, а она железная, ей все равно...

Примеры табличной организации данных, например бухгалтерские записи, прейскуранты, массивы в программировании и т.д.

Их тоже можно свести к иерархии, как и наоборот - дело не в этом.

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

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

Возьмем теперь Ваш пример с объектами. Все, что Вы получаете, легко получить, если объекты лежат в таблице с колонками "Занимается MS" и "Величина оклада". Таблицу можно легко обработать в цикле, используя одну и ту же процедуру и инструментальные средства, в том числе и индексы.

Обработать да, а вот получить - нет. Получить в разы сложнее, надо выбрать это дело из плоской таблицы, разложить по полям объекта выполнив ряд преобразований и проверок, и то же самое, в обратном порядке, надо сделать при сохранении... Головная боль та еще...

Но предположим, Вы организовали эти же данные в виде деревьев (обектов), как Вы их собираетесь обрабатывать?

Смотря что имеется в виду под обработкой. Скажем обработка одного "объекта" в иерархической или объектной системе будет и быстрее и проще чем в реляционной. А вот совокупность объектов, отобанных по разным признакам для разработчика опять-таки будет проще, а вот на производительности это скажется фатально.

Когда их например 10^9. Ну предположим обработали, выбрали то, что надо, получили 10^4 объектов. Как теперь с ними разбираться?

Ээээ стоп, от выборки 10^4 объектов и реляционной системе поплохеет. Должно быть что-то сильно не так в системе, если требуется отбирать такое количество объектов.

В общем мой взгляд на эти вещи такой. Когда в данных имеется >10-100 объектов, хочешь не хочешь, надо запихивать эти данные в таблицу. Иначе кирдык.

Ну нет. Я с трудом могу представить себе систему в которой надо одновременно вытягивать из хранилища больше нескольких сотен объектов.