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

S>Что бы замять этот разговор то в зависимости от строение бд можно придумать строение ПК так, чтобы по нему можно было найти физический адрес.

Нельзя, потому что физический адрес меняется при расщеплении страницы и придется все FK в базе отыскивать и править.

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

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

S>>Что бы замять этот разговор то в зависимости от строение бд можно придумать строение ПК так, чтобы по нему можно было найти физический адрес.

AVK>Нельзя, потому что физический адрес меняется при расщеплении страницы и придется все FK в базе отыскивать и править.

Это еще при условии, что они все по FK лежат. А могут и без FK лежать

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

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

GZ>В Oracle если в like указана любая строка не начинающаяся с символа маски, то у нее есть полное право испольняться через индекс.
В MS SQL, afaik, тоже. НУ И ЧТО? Строка, не начинающаяся с маски, приводит опять же к расщеплению предиката. Ничего не меняется.
Я не понимаю, в чем проблема? Ты уже понял, что ограничение на длину ключа НЕ ПРИВОДИТ к ошибкам? Оно просто приводит к переключению на более дорогостоящие алгоритмы в некоторых особо неудачных случаях.

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

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

S>>Что бы замять этот разговор то в зависимости от строение бд можно придумать строение ПК так, чтобы по нему можно было найти физический адрес.

AVK>Нельзя, потому что физический адрес меняется при расщеплении страницы и придется все FK в базе отыскивать и править.
Может я чего не понимаю. ПК отвечает за быстрый поиск физического адреса в БД он неизменяем.
При этом он может сосуществовать совместно и с обычным ПК в Б+ дереве. Запись неподвижна внутри страницы. Как правило например в фокспро это так если конечно не делать упакоку, новые записи становятся на место удаленных (правда там индекс, но вполе можно использовать спписки).
Все зависит от организации БД. Там где БД ветвистая с большим количеством ссылок, такой подход оправдан.
При разного рода усечениях, легче переписать БД реструкуризовав её. Понимаю, что это утопия.

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

M>При этом у тебя в модели ошибочка по логике вещей должно быть:

А для демонтрации моих мыслей должно быть так как у меня было!

M>Так как адресов у клиента вполне может быть несколько.... И вся основная нагрузка ложится на аккуратно упорядоченный FK.

Блиииин , нафига ты изменил мою модель классов. Это же пример. Для изначальной модели и БД будет как раз как надо.
Мы же говорим про навигационный доступ. В первую очередь про "много-ко-одному" ассоциации, то есть ссылки, а не коллекции. Я же не отрицаю, что коллекции тоже бывают, но проблема то затронутая мной — она с одиночными ссылками. Так что их и обсуждать надо.

PS: длина ветки уже существенно превысила ее значимость.

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

S> При этом он может сосуществовать совместно и с обычным ПК в Б+ дереве. Запись неподвижна внутри страницы.
В случае если это записи в сортированной по индексу(с кластеризованным индексом) таблице, то при балансировке дерева записи перемещаются.

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

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

S>Блиииин , нафига ты изменил мою модель классов. Это же пример.
Значит надо было выбрать более удачный пример...

S> Для изначальной модели и БД будет как раз как надо.
Нет, будет как ненадо. В подавляющем большинстве практически применимых случаев по PK выбирается уникальная запись и далее идет выборка по FK из дочерних таблиц, классический пример Order/Detail.

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

S>Я же не отрицаю, что коллекции тоже бывают, но проблема то затронутая мной — она с одиночными ссылками. Так что их и обсуждать надо.
Это твоя проблема, а не та, которую мы обсуждаем. Если твоя задача именно такова как ты описываешь (в чем я честно говоря сомневаюсь), то скорее всего тебе больше подойдут ООБД, а не реляционные.

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

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

S>>А для демонтрации моих мыслей должно быть так как у меня было!
M>Понимаешь, за всю свою практику я не разу не встречался с такими задачами, как у тебя в мыслях..

Странно. Обычная ситуация когда надо показать список чего-нибудь. Список сотрудников, например, показать в сетке с дополнительными колонками: город, в котором он живет, отдел в котором работает, имя руководителя, которому подчиняется и т.п.
Тоже для отчетов.

M>В подавляющем большинстве практически применимых случаев по PK выбирается уникальная запись и далее идет выборка по FK из дочерних таблиц, классический пример Order/Detail.

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

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

Здесь существенная оговорка: в реальных приложениях, написанных как ты привык, и теми средствами, к которым ты привык.
А вот ты посмотри на просто приложения, без баз данных, там навигационного доступа значительно больше. А почему? А потому что это удобней и естественней.
А мы кстати обсуждаем настольные базы данных, в которых технические проблемы организации навигационного доступа совсем не такие, как в сетевой многопользовательской СУБД.

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

AVK>Это не ответ. Что касаемо FBEmbed, то это неудобная для десктопных задач БД.

А можно узнать почему? А то как раз надумываю использовать FB Embedded.

Спасибо

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

S>Странно. Обычная ситуация когда надо показать список чего-нибудь. Список сотрудников, например, показать в сетке с дополнительными колонками: город, в котором он живет, отдел в котором работает, имя руководителя, которому подчиняется и т.п.
Ты же показываешь не весь список сотрудников, а список сотрудников принадлежащих к какому-либо отделу... Вот и поехали, ID-отдела — FK в списке сотрудников.
И так всегда. Если записей мало, то скорость навигационного доступа не критична, если их много, то записи начинают фильтровать, причем, что характерно, последовательно.

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

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

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

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

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

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

PZT>А можно узнать почему? А то как раз надумываю использовать FB Embedded.

Подробности в форуме Janus

S>Здесь существенная оговорка: в реальных приложениях, написанных как ты привык, и теми средствами, к которым ты привык.
S>А вот ты посмотри на просто приложения, без баз данных, там навигационного доступа значительно больше. А почему? А потому что это удобней и естественней.
Нет, не поэтому. А потому, что в императивных языках программирования средства ассоциативного доступа отсутствуют. Точка. А средства навигационного доступа встроены прямо аж на уровне ассемблера.
В итоге программист специально вводит навигационные решения для задач ассоциативного доступа. Ну вот типа сначала ему надо ассоциировать адрес с юзером, и он заводит в юзере указатель на адрес. Потом ему надо заниматься поиском юзеров по адресу, и он сначала делает поиск в списке адресов, потом приделывает к списку адресов хештаблицу "текст адреса"->адрес, потом делает сканирование коллекции юзеров в поисках ссылающихся на данный адрес, потом он думает, что это неэффективно, и вводит бимэп userID<->addressId... И все только от того, что нету у него встроенных средств записать select * from users where address.city = @city.
В большинстве случаев ассоциативный доступ удобнее.
S>А мы кстати обсуждаем настольные базы данных, в которых технические проблемы организации навигационного доступа совсем не такие, как в сетевой многопользовательской СУБД.

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

S>>Странно. Обычная ситуация когда надо показать список чего-нибудь. Список сотрудников, например, показать в сетке с дополнительными колонками: город, в котором он живет, отдел в котором работает, имя руководителя, которому подчиняется и т.п.
M>Ты же показываешь не весь список сотрудников, а список сотрудников принадлежащих к какому-либо отделу...

Ты хоть прочитай, что я показываю. Я показываю список сотрудников (неважно по какому критерию отфильтрованный) и вместе с ним НЕСКОЛЬКО дополнительных колонкок в сетке — отдел, город и т.п. Если бы я показывал сотрудников одного отдела, то нафига мне дополнительная колонка в сетке показывающая этот (и так известный) отдел.

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

Да не все делается через коллекции. В этом-то и фишка. Есть и коллекции и одиночные ссылки. Все тот-же пример:

int P()
{
    int res = 0;
    foreach (auto i in (from Clients where ...))
        res += M(i);
    return res;
}

int M(Client client)
{
    if (client.address.street = 'блабла')
        return 1;
    return 0;
}

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

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

Тогда и нефиг было начинать обсуждение особенностей настольных СУБД.

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

А не сидим то не потому что не хотим, а из-за технических проблем реализации.

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

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

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

S>В большинстве случаев ассоциативный доступ удобнее.

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

Но проблема-то в том, что логика не может писаться, чтобы быть одновременно эффективной как для императивного исполнения так и для использования в оптимизаторе запросов. Вследствие чего оптимизатор курит в сторонке и мы почти что имеем полный перебор. А самое главное, что поведение системы становиться непредстказуемым: до изменения логики оптимизатор хорошо работал, а после небольшого изменения — вырубился.

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

S>Ты хоть прочитай, что я показываю.
Я читаю, и читаю я, что ты все время какие-то искуственные задачи приводишь...

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

S>Да не все делается через коллекции. В этом-то и фишка. Есть и коллекции и одиночные ссылки. Все тот-же пример:
Фишка в том, что не все, но большинство. Причем одна навигационная операция — не проблема, а вот с коллекциями надо работать наиболее оптимальным образом.

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

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

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

S>Тогда и нефиг было начинать обсуждение особенностей настольных СУБД.
Ну во-первых это не ко мне, во-вторых у настольных есть другие особенности, но с паттерном доступа они мало связаны.
Если бы затык был в навигации, то надо было бы писать ООБД, а не реляционку.

S>А не сидим то не потому что не хотим, а из-за технических проблем реализации.
Так что же это за такие технические проблемы, если навигационный доступ такой замечательный?

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

S>Вот если бы можно было функции основного языка в запросы вставлять, тогда да.
Такой есть SQLJ, например.

S>Да только такой движок сам по себе для выполнения запросов стал бы активно использовать доступ по ключу и т.п. Так что в сущности — одно и тоже.
Ничего подобного, лучше SQL-я для работы с данными пока что ничего нет, не смотря на все потуги и никакого доступа по ключу не намечается.
Еще раз тебе говорю, перестань обращаться с данными как с объектами, ни к чему хорошему это не приведет.

S>А так получается большуууущий геморроище:
Это все от неумения готовить..

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

S>Нет, не поэтому. А потому, что в императивных языках программирования средства ассоциативного доступа отсутствуют. Точка. А средства навигационного доступа встроены прямо аж на уровне ассемблера.
S>В итоге программист специально вводит навигационные решения для задач ассоциативного доступа. Ну вот типа сначала ему надо ассоциировать адрес с юзером, и он заводит в юзере указатель на адрес. Потом ему надо заниматься поиском юзеров по адресу, и он сначала делает поиск в списке адресов, потом приделывает к списку адресов хештаблицу "текст адреса"->адрес, потом делает сканирование коллекции юзеров в поисках ссылающихся на данный адрес, потом он думает, что это неэффективно, и вводит бимэп userID<->addressId... И все только от того, что нету у него встроенных средств записать select * from users where address.city = @city.
Извиняюсь, не могу сдержаться.
Во первых ты говоришь не о доступе как таковом, а о поиске. Что является лишь частью доступа. Во вторых, всех так на курсоры тянем что у меня есть сомнения в декларативном доступе. А тянет всех потому как нельзя в sql запросе указывать сложную логику зависящую от состояния читаемого объекта(даешь в sql делегаты, хотя и они могут не спасать). В третьих, sql так построен, что дальше навигации с курсором особо не уйдешь. В пятых, у меня как бич получается, что на каждом проекте мне приходится в той. или иной мере реализовывать редактор sql запросов. В шестых, весьма удобно отойти от отношения как такового, а перейти к навигации в определенных случаях. Например у тебя форма. Обычно данные в такой форме есть дерево по которому в случае навигационного доступа было бы удобно бегать.
S>В большинстве случаев ассоциативный доступ удобнее.
В большинстве случаев удобнее оба варианта в смешанном состоянии.
S>>А мы кстати обсуждаем настольные базы данных, в которых технические проблемы организации навигационного доступа совсем не такие, как в сетевой многопользовательской СУБД.
Ага, там единственная проблема, она не sql, и под sql никак не клеится.

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

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

S>> При этом он может сосуществовать совместно и с обычным ПК в Б+ дереве. Запись неподвижна внутри страницы.
GZ>В случае если это записи в сортированной по индексу(с кластеризованным индексом) таблице, то при балансировке дерева записи перемещаются.

Разумеется это некасается кластерного индекса. Кроме того никто не зпрещает иметь две таблицы обычную и кластерную для для более быстрого поиска и чесе по диапозону индекса. При ЭТОМ ССылка на элемент может состоять из двух записей и применяться либо Б+ дерево либо прямая (на самом деле косвенная но с бытрым поиском нужной страницы RID). Излищняя избыточность но более быстрый переход по ссылке.

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

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

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

С ростом мощи машин следует признать, что лучшей универсальной настольной БД д.б. признан[а|о] Windows Registry. Реестр, в общем.

Посудите сами:

>1) in process или out of process?

Неважно

>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc

Неважно

>3) Описание метаданных

Полагаю, что для домашней БД важен принцип KISS. оставим метаданные ораклу.

>4) Способ формирования запросов

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

>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом

Если нужен контроль — пишется обёртка. Хоть бы и SQL реализующая, во!
Зато есть встроенный контроль доступа из коробки! Интегрированный с системой безопасности Windows!

>6) Алгоримты деплоймента

Стандартизованные де-факто *.reg файлы для бэкапа и переноса данных!
Движок уже предустановлен на всех Windows, включая мобильные!

Все на использование реестра!

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

D>Если нужен контроль — пишется обёртка. Хоть бы и SQL реализующая, во!
D>Зато есть встроенный контроль доступа из коробки! Интегрированный с системой безопасности Windows!

>>6) Алгоримты деплоймента

D>Стандартизованные де-факто *.reg файлы для бэкапа и переноса данных!
D>Движок уже предустановлен на всех Windows, включая мобильные!

D>Все на использование реестра!
D>
На Symbian что делать?
Уж лучше свой XML-движок БД написать.