Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
2Lirik_SPB
Это не ответ на вопросы.
Дальше, а как будут работать индексы, если объекты разных версий?


Я уже писал, что с индексами действительно могут возникнуть вопросы. Но описание того, как разрешаются ВСЕ возможные варианты таких конфликтных ситуаций, займет очень много места. Логичнее обратиться к документации на продукты.
4 фев 05, 15:03    [1300805]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ответ лишь на одну фразу
BaZa
Я не буду спорить с тем, что я недавно закончил инситиут... хм институт может быть оканчивали вы, а я окончил УНИВЕРСИТЕТ (СПбГУ). Может быть слышали о таком?
И именно то, чему меня там учили позволяет мне утверждать все это...

Да нет, я тоже закончил универ. ИГУ (Иркутский). Так что мы однополчане :))
И именно то все, чему я научился после окончания, позволило мне влезть в это болото :))

-- Tygra's --
4 фев 05, 15:11    [1300846]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
А что насчет остальных, хотя это не так уж и существенно, ведь все равно каждый окажется при своем мнении...
Всем peace :)
4 фев 05, 15:23    [1300913]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
BaZa
А что насчет остальных, хотя это не так уж и существенно, ведь все равно каждый окажется при своем мнении...
Всем peace :)


Насчет своих мнений - не сомневаюсь... Есть у меня один знакомый, так он окромя досовского фокса ничего другого не признает и заявляет, что SQL - для ленивых...
:-)
И основной его аргумент очень похож на услышанное мною здесь - "Так ведь - работает"... No comments.
4 фев 05, 17:58    [1301533]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
PArth

Насчет своих мнений - не сомневаюсь... Есть у меня один знакомый, так он окромя досовского фокса ничего другого не признает и заявляет, что SQL - для ленивых...
:-)
И основной его аргумент очень похож на услышанное мною здесь - "Так ведь - работает"... No comments.


Во-во, очень его аргументы на ваши собственные похожи...

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

Об том и речь, что, пусть иногда и с потерей (иногда!!!) тех преимуществ, которые дает Р/ОРСУБД, но зато с экономией времени (-->денег!!!) можно удовлетворить всем поставленным требованиям, используя ОО языки высого уровня + реализация О/Р преобразования (или ООСУБД)...
4 фев 05, 18:06    [1301550]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
:-) :-) И мне по ушам досталось... :-) Я-то вроде бы об этом же говорил... :-)
4 фев 05, 18:11    [1301559]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
2_PArth

Прости, дружище, это наверно мизандерстуд (жесткий)...

кстати во какой линк накопал
4 фев 05, 18:25    [1301596]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

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

Alexey Rovdo>> Лично я считаю постановку задачи вполне достаточной.

c127> Раз постановка достаточна, то не затруднит ли Вас сделать одно из двух: либо признать решение SergSuper-а полным и удовлетворительным либо процитировать ту часть постановки задачи, которой это решение не удовлетворяет.


А потом мы поговорим о демагогии.
5 фев 05, 02:15    [1302063]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
Lirik_SPB> Утверждение tygra` а можно свести к фразе "зачем вам языки высокого уровня, ассемблер все может - пользуйтесь им и не выпендривайтесь, а если не хотите то и не суйтесь в программирование" если проводить аналогию с языками программирования.

BaZa> Об том и речь, что, пусть иногда и с потерей (иногда!!!) тех преимуществ, которые дает Р/ОРСУБД, но зато с экономией времени (-->денег!!!) можно удовлетворить всем поставленным требованиям, используя ОО языки высого уровня + реализация О/Р преобразования (или ООСУБД)...

Ну все, приравняли СКЛ к асемблеру, а ОО языки это оказывается языки высокого уровня. А господа закончившие университет знают разницу между императивными и апликативными стилями программирования? И знают ли они который из них поддерживается ОО языками и асемблером (именно в такой группировке), а который СКЛ-ем? И что разница между ЛЮБЫМ ОО языком и асемблером гораздо меньше, чем между асемблером и СКЛ-ем. Разницу в стилях, их преимущества и недостатки можно оценить, сравнив варианты решения нашей многострадальной задачи, предложенные Alexey Rovdo и SergSuper-ом. Так что не надо рассказывать сказки о том, кто программирует на асемблере, а кто на языках высокого уровня.
5 фев 05, 04:18    [1302097]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
>с127: "Ну все, приравняли СКЛ к асемблеру, а ОО языки это оказывается языки высокого уровня. А господа закончившие университет знают разницу между императивными и апликативными стилями программирования? И знают ли они который из них поддерживается ОО языками и асемблером (именно в такой группировке), а который СКЛ-ем? И что разница между ЛЮБЫМ ОО языком и асемблером гораздо меньше, чем между асемблером и СКЛ-ем. Разницу в стилях, их преимущества и недостатки можно оценить, сравнив варианты решения нашей многострадальной задачи, предложенные Alexey Rovdo и SergSuper-ом. Так что не надо рассказывать сказки о том, кто программирует на асемблере, а кто на языках высокого уровня"

А что Вам знания различий между стилями программирования дают на практике? :-)

Я больше 15 лет работаю с РСУБД, и готов повторять вслед за Lirik_SPB: "Да, это хороший инструмент. Да, практически любую задачу хранения и обработки данных этим инструментом можно решить". НО!!! Но почему я, используя объектный инструментарий для кодирования бизнес-логики должен огрничивать себя структурным языком работы с данными? Почему сложную сущность я должен "распределять" по множеству таблиц? (При этом следить за целостностью, непротиворечивостью и т.д. и т.п.) И вот этих почему у меня накопилось достаточно много. У Вас есть ответы на эти почему?

А вообще-то Alexey Rovdo не миссионер. (И я тоже...) Он только продает продукты Versant, но не обязан обращать Вас в ОО ВЕРУ. Каждый должен вырасти до этого сам. Вы, похоже, не доросли...
5 фев 05, 07:38    [1302112]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Лох Позорный

>Да не настаивайте вы на отказе от ввода/вывода.
Хотят сравнивать не только СУБД, но и клиентское междумордие - еще больше проиграют.


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

2 PArth

>А что Вам знания различий между стилями программирования дают на практике? :-)

По-моему решение совершенно практической задачи предложенной Alexey Rovdo, при котором "асемблер" выиграл у "языка высокого уровня" в 4 раза, отвечает на Ваш вопрос. А знания различий между стилями позволяет мне понять, что такой разрыв не случайность а закономерность и соответсвенно выбирать средства решения совершенно практических задач. А кроме экономии труда, времени и денег это никакой практической пользы не приносит, тут Вы правы.

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

Могу только посочувствовать и пожелать все-таки перейти с парадокса на нормальные СКЛ сервера. В парадоксе - да, там язык структурный. Кстати в Ваших ООБД языки тоже структурные - джава, С++ и пр, хоть и называются ОО. Посмотрите на код Alexey Rovdo. А перейдете на СКЛ - немного поработаете и, я уверен, начнете ощущать силу декларативных языков. Попробуйте.

>А вообще-то Alexey Rovdo не миссионер. (И я тоже...) Он только продает продукты Versant, но не обязан обращать Вас в ОО ВЕРУ. Каждый должен вырасти до этого сам. Вы, похоже, не доросли...

То, что Alexey Rovdo тут зарабатывает деньги, а вовсе не стремится разобраться в ситуации, стало понятно по его слишком уж слишком явному стремлению получить единственный выгодный для себя результат.
5 фев 05, 11:20    [1302157]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
Про парадокс не понял... И на второе "почему" ответа не получил...
5 фев 05, 13:32    [1302244]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
Вдогонку:

"Могу только посочувствовать и пожелать все-таки перейти с парадокса на нормальные СКЛ сервера. В парадоксе - да, там язык структурный. Кстати в Ваших ООБД языки тоже структурные - джава, С++ и пр, хоть и называются ОО"

1) Ежели Вы про Borland Paradox - то Вы явно мне напрасно приписываете чужие заслуги.... :-)
2) SQL - Structured Query Language. Ваши комментарии?
3) В ООБД никакого языка нет(окромя OQL)!!! (впрочем, так же как и впарадоксе...)
4) C++, Borland Object Pascal и иже с ними потому и называются Объектно-Ориентироваными, что позволяют смешивать стили... SmallTalk, C#, Java, etc. - Объектные языки.

"А перейдете на СКЛ - немного поработаете ..."

Вы невнимательны, либо читаете только собственные сообщения... Я от SQL ухожу...
5 фев 05, 13:54    [1302258]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 PArth

>2) SQL - Structured Query Language. Ваши комментарии?

А может так: Structured Query Language. Не структурный язык запросов, а язык структурных запросов.

Но если серьезно, то это была шутка. Не бывает структурных языков, бывает структурный стиль, поддерживаемый какими-то процедурными языками, всякие там begin-end, if-then-else, хотя структурно можно писать и на фортране 66. Поэтому нельзя говорить "...огрничивать себя структурным языком работы..." (PArth) это ИМХО неграмотно.

>И на второе "почему" ответа не получил...

С удовольствием отвечу, но какое именно "почему" Вы называете вторым? Там есть риторические. На какое нужно отвечать?

>3) В ООБД никакого языка нет(окромя OQL)!!! (впрочем, так же как и впарадоксе...)

А мне тут заливали о смалтоке (АЗ> Server Smalltalk -- GemStone allows database application developers to create classes and write methods which are stored and executed directly in the database. These methods can be accessed either internally, or from external client applications), СКЛ-е, якобы поддерживаемым фастобжексом. Так и знал, что никому верить нельзя.

Я не знал, что парадокс теперь поддерживает OQL. Молодцы, развивают продукт, хоть в этом и нет смысла. Лет 10 назад там был только PAL (Paradox Application Language), если не ошибаюсь. Процедурно-ориентированный язык, типа паскаля или джавы, поддерживающий структурный стиль. Ужас, одним словом.

>4) C++, Borland Object Pascal и иже с ними потому и называются Объектно-Ориентироваными, что позволяют смешивать стили... SmallTalk, C#, Java, etc. - Объектные языки.

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

Приведите определения - обсудим.

c127> А перейдете на СКЛ - немного поработаете ..."

>Вы невнимательны, либо читаете только собственные сообщения... Я от SQL ухожу...


Это Вы невнимательны при написании своих постов. У Вас написано: "Я больше 15 лет работаю с РСУБД, и готов повторять вслед за Lirik_SPB....". Тут не сказано, что Вы работаете с СКЛ. За 15 лет работы с РСУБД можно было бы выяснить, что СКЛ != РСУБД. Например Вы могли работать как администратор, там без знания СКЛ в принципе можно обойтись.

А я Вам предлагал ПОРАБОТАТЬ с СКЛ. Так что у все правильно, ошибки нет.

Но это все чепуха. Я все-таки хотел бы получить ответ на мой вопрос.

Alexey Rovdo>> Лично я считаю постановку задачи вполне достаточной.

c127> Раз постановка достаточна, то не затруднит ли Вас сделать одно из двух: либо признать решение SergSuper-а полным и удовлетворительным либо процитировать ту часть постановки задачи, которой это решение не удовлетворяет.
6 фев 05, 00:04    [1302758]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
"А мне тут заливали о смалтоке (АЗ> Server Smalltalk -- GemStone allows database application developers to create classes and write methods which are stored and executed directly in the database. These methods can be accessed either internally, or from external client applications), СКЛ-е, якобы поддерживаемым фастобжексом. Так и знал, что никому верить нельзя"

Да, смешались в кучу кони, люди... Про Smalltalk помолчу - не знаю... А FastObjects поддерживает не SQL, а OQL...

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

P.S. На неделю исчезаю, лайтесь дальше без меня...
6 фев 05, 01:17    [1302795]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
И напоследок...

2 с127:
"А может так: Structured Query Language. Не структурный язык запросов, а язык структурных запросов"

А что, это что-то принципиально меняет? Объектность вдруг вырастает?

"Т.е. по-Вашему джава не поддерживает структурный стиль? А если поддерживает, то какой смысл в Вашей классификации, по которой одинаковые языки вдруг стали относится к разным классам"

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

" я Вам предлагал ПОРАБОТАТЬ с СКЛ. Так что у все правильно, ошибки нет."

Любопытно, на основании какой информации Вы решили, что я с ним не РАБОТАЛ? Я конечно понимаю, Вы сами его недавно изучили и до сих пор не наигрались... Но это пройдет со временем...
6 фев 05, 01:28    [1302799]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
>P.S. На неделю исчезаю, лайтесь дальше без меня...

Вы с Андреем Леонидовичем случайно не на одних курсах учились? Уж больно приемы похожи: типа как только жареным запахло - все, исчезаю на N недель.

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

Кстати парадокс это такой программный продукт, файл-серверная БД, если Вы еще не поняли.

Проявлять остроумие в нашем диалоге начали первым Вы: "PArth> Каждый должен вырасти до этого сам. Вы, похоже, не доросли..."

>Любопытно, на основании какой информации Вы решили, что я с ним не РАБОТАЛ?

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

PArth>>> В ООБД никакого языка нет(окромя OQL)!!!

c127>> А мне тут заливали о смалтоке (АЗ> Server Smalltalk -- GemStone allows....)

>Про Smalltalk помолчу - не знаю...


А что, GemStone не ООБД? Вот я и говорю, что никому верить нельзя. Вы только что совершенно категорично, заявили, что никакого другого языка нет и точка, а тут уже типа не знаю, промолчу. Раньше молчать нужно было.

>А FastObjects поддерживает не SQL, а OQL...

Alexey Rovdo[1285687]> Действительно эффективные объектно-ориентированные приложения не должны осуществлять выборку данных по значению (во всяком, случае этого следует всячески избегать) – они должны использовать прямую навигацию, что реализуется в программах на объектно-ориентированных языках программирования (Java, C++, C#, SmallTalk ... ). Таким образом в ООСУБД отделение базы данных от приложения противоречит всей идеологии системы.

Да, про СКЛ не нашел, может ошибся, зато было про Java, C++, C#, SmallTalk. Это никак не вяжется с Вашим: "В ООБД никакого языка нет(окромя OQL)!!!". Тут их аж 4 кроме OQL.
6 фев 05, 04:44    [1302816]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
PArth
Member

Откуда: теткина деревня
Сообщений: 48
"Вы с Андреем Леонидовичем случайно не на одних курсах учились? Уж больно приемы похожи:"

Не имею чести быть знакомым...

"Кстати парадокс это такой программный продукт, файл-серверная БД, если Вы еще не поняли."

Вот я и говорю - хватит хамить...

"А что, GemStone не ООБД? Вот я и говорю, что никому верить нельзя... ... Да, про СКЛ не нашел, может ошибся, зато было про Java, C++, C#, SmallTalk. Это никак не вяжется с Вашим: "В ООБД никакого языка нет(окромя OQL)!!!". "

Я же сказал - внутри ООБД, т.е. ни внутри ОО данных, ни внутри сервера никаких языков нет.(Никаких интерпретаторов, рантаймов и т.п.) Или Вы все давным-давно поняли и просто стебетесь?
А про GemStone сказал ведь - не в курсах, могет быть создатели интерпретатор Смолтока внутрь засунули, откуда мне знать? Токда это круто...

"типа как только жареным запахло - все, исчезаю на N недель"

А что Вы только вошли во вкус??? Я что-то от Вас ни одного сообщения по-делу не прочитал... (Ну не считая замечаний про парадокс, конечно...)

Всё, тороплюсь на поезд...
6 фев 05, 08:06    [1302834]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 PArth

Где пропадали целую неделю?

>Вот я и говорю - хватит хамить...

А не нужно было начинать. Вам типа можно, а другим нельзя. По-видимому вы (те, кто уходит от РМД к более прогрессивной ОМД) в таком же стиле и СУБД сравниваете.

> Я же сказал - внутри ООБД, т.е. ни внутри ОО данных, ни внутри сервера никаких языков нет.(Никаких интерпретаторов, рантаймов и т.п.) Или Вы все давным-давно поняли и просто стебетесь?

Не понял я ничего. Одно из основных утверждение ООСУБД-шников, что нет клиента, нет сервера, все свалено в кучу и это оказывается громадное преимущество: "Таким образом в ООСУБД отделение базы данных от приложения противоречит всей идеологии системы" (Alexey Rovdo[1285687]). Раз есть где-то джава (С++, С#, ...), а деления на сервер и не-сервер нет, то получается что джава и все остальные языки именно в сервере.

Или все-таки сервер отдельно а клиент отдельно? И если вдруг сервер присутсвует отдельно, то что же мы не сравнивали сервера, а боролись с какой-то джавой. Или Вы с этим не согласны?

>Я что-то от Вас ни одного сообщения по-делу не прочитал...

Это исключительно потому что плохо читаете. Специально для Вас еще раз повторяю пример замечания по-делу, может Вы сумеете ответить и спасете попавшего в неловкое положение Alexey Rovdo:

Alexey Rovdo>> Лично я считаю постановку задачи вполне достаточной.

c127> Раз постановка достаточна, то не затруднит ли Вас сделать одно из двух: либо признать решение SergSuper-а полным и удовлетворительным либо процитировать ту часть постановки задачи, которой это решение не удовлетворяет.
7 фев 05, 06:15    [1303447]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127

А потом мы поговорим о демагогии.


"говорить о демагогии" - это уже какая-то демагогия в квадрате получается.
8 фев 05, 17:50    [1308724]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Итак, пришло время проанализировать различные решения предложенной задачи на предмет быстродействия. Сразу замечу, что свой анализ я начну именно со своих двух решений (для FastObjects и для MS SQL), но и первое решение SergSuper забыто не будет.

Содержание

Введение

Недостатки SQL на примере анализа конкретного запроса

Модель данных по версии SergSuper, ее отличия и недостатки

Анализ исполнения сложного JOIN-запроса в MS SQL Server

Анализ выборки сложных данных в FastObjects

Сравнение эффективности MS SQL и FastObjects на примере однотипной выборки

Выводы



продолжение следует ...
8 фев 05, 18:18    [1308824]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Введение

Содержание

Начнем с очередной конкретизации того, что же мы рассматриваем. Для FastObjects мы будем рассматривать отдельные участки Java-кода, а для MS SQL – сами SQL-запросы (имея, однако, в виду, что их результаты мы в итоге хотим видеть в приложении, а не только в QA).

продолжение следует ...
8 фев 05, 18:20    [1308834]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Недостатки SQL на примере анализа конкретного запроса

Содержание

В представленном мною ранее решении для MS SQL Server Запрос 1 выглядел следующим образом:

SELECT Item.id, Item.day, Flight.description, Seat.level, Count(Seat.id)-Count(Seat2.id) AS free_seats 
FROM Item INNER JOIN Flight ON Flight.id = Item.flight_id 
INNER JOIN CraftType ON CraftType.id = Flight.crafttype_id      
INNER JOIN Seat ON Seat.crafttype_id = CraftType.id 
INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id 
INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id 
LEFT JOIN Ticket ON Ticket.item_id = Item.id 
LEFT JOIN Seat AS Seat2 ON Ticket.seat_id = Seat2.id and Seat2.level = Seat.level 
WHERE Item.day = '01.01.2005' and City1.name = 'A' and  City2.name = 'B' 
GROUP BY Item.id, Item.day, Flight.description, Seat.level 

Чтобы не быть раскритикованным за использование неоптимального запроса, я начинаю с детального его рассмотрения и оптимизации по ряду параметров. И пежде всего оказывается, что этот запрос вообще ОШИБОЧНЫЙ. Что же в нем не так ? Полагаю только очень немногие спецы высокого класса смогут увидеть ошибку в этом исходном коде без запуска запроса на контрольных данных (поясняю для малограмотных – вот для чего нужны тестовые данные – чтобы проверять на них корректную работу написанных запросов).

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

После необходимой правки наш запрос будет выглядеть следующим образом:

SELECT Item.id, Item.day, Flight.description, Seat.level, Count(Seat.id)-Count(Ticket.id) free_seats
FROM Item 
INNER JOIN Flight ON Flight.id = Item.flight_id and Item.day = '01.01.2005'
INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id and City1.name = 'A' 
INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id and City2.name = 'B'
INNER JOIN CraftType ON CraftType.id = Flight.crafttype_id 
INNER JOIN Seat ON Seat.crafttype_id = CraftType.id 
LEFT OUTER JOIN Ticket ON Ticket.seat_id = Seat.id and Ticket.item_id = Item.id
GROUP BY Item.id, Item.day, Flight.description, Seat.level

Забавно, однако, что существует много вариантов построения этого запроса. Вот, к примеру, еще один:

SELECT Item.id, Item.day, Flight.description, Seat.level, Count(Seat.id)-Count(Ticket.id) free_seats
FROM Seat
INNER JOIN CraftType ON Seat.crafttype_id = CraftType.id 
INNER JOIN Flight ON CraftType.id = Flight.crafttype_id 
INNER JOIN Item ON Flight.id = Item.flight_id and Item.day = '01.01.2005'
INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id and City1.name = 'A' 
INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id and City2.name = 'B'
LEFT OUTER JOIN Ticket ON Ticket.seat_id = Seat.id and Ticket.item_id = Item.id
GROUP BY Item.id, Item.day, Flight.description, Seat.level

А можно и так:

SELECT Item.id, Item.day, Flight.description, Seat.level, Count(Seat.id)-Count(Ticket.id) free_seats
FROM Item 
INNER JOIN Flight ON Flight.id = Item.flight_id 
INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id 
INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id 
INNER JOIN CraftType ON CraftType.id = Flight.crafttype_id 
INNER JOIN Seat ON Seat.crafttype_id = CraftType.id 
LEFT OUTER JOIN Ticket ON Ticket.seat_id = Seat.id and Ticket.item_id = Item.id
WHERE Item.day = '01.01.2005' and City1.name = 'A' and City2.name = 'B'
GROUP BY Item.id, Item.day, Flight.description, Seat.level

Или так:

SELECT Item.id, Item.day, Flight.description, Seat.level, Count(Seat.id)-Count(Ticket.id) free_seats
FROM Item 
LEFT JOIN Flight ON Flight.id = Item.flight_id 
LEFT JOIN CraftType ON CraftType.id = Flight.crafttype_id 
LEFT JOIN Seat ON Seat.crafttype_id = CraftType.id 
LEFT JOIN City AS City1 ON Flight.startpoint_id = City1.id 
LEFT JOIN City AS City2 ON Flight.endpoint_id = City2.id and City2.name = 'B'
LEFT OUTER JOIN Ticket ON Ticket.seat_id = Seat.id and Ticket.item_id = Item.id
WHERE Item.day = '01.01.2005' and City1.name = 'A' 
GROUP BY Item.id, Item.day, Flight.description, Seat.level

А еще так:

SELECT Item1.id, Item1.day, Item1.description, Seat.level, Count(Seat.id)-Count(Ticket.id) free_seats
FROM 
(SELECT Item.id, Item.day, Flight.description, Flight.crafttype_id FROM Item  
 INNER JOIN Flight ON Flight.id = Item.flight_id 
 INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id  
 INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id 
 WHERE Item.day = '01.01.2005' and City1.name = 'A' and City2.name = 'B') AS Item1
LEFT JOIN CraftType ON CraftType.id = Item1.crafttype_id 
LEFT JOIN Seat ON Seat.crafttype_id = CraftType.id 
LEFT OUTER JOIN Ticket ON Ticket.seat_id = Seat.id and Ticket.item_id = Item1.id
GROUP BY Item1.id, Item1.day, Item1.description, Seat.level

И множество других вариантов ...

По идее, различия между всеми вариантами построения такого запроса должны нивелироваться оптимизатором MS SQL. Но это далеко не всегда так. Достаточно посмотреть на планы двух первых приведенных выше запросов, чтобы увидеть важную деталь – MS SQL Server будет по-разному подходить к исполнению этих запросов.
Что же получается? Одну и ту же задачу мы можем решить десятью способами. Причем выбрать оптимальный способ будет не легко и делается это совершенно неочевидными методами. Сюда следует добавить и достаточно сложную систему индексов, которую нам прийдется создать для оптимизации исполнения нашего запроса (и этот набор индексов мы должны учитывать во время самого написания SQL-запроса).

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

И еще: Эффективность того или иного SQL-запроса во многом зависит от наличия в системе предопределенных индексов. Нельзя быть уверенным в преимуществах одного способа построения запроса над другими без знания состава этих индексов.

В качестве промежуточного вывода можно заметить, что указанные проблемы SQL практически не проявляются на простых запросах и при простой организации данных. В таких системах мы имеем возможность заранее определить почти 100% необходимых индексов, не перевышая при этом разумного их числа, оптимизаторы прекрасно справляются с обработкой запросов, написанных самыми разными способами (т.е. итоговые планы запросов совпадают), а сами исходные тексты SQL-запросов при их небольшой длине и сложности легко читаются и поддаются проверке. Проблемы начинаются при усложнении структуры данных и – как следствие - запросов к этим данным.

продолжение следует ...
8 фев 05, 18:22    [1308844]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Модель данных по версии SergSuper, ее отличия и недостатки

Содержание

Выше было много замечаний на предмет того, что используемая мною для примера на MS SQL модель данных совершенно искуственна, а решению задачи более соответствует более ранняя модель, предложенная SergSuper. Ну что же, давайте рассмотрим и эту модель поподробнее. Вот ее реализация для MS SQL Server (первый вариант):

CREATE TABLE Race (
       race                 int NOT NULL,
       caption              varchar(255) NULL,
       PRIMARY KEY (race ASC)
)

CREATE TABLE Fly (
       fly                  int NOT NULL,
       caption              varchar(255) NULL,
       PRIMARY KEY (fly ASC)
)

CREATE TABLE Shedul (
       race                 int NOT NULL,
       date                 char(10) NOT NULL,
       fly                  int NULL, 
       FOREIGN KEY (race)
       REFERENCES Race  (race), 
       FOREIGN KEY (fly)
       REFERENCES Fly  (fly),
       UNIQUE (
              race ASC,
              date ASC
       )
)

CREATE TABLE Sold (
       race                 int NULL,
       date                 char(10) NULL,
       class                int NULL,
       cnt                  int NULL,
       fio                  varchar(255) NULL,
       flag                 int NULL,
       price                money NULL, 
       FOREIGN KEY (race, date)
       REFERENCES Shedul  (race, date)
)

CREATE TABLE Place (
       fly                  int NULL,
       class                int NULL,
       cnt                  int NULL, 
       FOREIGN KEY (fly)
       REFERENCES Fly  (fly)
)

Замечу, кстати, что всячески пропагандируемое здесь c127 решение SergSuper не является ПОЛНЫМ и ПРАВИЛЬНЫМ хотя бы потому, что допускает двоякое толкование. Например, и следующая модель будет полностью соответствовать описанию:

CREATE TABLE Race (
       race                 int NOT NULL,
       caption              varchar(255) NULL,
       PRIMARY KEY (race ASC)
)

CREATE TABLE Fly (
       fly                  int NOT NULL,
       caption              varchar(255) NULL,
       PRIMARY KEY (fly ASC)
)

CREATE TABLE Shedul (
       race                 int NOT NULL,
       date                 char(10) NOT NULL,
       fly                  int NULL, 
       FOREIGN KEY (race)
       REFERENCES Race  (race), 
       FOREIGN KEY (fly)
       REFERENCES Fly  (fly)
)

CREATE TABLE Sold (
       race                 int NULL,
       date                 char(10) NULL,
       class                int NULL,
       cnt                  int NULL,
       fio                  varchar(255) NULL,
       flag                 int NULL,
       price                money NULL, 
       FOREIGN KEY (race)
        REFERENCES Race  (race)
)

CREATE TABLE Place (
       fly                  int NULL,
       class                int NULL,
       cnt                  int NULL, 
       FOREIGN KEY (fly)
       REFERENCES Fly  (fly)
)

Первая реализация мне нравится больше. Поэтому далее будем работать с ней. Напоминаю условие задачи:

Дано: дата d, маршрут [Z1, Z2]
Выдать таблицу (билеты в наличии): рейс - класс - кол-во мест

Теперь обратимся к тексту запроса, предложенного SergSuper:

select race, p.class, p.cnt-sum(isnull(cnt,0))
  from Shedul s 
  inner join Place p where s.fly=p.fly
  left join Sold d on d.race=s.race and d.date='нужная дата' and d.class=p.class  and d.flag=1
  where s.date='нужная дата' and s.race='нужный рейс'
  group by race, p.class, p.cnt

После исправления ОЧЕВИДНЫХ ОШИБОК в синтаксисе этот запрос будет выглядеть следующим образом:

select s.race, p.class, p.cnt-sum(isnull(d.cnt,0))
  from Shedul s 
  inner join Place p ON s.fly=p.fly
  left join Sold d on d.race=s.race and d.date='нужная дата' and d.class=p.class  and d.flag=1
  where s.date='нужная дата' and s.race='нужный рейс'
  group by s.race, p.class, p.cnt

Строго говоря, этот запрос не является решением поставленной задачи по двум параметрам. Один из них касается учета мест по номерам и уже упоминался мною выше (чтобы исправить эту недоработку больших изменений не потребуется и это уже было показано выше). Второй же дефект более фундаментален. В условии задачи маршрут (рейс) задается своим началом и концом (две точки). Из представленной структуры следует, что полное описание маршрута (рейса) будет храниться в поле caption таблицы Race. Таким образом, мы должны обращаться именно к этой таблице для идентификации рейсов. Казалось бы – ну что за ерунда – найди рейс в этой таблице да и подставь его идентификатор (race) в запрос на место конструкции ‘нужный рейс’. Но вот беда – представленная структура предполагает, что в таблице Race может появиться несколько записей с идентичным значением в поле caption (например, “A-B”). Это имеет место в том случае, когда в течение одного дня по одному маршруту (A-B) выполняется несколько полетов (в представленной структуре это будут разные рейсы и разные записи в таблице Race). Таким образом, приведенный выше запрос НЕВЕРЕН поскольку использует в качестве входных данных не вполне то, что предполагалось по условию задачи. Правильный запрос в такой структуре будет выглядеть следующим образом:

select s.race, p.class, p.cnt-sum(isnull(d.cnt,0)) free_place
  from Shedul s 
  inner join Place p ON s.fly=p.fly
  left join Sold d on d.race=s.race and d.date='дата' and d.class=p.class  and d.flag=1
  left join Race r on s.race = r.race
  where s.date='дата' and r.caption='нужный рейс'
  group by s.race, p.class, p.cnt

Что еще можно сказать о недостатках предложенной модели ? Записи таблицы Shedul в качестве уникального ключа фактически используют поля race и date. Аналогично и в таблице Sold поля race и date играют роль FOREIGN KEY, указывая на уникальную запись в таблице Shedul, к которой имеет отношение выписанный билет. Но это как-то нерационально. Зачем использовать ключ по двум полям. когда достаточно и одного. Ко всему прочему, при таком построении перенос даты рейса в расписании (например. с 01.01.2005 : 23-50 на 02.01.2005 : 00-10) не будет приводить к необходимости внесения изменений в таблицу Sold. Таким образом, мы можем убрать из таблицы Sold поля race и date, заменив их полем shedul, указывающим на поле (PK) с тем же названием в таблице Shedul. Заодно такой подход решает и проблему, показанную выше – теперь мы дейстительно сможем однозначно идентифицировать маршрут полета по идентификатору race.
Короче говоря, учет ряда аналогичных поправок (например, в отношении поля «номер места» в таблице Sold) приведет нас ровно к той модели, которая выше была использована в моем примере. Вот ряд пояснений и переименований полей и таблиц:

Sold -> Ticket
Sold.shedul -> Ticket.item_id
Sold.class -> Ticket.seat_id
Sold.fio -> Ticket.person_id + таблица Person (таблица Person позволяет вести учет различных атрибутов для пассажиров, таких как номер паспорта и т.п.)
Sold.price -> Ticket.cost

Fly -> Crafttype
Place -> Seat
Race -> Flight
Shedul ->Item

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

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

продолжение следует ...
8 фев 05, 18:23    [1308845]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Анализ исполнения сложного JOIN-запроса в MS SQL Server

Содержание

К моему сожалению, мало осмысленный спор с c127 об абстрактных достоинствах и недостатках различных SQL-решений увел нас от сравнения эффективности (быстродействия) решений на базе MS SQL и FastObjects. Однако, именно этот аспект мне кажется наиболее интересным. Как же провести такое сравнение? При столь различной архитектуре решений прямое сравнение быстродействия на больших массивах данных мне кажется весьма затруднительным (слишком сложно обеспечить равные условия, ввиду неопределенности критериев равенства этих условий). Поэтому единственным выходом я вижу анализ порядка исполнения запросов и программного кода, а также оценку объемов вычислений и пересылаемых данных. Для SQL-запросов в первую очередь можно взглянуть на планы этиз запросов, выдаваемые в SQL Query Analyzer.
Итак, проанализируем первый вариант запроса, представленный в моем решении, вот его план (для оптимизации работы запроса в БД были созданы различные индексы):

|---Compute Scalar(DEFINE:([Expr1014]=[Expr1012]-[Expr1013]))
2 |---Compute Scalar
    | (DEFINE:([Expr1012]=Convert([Expr1015]), 
    |          [Expr1013]=Convert([Expr1016])))
3   |---Stream Aggregate
      | (GROUP BY:([Item].[id], 
      |            [Flight].[description], 
      |            [Seat].[level])
      |  DEFINE:([Expr1015]=Count(*),
      |          [Expr1016]=COUNT_BIG([Ticket].[id]),   
      |          [Item].[day]=ANY([Item].[day])))
4     |---Nested Loops
        | (Left Outer Join, 
        |  OUTER REFERENCES:([Seat].[id],
        |                    [Item].[id]))
5       |---Sort
        | | (ORDER BY:([Item].[id] ASC,
        | |            [Flight].[description] ASC, 
        | |            [Seat].[level] ASC))
6       | |---Nested Loops
        |   | (Inner Join, 
        |   |  OUTER REFERENCES:([Flight].[crafttype_id]))
        |   |
7       |   |---Nested Loops
        |   | | (Inner Join, 
        |   | |  OUTER REFERENCES:([Flight].[id]))
        |   | |
8       |   | |---Nested Loops
        |   | | | (Inner Join, 
        |   | | |  OUTER REFERENCES:([Flight].[endpoint_id]))
        |   | | |
9       |   | | |---Nested Loops
        |   | | | | (Inner Join, 
        |   | | | |  OUTER REFERENCES:([Flight].[startpoint_id]))
        |   | | | |
10      |   | | | |---Clustered Index Scan
        |   | | | |  (OBJECT:([test1].[dbo].[Flight].[PK_Flight_(id)]))
11      |   | | | |---Index Seek
        |   | | |     (OBJECT:([test1].[dbo].[City].[PK_City_(id)] AS [City1]), 
        |   | | |      SEEK:([City1].[id]=[Flight].[startpoint_id] AND 
        |   | | |            [City1].[name]='A') ORDERED FORWARD)
12      |   | | |---Index Seek
        |   | |     (OBJECT:([test1].[dbo].[City].[PK_City_(id)] AS [City2]), 
        |   | |      SEEK:([City2].[id]=[Flight].[endpoint_id] AND 
        |   | |            [City2].[name]='B') ORDERED FORWARD)
13      |   | |---Index Seek
        |   |     (OBJECT:([test1].[dbo].[Item].[IX_Item_(day_flight_id)]), 
        |   |      SEEK:([Item].[day]='01.01.2005' AND 
        |   |            [Item].[flight_id]=[Flight].[id]) ORDERED FORWARD)
14      |   |---Clustered Index Seek
        |     (OBJECT:([test1].[dbo].[Seat].[IX_Seat_(crafttype_id)]),
        |      SEEK:([Seat].[crafttype_id]=[Flight].[crafttype_id]) ORDERED FORWARD)
15      |--Clustered Index Seek
             (OBJECT:([test1].[dbo].[Ticket].[IX_Ticket_(item_id)]),
              SEEK:([Ticket].[item_id]=[Item].[id]),  
                    WHERE:([Ticket].[seat_id]=[Seat].[id]) ORDERED FORWARD)

Что же мы видим? А видим мы:
1) 5 Nesteed Loops операций
2) 5 явно используемых индексов

А что такое Nested Loop?
Всякий раз, выполняя JOIN для двух таблиц (inner и outer) MS SQL делает следующее.
Для каждой записи в outer-таблице производится поиск соответствующих элементов в inner-таблице. Например, для п.9 (Nested Loop/Inner Join) это будет выглядеть так:
1) (п.10) По кластеризованному индексу PK_Flight_(id) выбирается элемент таблицы Flight
2) (п.11) В таблице City по определенным в ней индексам производится поиск всех элементов, удовлетворяющих условию
[City1].[id]=[Flight].[startpoint_id] AND [City1].[name]='A'

Ключевым здесь является слово ПОИСК. Аналогичный поиск имеет место для всех операций JOIN данного запроса. Таким образом при выполнении запроса имеет место как минимум пять операций поиска (пп. 11-15) по четырем разным индексам.
Возвращаясь к решению SergSuper, можно сказать, что и здесь Nested Loops будут не в единственном числе (три). Разумеется сокращение числа таблиц, суть – упрощение модели данных, уменьшает число JOIN-операций и Nested Loops при исполнении запроса.

продолжение следует ...
8 фев 05, 18:25    [1308849]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить