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

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

Я не описываю случай "мастер-деталь". НЕ ОПИСЫВАЮ! Если ты хочешь поговорить об этом — заведи отдельную ветку. Мой пример о другом. И нефиг переводить стрелки .

S>>А вот теперь представь, что метод M() содержит сложную логику с вызовом виртуальных методов и т.п. и вообще половину ее писал не ты.
M>Тогда это проблемы метода M, и за такую архитектуру к компу не подпускать..



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

В конечном итоге любая программа — это машинные коды. И значит надо просто правильно написать их !
Только почему же никто так не делает, а?

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

Да ну. Вот такие запросы, которые как ты говоришь, не предназначены для работы с логикой, ты же сам называешь естественными. Когда ты искусственно разбиваешь модель прикладной программы на данные и объекты — это уже совсем не естественно.
Естественный ассоциативный доступ — это запросы к объектному представлению с использованием логики. Запросы к "данным" да еще и без логики — не естественны. И навигационный доступ намного более естественный ем такие запросы. О чем я и говорил .

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

С паттерном доступа они как раз хорошо связаны. Внутри обычной СУБД в планах выполнения запросов часто встречается UNIQUE INDEX UNIQUE SCAN, что есть суть доступ по ключу. Однако это внутри! Так как между клиентом и сервером — сеть и толстый API. А для настольной СУБД — запросто можно вынести и наружу, таким образом получив фактически быстрый навигационный доступ.

M>Сосредоточься и отдели у себя в голове данные от объектов, навигационный доступ удобен для объектов, а не для данных, с данными все наоборот. Как только отделить одно от другого, все сразу станет на свои места, не надо заставлять данные думать.

А зачем мне десять разных представлений модели прикладной области? Да еще и разных по смыслу, как ты тут заявляешь.

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

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

S>>>> При этом он может сосуществовать совместно и с обычным ПК в Б+ дереве. Запись неподвижна внутри страницы.
GZ>>>В случае если это записи в сортированной по индексу(с кластеризованным индексом) таблице, то при балансировке дерева записи перемещаются.
S>>Разумеется это некасается кластерного индекса.
GZ>Нет не только кластерного. В случае если у нас запись имеет поле с изменяемой длиной, то при расширении запись может уже не помещаться на текущей таблице, и как результат его нужно будет переносить на другую страницу. И тогда все индексы нужно обновлять.
S>>Излищняя избыточность но более быстрый переход по ссылке.
GZ>Почти соглашусь. Однако у нас получатся еще и другие накладные расходы(одно то, что нам придется постоянно добывать типизированные объекты из byte[] чего-то стоят). Как бы при этих накладных расходах разность в работе этих фич не стремились к нулю. Поэтому максимум чем можно так абстрактно(но более точно) измерять — количество чтений-записей.

ну получить тип по &byte[0] не проблема, просто ссылка на структуру. Но про указатели мы не забываем. То бишь ничего не стоит. Практика это доказывает. В нативе вообще проще т.к. просто копирование в типизированный буффер (структуру).
GZ>Но косвенность любого индекса — это ключевое слово.
Разные уровни этой коственности. Например в фокспро для увеличения емкости ключи хранятся запакованными (логично для сортированных строк).
Итд. При этом прямая ссылка более подходящий способ хранения в объекие, чем хранения ссылки через промежуточный объект

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


S>>>>> При этом он может сосуществовать совместно и с обычным ПК в Б+ дереве. Запись неподвижна внутри страницы.
GZ>>>>В случае если это записи в сортированной по индексу(с кластеризованным индексом) таблице, то при балансировке дерева записи перемещаются.
S>>>Разумеется это некасается кластерного индекса.
GZ>>Нет не только кластерного. В случае если у нас запись имеет поле с изменяемой длиной, то при расширении запись может уже не помещаться на текущей таблице, и как результат его нужно будет переносить на другую страницу. И тогда все индексы нужно обновлять.
S>>>Излищняя избыточность но более быстрый переход по ссылке.
GZ>>Почти соглашусь. Однако у нас получатся еще и другие накладные расходы(одно то, что нам придется постоянно добывать типизированные объекты из byte[] чего-то стоят). Как бы при этих накладных расходах разность в работе этих фич не стремились к нулю. Поэтому максимум чем можно так абстрактно(но более точно) измерять — количество чтений-записей.
Нужно отметить еще то, что при этом ты получаешь большую гибкость приеняя к объектам все тодступныеме методы для работы с ними (регулярные выражения,CSV для строк итд) Даже тупо потери при нормальной сериализации достаточно малы, учитывая получаемые бенефиты.
S> ну получить тип по &byte[0] не проблема, просто ссылка на структуру. Но про указатели мы не забываем. То бишь ничего не стоит. Практика это доказывает. В нативе вообще проще т.к. просто копирование в типизированный буффер (структуру).
GZ>>Но косвенность любого индекса — это ключевое слово.
S> Разные уровни этой коственности. Например в фокспро для увеличения емкости ключи хранятся запакованными (логично для сортированных строк).
S>Итд. При этом прямая ссылка более подходящий способ хранения в объекие, чем хранения ссылки через промежуточный объект

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

S>Я не описываю случай "мастер-деталь". НЕ ОПИСЫВАЮ! Если ты хочешь поговорить об этом — заведи отдельную ветку. Мой пример о другом. И нефиг переводить стрелки .
Значит варианта два. Либо твоя задача — большое исключение и не для реляционных БД, либо ты ее неправильно описываешь, поскольку 99% задач сводятся к master/detail...

S>В конечном итоге любая программа — это машинные коды. И значит надо просто правильно написать их !
S>Только почему же никто так не делает, а?
Почему не делают? Делают.

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

S>Естественный ассоциативный доступ — это запросы к объектному представлению с использованием логики.
Не ищи естественности там где ее нет.

S> Запросы к "данным" да еще и без логики — не естественны.
Хм, я вообще не понимаю, когда ты начинаешь оперировать категориями "естественности", может из-за этого и все проблемы?

S>И навигационный доступ намного более естественный ем такие запросы.
То-то ты с ним такие проблемы имеешь.

S>Внутри обычной СУБД в планах выполнения запросов часто встречается UNIQUE INDEX UNIQUE SCAN, что есть суть доступ по ключу.
Часто, но не на столько часто, чтобы быть узким местом.

S> А для настольной СУБД — запросто можно вынести и наружу, таким образом получив фактически быстрый навигационный доступ.
Зачем, если и так все хорошо? Пойми-ты. Не нужен никому быстрый навигационный доступ. Точнее так — навигационный доступ, как правило, и так достаточно быстр, он отнюдь не самое узкое место, если его таковым искуственно не делать, чам, похоже ты в своей задаче и занимаешься.

S>А зачем мне десять разных представлений модели прикладной области? Да еще и разных по смыслу, как ты тут заявляешь.
Ты в серьез полагаешь, что модель данных можно сделать один-в-один с объектной? Более не "естественноую" конструкцию, пожалуй будет сложно придумать.
Там даже принципы организации моделей совершенно противоположные, объекты — лишь один из способов представления данных...
Хочешь простоты и единой модели — бери ООБД, сплошной навигационный доступ, но не говори потом, что я не предупреждал.

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

M>Значит варианта два. Либо твоя задача — большое исключение и не для реляционных БД, либо ты ее неправильно описываешь, поскольку 99% задач сводятся к master/detail...

Я так не считаю. Выражаясь терминами UML, ты утверждаешь, что 99% ассоциаций — это аггрегации, и, соответственно оставшийся 1% — просто ассоциации. Чушь! Возми для примера AST для C# и посчитай.

S>>В конечном итоге любая программа — это машинные коды. И значит надо просто правильно написать их !
S>>Только почему же никто так не делает, а?
M>Почему не делают? Делают.

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

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

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

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

А мои примеры ничего плохого-то не показывают...

M>Не ищи естественности там где ее нет.

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

M>Хм, я вообще не понимаю, когда ты начинаешь оперировать категориями "естественности", может из-за этого и все проблемы?

Странно, что не понимаешь. Ведь это же твои слова, что ассоциативный доступ более естественный, чем навигационыый .

S>>И навигационный доступ намного более естественный ем такие запросы.
M>То-то ты с ним такие проблемы имеешь.

Нет у меня проблем. Любая технология, пытающаяся автоматизировать что-либо вполне может быть сложной. Возми GC, для примера.
Реализация сложная — использование простое. Стандартная ситуация.

S>> А для настольной СУБД — запросто можно вынести и наружу, таким образом получив фактически быстрый навигационный доступ.
M>Зачем, если и так все хорошо? Пойми-ты. Не нужен никому быстрый навигационный доступ. Точнее так — навигационный доступ, как правило, и так достаточно быстр, он отнюдь не самое узкое место, если его таковым искуственно не делать, чам, похоже ты в своей задаче и занимаешься.

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

S>>А зачем мне десять разных представлений модели прикладной области? Да еще и разных по смыслу, как ты тут заявляешь.
M>Ты в серьез полагаешь, что модель данных можно сделать один-в-один с объектной? Более не "естественноую" конструкцию, пожалуй будет сложно придумать.
M>Там даже принципы организации моделей совершенно противоположные, объекты — лишь один из способов представления данных...

Да делай ее какой хочешь. Главное — она есть просто способ сохранить/восставовить состояние объектной модели. И поэтому она не должна мозолить мне глаза на уровне работы с объектной моделью, т.е. на уровне логики.

M>Хочешь простоты и единой модели — бери ООБД, сплошной навигационный доступ, но не говори потом, что я не предупреждал.

Как я уже говорил, я за смешанный тип. Должен присутствовать и навигационный доступ и все прелести реляционной БД.

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

S> ну получить тип по &byte[0] не проблема, просто ссылка на структуру. Но про указатели мы не забываем. То бишь ничего не стоит. Практика это доказывает. В нативе вообще проще т.к. просто копирование в типизированный буффер (структуру).
Нет. Не только это. Ты должен хранить типизированные значения в одном месте, а кэш страниц в другом. В наиболее криминальном случае нагрузка на память можно умножать на 2.

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

S>Я так не считаю.
Твое право.

S> Выражаясь терминами UML, ты утверждаешь, что 99% ассоциаций — это аггрегации, и, соответственно оставшийся 1% — просто ассоциации.
Во-первых я говорил совсем другое, а во-вторых, причем тут UML?

S>Чушь!
Ну ты понял..

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

S>Данные — это просто технический слой, необходимый для сохранения/восстановления состояния программы. И все!
Не, мужик, все совсем не так. Я бы даже сказал строго наоборот. Твоя программа может измениться 10 раз, полностью поменяется объектная модель и ее предназначение, а данные останутся тми же самыми... Так что данные первичны, а твоя программа всего лишь фантик, который можно раскрасить как тебе нравится, потом выкинуть и навернуть другой, поверх той же самой конфетки с данными.

S> И чем прозрачней этот слой — тем лучше.
В этом-то и есть твое основное заблуждение.

S>Разделение, о котором ты говоришь, обуславливается лишь текущим состоянием технологий, и никак не является филосовской самоцелью.
С этим никто не спорит, но с текущим состоянием технологий приходится мириться.

S>А мои примеры ничего плохого-то не показывают...
Здрасьте, а кто тут плакался по поводу потрясающий производительности навигационного доступа?

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

S>Странно, что не понимаешь. Ведь это же твои слова, что ассоциативный доступ более естественный, чем навигационыый .
Нет, про "естественность" это все твое, я просто пытаюсь пользоваться твоей терминологией, чтоы понятнее было.

S>Нет у меня проблем.
Тогда о чем разговор? Значит проблем с навигационным доступом таки нет.

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

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

S>Главное — она есть просто способ сохранить/восставовить состояние объектной модели. И поэтому она не должна мозолить мне глаза на уровне работы с объектной моделью, т.е. на уровне логики.
Да вторична твоя логика, вместе с объектной моделью. Это, кстати, вечная проблема кривых ORM-ов, которые пытаются забыть про данные и делать все по объектному, чтобы было "прозрачно", а надо ровно наоборот. Посмотри на DLinq, вот там они как раз пляшут в первую очередь от данных и подгоняют объекты под данные, получая, так вожделенную тобой прозрачность, но уже с правильной стороны.

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

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

S>

S>select * from A left join B on B.pk = A.fk
S>

S>Может по таблице A и последовательно, а по B — с поиском по ключу (UNIQUE INDEX UNIQUE SCAN), а потом еще и доступ к записи в таблице B по найденному в индексе rowid (тоже не последовательно по отношению к физическому хранению).
S>Что, не так скажешь?
Нет, конечно же не так. Да, иногда задача сводится к подъему связанных записей из справочников. Но как только потребуется наложить нетривиальное условие на B, навигационный доступ тут же уйдет курить. А ассоциативный сможет применить другой набор индексов; причем порядок применения предикатов будет определяться не только самой формулировкой задачи, но также и статистикой — если B, удовлетворяющих предикату, значительно меньше, чем A, то никаких последовательных вытаскиваний B по ключу из A не будет.
Именно поэтому умные дяди двадцать пять лет назад отказались от сетевых СУБД — реляционка не хуже них выполняет unique index unique scan. Мы можем оформить запрос select * from B where B.pk = @key в как-бы-навигационном виде. Но это декорация, и совершенно не факт, что ее стоит делать удобной в применении. Потому как это будет провоцировать разработчиков на использование навигационного доступа, что вставляет палки в колеса оптимизатора. Косяк в том, что с системой, написанной в навигационном стиле, практически ничего полезного сделать нельзя. Только переписать. А система, построенная в виде декларативного описания трансформаций хранимых данных в выдаваемые данные, можно еще очень много всего сделать. Мне не очень нравится сам по себе SQL из-за слабых возможностей декомпозиции.

В современной реляционной системе можно пойти намного дальше. В частности, реализация ленивой семантики в реляционных выражениях может существенно сэкономить усилия по повторному использованию. Опять же, можно снять проблемы с динамическим построением запросов в зависимости от наличия/отсутствия ограничений. Современные реализации SQL идут в этом плане очень недалеко: можно определять view, но это жутко статические сущности. Можно применять временные таблицы, но у них "шустрая" семантика, и оптимизатору негде развернуться.

В нормальной системе я могу объявить переменную типа "реляция", могу динамически построить из нее выражение, могу передать это выражение дальше, а могу просто исполнить. Можно будет решить, откуда выбирать данные в одном месте, выбрать фильтр для применения к ним в другом, а порядок сортировки определить в третьем.

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

Здравствуйте, GlebZ, Вы писали:
GZ>Извиняюсь, не могу сдержаться.
GZ>Во первых ты говоришь не о доступе как таковом, а о поиске.
Ну, в принципе да. У тебя есть альтернативное определение термина "доступ"?
GZ>Что является лишь частью доступа. Во вторых, всех так на курсоры тянем что у меня есть сомнения в декларативном доступе. А тянет всех потому как нельзя в sql запросе указывать сложную логику зависящую от состояния читаемого объекта(даешь в sql делегаты, хотя и они могут не спасать).
Гм. В этом месте не понял. SQL предназначен для того, чтобы выполнять операции с данными. Никаких объектов там нет. Есть кортежи. При этом сложную логику, зависящую от состояния кортежа, в SQL вполне можно использовать. Хотя, конечно же, применение индексов существенно затрудняется сложными выражениями (читай — делается невозможным). Низкая производительность самих по себе выражений лежит исключительно на совести реализаторов — никто не мешает в движке SQL скомпилировать выражение 2*a*a + SQRT(b) / с прямо в нативный код, а не париться с интерпретацией.
GZ>В третьих, sql так построен, что дальше навигации с курсором особо не уйдешь.
Вина SQL в том, что это диалоговый язык. Убил бы того, кто это придумал. Результатом стейтмента Select должна быть не отправка резулт сета в трубу, а выражение реляционного типа.
Что-то вроде табличной переменной в MS SQL, только без выполнения запроса. Чтобы можно было делать так:

declare @a (id int, code int)
set @a = select id, type from sysobjects
if not @type is null
  set @a = select * from @a where type = @type 
return @a

Все как в функциональных языках — берем ленивые выражения, строим из них другие и т.п. И только когда нам наконец понадобились сами данные, отдаем запрос на выполнение.
GZ>В пятых, у меня как бич получается, что на каждом проекте мне приходится в той. или иной мере реализовывать редактор sql запросов.
А это ты к чему? Сложности редактирования сами по себе слабо связаны с SQL. Их суть в том, что сам запрос надо рассматривать как объект. Что, впрочем, вполне противоречит принятому в SQL идиотизму с желанием как можно быстрее перейти "от слов к делу", точнее от текста запроса к табличке с данными.
GZ>В шестых, весьма удобно отойти от отношения как такового, а перейти к навигации в определенных случаях. Например у тебя форма. Обычно данные в такой форме есть дерево по которому в случае навигационного доступа было бы удобно бегать.
Это я тоже не очень понимаю. Навигация суть частный случай поиска по первичному ключу.

S>>>А мы кстати обсуждаем настольные базы данных, в которых технические проблемы организации навигационного доступа совсем не такие, как в сетевой многопользовательской СУБД.
GZ>Ага, там единственная проблема, она не sql, и под sql никак не клеится.

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

S>> Выражаясь терминами UML, ты утверждаешь, что 99% ассоциаций — это аггрегации, и, соответственно оставшийся 1% — просто ассоциации.
M>Во-первых я говорил совсем другое, а во-вторых, причем тут UML?

UML для того, чтобы обозначить термины. А что другое ты говорил. Чем оно отличается от этого?

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

S>В нормальной системе я могу объявить переменную типа "реляция", могу динамически построить из нее выражение, могу передать это выражение дальше, а могу просто исполнить. Можно будет решить, откуда выбирать данные в одном месте, выбрать фильтр для применения к ним в другом, а порядок сортировки определить в третьем.

Это вот очень правильная тема. Я тоже над этим давно думаю .

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

Я считаю так: запросы (и переменные типа "реляция") — это более высокий уровень. Императивная программа (и навигационный доступ) — более низкий (обработка результатов запросов).
Полностью от навигационного доступа избавляться нельзя — страдает модульность, особенно в условиях OO пардигмы с наличием полиморфизма.

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

S> А что другое ты говорил. Чем оно отличается от этого?
Я говорил, что 99% сводится к master/detail, а так как в SQL-е нет наследования и прочих прелестей ОО, то и получается master/detail по факту — это к вопросу о разных моделях в ОО и реляционке.

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

M>Я говорил, что 99% сводится к master/detail, а так как в SQL-е нет наследования и прочих прелестей ОО, то и получается master/detail по факту — это к вопросу о разных моделях в ОО и реляционке.

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

Здравствуйте, stalcer, Вы писали:
S>Я считаю так: запросы (и переменные типа "реляция") — это более высокий уровень. Императивная программа (и навигационный доступ) — более низкий (обработка результатов запросов).
Вот мне совершенно непонятно, что именно ты имеешь в виду под обработкой результатов запроса. Если мы говорим о реляционном запросе, то вся обработка сводится к последовательному перебору кортежей.
Если мы говорим о некоторой иерархии, которая является результатом запроса, то ее логично представлять в виде XML — т.к. для него есть как произвольный доступ, так и однонаправленный последовательный перебор, а также механизмы декларативных запросов и трансформаций.
S>Полностью от навигационного доступа избавляться нельзя — страдает модульность, особенно в условиях OO пардигмы с наличием полиморфизма.
А можно раскрыть этот тезис поподробнее? В каком месте навигационный доступ поможет модульности?

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

S>Ну, в принципе да. У тебя есть альтернативное определение термина "доступ"?
Просто для него существует так же update, delete и insert.

S>Гм. В этом месте не понял. SQL предназначен для того, чтобы выполнять операции с данными. Никаких объектов там нет. Есть кортежи. При этом сложную логику, зависящую от состояния кортежа, в SQL вполне можно использовать. Хотя, конечно же, применение индексов существенно затрудняется сложными выражениями (читай — делается невозможным). Низкая производительность самих по себе выражений лежит исключительно на совести реализаторов — никто не мешает в движке SQL скомпилировать выражение 2*a*a + SQRT(b) / с прямо в нативный код, а не париться с интерпретацией.
Такие простые выражения — да. Но если посложней, то уже идет переход на курсоры. А курсоры — это навигационный доступ. Я сомневаюсь что можно построить язык запросов который мог бы удовлетворить все вычислимые задачи.

S>Вина SQL в том, что это диалоговый язык. Убил бы того, кто это придумал. Результатом стейтмента Select должна быть не отправка резулт сета в трубу, а выражение реляционного типа.
S>Что-то вроде табличной переменной в MS SQL, только без выполнения запроса. Чтобы можно было делать так:
S>

S>declare @a (id int, code int)
S>set @a = select id, type from sysobjects
S>if not @type is null
S>  set @a = select * from @a where type = @type 
S>return @a
S>

Хорошая весчь. Прям XQuery(который в действительности умеет работать с реляционными данными). Я как-то продумывал математику на такую шнягу на основе Фегараса. Ну для чистого sql эта вещь не слишком. Лучше делать язык который учитывает сразу взаимосвязи.

S>Все как в функциональных языках — берем ленивые выражения, строим из них другие и т.п. И только когда нам наконец понадобились сами данные, отдаем запрос на выполнение.
+1

S>А это ты к чему? Сложности редактирования сами по себе слабо связаны с SQL. Их суть в том, что сам запрос надо рассматривать как объект. Что, впрочем, вполне противоречит принятому в SQL идиотизму с желанием как можно быстрее перейти "от слов к делу", точнее от текста запроса к табличке с данными.
Это к вопросу о навигации. Фактически для любой функциональности надо иметь некоторое дерево(или связанный граф). Фактически, легко ассоциативно найти корень дерева(или набор корней) и после пройтись от объекта к объекту. В случае SQL такие проходы(а их бывают очень много) выливаются в генерацию SQL.

GZ>>В шестых, весьма удобно отойти от отношения как такового, а перейти к навигации в определенных случаях. Например у тебя форма. Обычно данные в такой форме есть дерево по которому в случае навигационного доступа было бы удобно бегать.
S>Это я тоже не очень понимаю. Навигация суть частный случай поиска по первичному ключу.
Ну не всегда. Навигация по foreign key еще может быть. Но в случае применения навигационного доступа, я вполне могу гулять как захочу без sql.

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

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

S>Но навигация вредит всему этому. Она слишком императивна, и требует от разработчика слишком точного представления о том, как именно устроены данные, с которыми он работает.
Вопрос 1 — чем может помешать оптимизатору навигационный доступ в локальной системе? Я согласен на иное, что оптимизатор мешается и слишком избыточен для навигационного доступа.
Вопрос 2. Такое впечатление что ты когда говоришь о навигационном доступе, говоришь о проходах на физическом уровне. Это действительно, очень нехорошо. Но если говорить о проходах на логическом уровне (который потом уже будет трансформирован в физический) то проблем не вижу.

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

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

S>> ну получить тип по &byte[0] не проблема, просто ссылка на структуру. Но про указатели мы не забываем. То бишь ничего не стоит. Практика это доказывает. В нативе вообще проще т.к. просто копирование в типизированный буффер (структуру).
GZ>Нет. Не только это. Ты должен хранить типизированные значения в одном месте, а кэш страниц в другом. В наиболее криминальном случае нагрузка на память можно умножать на 2.
Это касается только ссылочных типов. Доступ осуществляется через свойства, и выделение из поля объекта по требованию, если объект нужен кратковременно, то в зависимости от версии GC мы теряем время только на десериализацию которая ничтожна. Зачем хранить все прочитанные объекты???
У нас настольная БД раз, ничего кэшировать не надо (а со страницами Файловая сиситема хорошо сама справляется).
Для примера 1С работает по такому принципу и большинство удовлетворяет, а основные потери связаны отнють не с десериализацией.

Здравствуйте, GlebZ, Вы писали:
S>>Ну, в принципе да. У тебя есть альтернативное определение термина "доступ"?
GZ>Просто для него существует так же update, delete и insert.
А-а. Ну, тут понятия "ассоциативности" несколько размываются. Сама по себе реляционная алгебра ничего о модификациях не говорит.
С точки зрения практики, все же есть некоторые "настоящие" отношения, которые собственно хранятся, а есть результаты вычисления выражений.
Вся ассоциативность операций сводится к:
— для удаления: отбор кортежей на основе декларативно заданного предиката, вместо прямого указания "удали вот это"
— для вставки: формирование множества кортежей, которые манием руки объявляются "отныне существующими", опять же вместо вставки чего-то куда-то.
— для обновления вообще все сложно. Нужно указать сразу как множество жертв операции, так и собственно действие, которое над ними нужно совершить.

GZ>Такие простые выражения — да. Но если посложней, то уже идет переход на курсоры.
Ну например?
GZ>А курсоры — это навигационный доступ. Я сомневаюсь что можно построить язык запросов который мог бы удовлетворить все вычислимые задачи.
А в чем собственно затык? Язык SQL уже собственно turing-complete.
GZ>Хорошая весчь. Прям XQuery(который в действительности умеет работать с реляционными данными).
Я XQuery собственно не знаю. Но с точки зрения функциональщины (где собственно выражения являются first-class citizens) SQL не слишком далеко убежал от Клиппера. Разве что результат операции по умолчанию не скидывается в новое персистентное отношение, а уезжает клиенту. Тьфу!
GZ>Я как-то продумывал математику на такую шнягу на основе Фегараса.
Очень хорошо.
GZ>Ну для чистого sql эта вещь не слишком.
Гм? Не уверен, но имхо это было бы весьма и весьма удобно.
GZ>Лучше делать язык который учитывает сразу взаимосвязи.
Ты имеешь в виду автоматизацию джойнов? Вроде select * from orders where order.Customer.Name like "Иванов%"?
S>>Все как в функциональных языках — берем ленивые выражения, строим из них другие и т.п. И только когда нам наконец понадобились сами данные, отдаем запрос на выполнение.
GZ>+1

GZ>Это к вопросу о навигации. Фактически для любой функциональности надо иметь некоторое дерево(или связанный граф).
Э-э? Я вот совершенно не уверен в справедливости данного утверждения. Это всего лишь один из способов достижения "любой функциональности". Вон, в Декларативном Программировании народ поопытнее меня, и вроде бы там упоминалось построение даже и интерактивных приложений на чисто функциональных языках, где навигации как таковой нету. Ну, может быть я и заблуждаюсь.
GZ>Фактически, легко ассоциативно найти корень дерева(или набор корней) и после пройтись от объекта к объекту. В случае SQL такие проходы(а их бывают очень много) выливаются в генерацию SQL.
Ну мы же говорим не о самом по себе SQL, а о том, что вместо указателей у нас могут быть связи, и собственно "проход" от объекта к объекту оформляется в виде подходящего запроса, сворачивающего граф в IEnumerable.
S>>Это я тоже не очень понимаю. Навигация суть частный случай поиска по первичному ключу.
GZ>Ну не всегда. Навигация по foreign key еще может быть.
А какие у нас еще есть случаи? Навигация — это либо разыменование ссылки, либо итерирование коллекции. Вариантов нет.
Собственно аналогом ссылки является PK, а коллекция суть результат некоторого запроса.
GZ>Но в случае применения навигационного доступа, я вполне могу гулять как захочу без sql.
Нет, просто в навигационном доступе намертво вшиты некоторые запросы. В частности прямая навигация по FK и обратная навигация (типа Order.Items).

GZ>Навигация в локальных системах ничего не стоит. Однако при реализации некоторый задач, чертовски удобная штука. Ессно, это не отрицает нужности ассоциативного поиска.
Ышшо рас: навигация суть частный случай ассоциативного поиска. С очень убогими ассоциациями

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

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

S>>Но навигация вредит всему этому. Она слишком императивна, и требует от разработчика слишком точного представления о том, как именно устроены данные, с которыми он работает.
GZ>Вопрос 1 — чем может помешать оптимизатору навигационный доступ в локальной системе?
Как это чем? Навигация — это физический план запроса. Это императивная конструкция, которая оперирует понятием ссылок. Навигация подменяет смысл операции ее выполнением. В результате эксплуатации навигация превращается в ритуал, которому тупо следует приложение, вместо того, чтобы отбросить все ненужное

GZ>Я согласен на иное, что оптимизатор мешается и слишком избыточен для навигационного доступа.
В тех случаях, когда навигационный доступ соответствует оптимальному плану запроса это так. Но как только оптимальность перестает быть действительной, только оптимизатор имеет шанс выбрать альтернативный план.
GZ>Вопрос 2. Такое впечатление что ты когда говоришь о навигационном доступе, говоришь о проходах на физическом уровне.
Конечно.
GZ>Это действительно, очень нехорошо. Но если говорить о проходах на логическом уровне (который потом уже будет трансформирован в физический) то проблем не вижу.
А я вот не вижу, как это так можно сделать навигацию на "логическом уровне".
Ну вот простейший пример: Допустим, у нас есть модель "заказы и позиции". Эта модель очень удобна, если нам нужно найти заказы конкретного заказчика (Customer.Orders) и распечатать сами заказы (Order.Items). Но как только у нас появляется задача выбрать всех, кто купил слона, приходится писать вот так:

foreach(Customer с in AllCustomers)
  foreach(Order o in c.Orders)
      foreach(Item i in o.Items)
          if (i.Good = elephant)
              yield return c;

Мы выбрали конкретный путь навигации. Некому решить, что лучше сканировать сначала — кастомеров или айтемы.
Можно попробовать схитрить:

      foreach(Item i in AllItems)
          if (i.Good = elephant)
              yield return i.Order.Customer;

И скормить результат в оператор distinct. Но заранее неизвестно, будет ли это эффективнее.
Все, упес пипиндур. Для того, чтобы сделать динамический выбор возможным, нужно отказаться от принудительного характера foreach, и вместо этого сформулировать предикат, а не способ его выполнения.
Я не против того, чтобы предикат был записан в форме distinct Item.Order.Customer where Item.Good = elephant. Но это — не навигация. Это просто другое представление ассоциативного запроса.

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

S>>Полностью от навигационного доступа избавляться нельзя — страдает модульность, особенно в условиях OO пардигмы с наличием полиморфизма.
S>А можно раскрыть этот тезис поподробнее? В каком месте навигационный доступ поможет модульности?

public class A { public int x; }
public class B { public int y; }

public class CBase 
{
    public abstract bool M();
}

public C1: CBase
{
    public A a;
    public override bool M() { return (a.x != 0); } // Здесь.
}

public C2: CBase
{
    public B b;
    public override bool M() { return (b.y != 0); } // Здесь.
}

void Main()
{
    foreach (CBase obj in (select xt.* from C_Tab xt)) // Можно так.
        if (obj.M())
            ...;
            
    foreach (CBase obj in (select xt.* from C_Tab xt where xt.M())) // Можно и так. Все равно.
        ...;
}