Re[33]: Настольная БД
От: GlebZ Россия  
Дата: 11.04.06 06:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

GZ>>Вопрос 2. Такое впечатление что ты когда говоришь о навигационном доступе, говоришь о проходах на физическом уровне.

S>Конечно.
GZ>>Это действительно, очень нехорошо. Но если говорить о проходах на логическом уровне (который потом уже будет трансформирован в физический) то проблем не вижу.
S>Я не против того, чтобы предикат был записан в форме distinct Item.Order.Customer where Item.Good = elephant. Но это — не навигация. Это просто другое представление ассоциативного запроса.
Немного не так. Давай возьмем ту шнягу с ленивыми вычислениями что представил ты, и выделим логический и физический уровень. Допустим физический уровень — это чистый набор таблиц. И допустим логический уровень — это некоторый entity к которому в метаданных прописан запрос получения(можно взять за образец BLToolkit).
Итого:
val entity=from table1 inner join tablejoin on (bla-bla) select id, b, c

нам нужно получить entity2 который связан с аттрибутом с, как с.a, и идентификатор entity = 10
val entity=from table select id, b, c
val entity2=from table1 select id, e, f
var res=from entity2, entity where entity2.c=entity.id and entity.id=10 select entity

что выливается в запрос
select table1.* from table1 inner join tablejoin on (bla-bla) inner join table2 on (table1.c=table2.id) where table1=10

А так нравится?
И вся эта нехилая шняга в использовании будет проста
entity2=entity1.c

Вот такой вот синтаксический сахар.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[34]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 07:58
Оценка:
Здравствуйте, stalcer, Вы писали:
S>>А можно раскрыть этот тезис поподробнее? В каком месте навигационный доступ поможет модульности?
S>void Main()
S>{
S> foreach (CBase obj in (select xt.* from C_Tab xt)) // Можно так.
S> if (obj.M())
S> ...;
Абсолютное зло, потому как запрещает использование индексов, как бы ни были они придуманы
S> foreach (CBase obj in (select xt.* from C_Tab xt where xt.M())) // Можно и так. Все равно.
S> ...;
S>}
S>[/c#]
А здесь вообще нет никакой навигации. Впрочем, в первом примере никакой навигации тоже нет. Ты выполнил вполне ассоциативный запрос, а затем затеял некоторую дополнительную обработку. Ну и что? С тем же успехом ты мог заняться этим и для классического DataSet. Что характерно, ты сам же привел пример с полиморфизмом, в котором навигационный доступ не нужен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 07:58
Оценка:
Здравствуйте, GlebZ, Вы писали:
S>>В тех случаях, когда навигационный доступ соответствует оптимальному плану запроса это так. Но как только оптимальность перестает быть действительной, только оптимизатор имеет шанс выбрать альтернативный план.
GZ>Навигация не нужна для операции фильтрации 10 тысяч кортежей из пары миллионов при пяти джоинах. Это всего лишь простое и легкое получение связанных объектов. Можешь называть его синтаксическим сахаром для небольших данных.
Ничего не понимаю. Я же сказал уже трижды — навигация суть убогий частный случай ассоциативного доступа. Я не против сахара.

GZ>Немного не так. Давай возьмем ту шнягу с ленивыми вычислениями что представил ты, и выделим логический и физический уровень. Допустим физический уровень — это чистый набор таблиц. И допустим логический уровень — это некоторый entity к которому в метаданных прописан запрос получения(можно взять за образец BLToolkit).

GZ>Итого:
GZ>
GZ>val entity=from table1 inner join tablejoin on (bla-bla) select id, b, c
GZ>

GZ>нам нужно получить entity2 который связан с аттрибутом с, как с.a, и идентификатор entity = 10
GZ>
GZ>val entity=from table select id, b, c
GZ>val entity2=from table1 select id, e, f
GZ>var res=from entity2, entity where entity2.c=entity.id and entity.id=10 select entity
GZ>

GZ>что выливается в запрос
GZ>
GZ>select table1.* from table1 inner join tablejoin on (bla-bla) inner join table2 on (table1.c=table2.id) where table1=10
GZ>

GZ>А так нравится?
Ну и что? Вся нехилость этого запроса, получается, скрыта. Кстати, для конкретно этого примера вполне достаточно сделать
create view entity as select id, b, c from table 
create view entity2 as select id, e, f from table1

И вся эта нехилая шняга в использовании будет проста:
select entity.* from entity inner join entity2 on entity.c=entity2.id where entity2.id=10

GZ>И вся эта нехилая шняга в использовании будет проста
GZ>
GZ>entity2=entity1.c
GZ>

Вот это мне вообще непонятно. Ну написали мы кусок Where. Дальше-то что? Это какой-то синтаксис без семантики. Все равно придется писать
from entity where entity.c = 10 select
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: Настольная БД
От: stalcer Россия  
Дата: 11.04.06 09:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


Да навигация-то была в реализациях метода M(). Я же специально жирным выделил. Вот попробуй ее оттуда убрать не меняя смысла. Придеться переносить в запрос, что и приводит к нарушению инкапсуляции (модульности).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[36]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 10:00
Оценка:
Здравствуйте, stalcer, Вы писали:

S>Да навигация-то была в реализациях метода M(). Я же специально жирным выделил. Вот попробуй ее оттуда убрать не меняя смысла. Придеться переносить в запрос, что и приводит к нарушению инкапсуляции (модульности).

А! Извини, не сразу заметил. Ну да, есть такая проблема. Точнее, полноценный OODBMS движок должен сам раскручивать такие вещи:

select xt.* from C_Tab xt where xt.M()

-->
select c1 from Extent<C1> c1 where c1.C1::M()
UNION 
select c2 from Extent<C2> c2 where c2.C2::M()


-->


select c1 from Extent<C1> c1 where c1.a.x != 0
UNION 
select c2 from Extent<C2> c2 where c2.b.y != 0


-->


дальше уже идет построение физического плана для обычного мономорфного запроса. Ну там типа
UNION(
  HASH_JOIN(
        CLUSTERED_INDEX_SEEK(A_X_ID, != 0), // сканируем индекс по A(x, id)
        CLUSTERED_INDEX_SCAN(C1_A) // сканируем FK- индекс по C1(a)
    ), 
    LOOP_JOIN(
      INDEX_SCAN(C2_PK_B), // сканируем индекс по C2(b)
        TABLE_SCAN(B, B.id=C2_B && y!=0)
    )
)


Но смысл остается в том, что поиск по-прежнему ведется ассоциативно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Настольная БД
От: stalcer Россия  
Дата: 11.04.06 10:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

Кроме, конечно, сложности реализации такого движка, есть здесь, как мне кажеться, и более фудаментальная проблема. Дело в том, что оптимизации такие будут возможны только для простых случаев, а дальше кирдык. И кирдык этот оттого, что логика пишется а императивном языке .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[43]: Настольная БД
От: GlebZ Россия  
Дата: 11.04.06 10:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А-а. Ну, тут понятия "ассоциативности" несколько размываются. Сама по себе реляционная алгебра ничего о модификациях не говорит.

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

S>А в чем собственно затык? Язык SQL уже собственно turing-complete.

В честь чего? Может ты имел ввиду T-SQL?

GZ>>Хорошая весчь. Прям XQuery(который в действительности умеет работать с реляционными данными).

S>Я XQuery собственно не знаю. Но с точки зрения функциональщины (где собственно выражения являются first-class citizens) SQL не слишком далеко убежал от Клиппера. Разве что результат операции по умолчанию не скидывается в новое персистентное отношение, а уезжает клиенту. Тьфу!
+1

GZ>>Я как-то продумывал математику на такую шнягу на основе Фегараса.

S>Очень хорошо.
Здесь больше подойдут кимовская оптимизация + beta редукция. Фегарасовская математика подразумевает другой набор реляционных операций.

GZ>>Лучше делать язык который учитывает сразу взаимосвязи.

S>Ты имеешь в виду автоматизацию джойнов? Вроде select * from orders where order.Customer.Name like "Иванов%"?
Да.

S>А какие у нас еще есть случаи? Навигация — это либо разыменование ссылки, либо итерирование коллекции. Вариантов нет.

+1.
S>Собственно аналогом ссылки является PK, а коллекция суть результат некоторого запроса.
+1
GZ>>Но в случае применения навигационного доступа, я вполне могу гулять как захочу без sql.
S>Нет, просто в навигационном доступе намертво вшиты некоторые запросы. В частности прямая навигация по FK и обратная навигация (типа Order.Items).
Если мы не будем отрывать физического хранения от логического, то да. Если будем отрывать, то все может быть несколько сложней и интересней.

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

S>Ышшо рас: навигация суть частный случай ассоциативного поиска. С очень убогими ассоциациями
А ненужно больше. Еще раз повторю уже слева направо:
Несложное приложение можно разделить на два локальных сценария:
1. Мы показываем некоторый грид (и тут без ассоциативного поиска никуда не денешся).
2. Мы редактируем некоторый объект в форме. В данном случае у нас есть некоторая куча взаимосвязанных объектов, у которых можно выделить один объект как корень. Плюс к этому, при редактировании мы должны поднимать справочники значений. И вот здесь, навигационный способ значительно продуктивнее для программиста, чем долгое вбивание запросов.
Re[48]: Настольная БД
От: Merle Австрия http://rsdn.ru
Дата: 11.04.06 10:37
Оценка:
Здравствуйте, stalcer, Вы писали:

S> А для просто ассоциаций, не являющихся аггрегациями — мой сценарий.

Но твой сценарий, когда просто ассоциации — это еденичные выборки и они не оказывают заметного влияния на производительность всей системы, с чего собственно и начался разговор.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[35]: Настольная БД
От: GlebZ Россия  
Дата: 11.04.06 10:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

Дык я и не возражалЪ.

S>Ну и что? Вся нехилость этого запроса, получается, скрыта. Кстати, для конкретно этого примера вполне достаточно сделать

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

public PersonDataSource:DataSource
{
    Query<T> Select(){return from table1 t, table2 t2 select t1;}
........
    
}


S>Вот это мне вообще непонятно. Ну написали мы кусок Where. Дальше-то что? Это какой-то синтаксис без семантики. Все равно придется писать

S>
S>from entity where entity.c = 10 select
S>

Безусловно. Корень в навигации практически всегда нужен.
Re[49]: Настольная БД
От: stalcer Россия  
Дата: 11.04.06 10:41
Оценка:
Здравствуйте, Merle, Вы писали:

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


Моя твоя непониает,
Рассудок мой изнемогает.
И т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[38]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 12:01
Оценка:
Здравствуйте, stalcer, Вы писали:
S>Кроме, конечно, сложности реализации такого движка, есть здесь, как мне кажеться, и более фудаментальная проблема. Дело в том, что оптимизации такие будут возможны только для простых случаев, а дальше кирдык. И кирдык этот оттого, что логика пишется а императивном языке .
С т.з. тезиса Черча императивные и декларативные языки суть одно
А с точки зрения здравого смысла мы вполне можем попытаться привести метод M() к функциональному виду. И это, очевидно, удастся в простых случаях (типа тех же лямбда-выражений). В случае неудачи мы можем откатиться к методу полного перебора. Как минимум это не хуже, чем классический навигационный способ.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[44]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 12:01
Оценка:
Здравствуйте, GlebZ, Вы писали:
S>>А в чем собственно затык? Язык SQL уже собственно turing-complete.
GZ>В честь чего? Может ты имел ввиду T-SQL?
Нет, зачем? Для справки: исчисление функций, где есть функция 0, инкремент, и выбор n-ого аргумента, является turing-complete.

S>>Нет, просто в навигационном доступе намертво вшиты некоторые запросы. В частности прямая навигация по FK и обратная навигация (типа Order.Items).

GZ>Если мы не будем отрывать физического хранения от логического, то да. Если будем отрывать, то все может быть несколько сложней и интересней.
Я не очень понимаю, что такое физическое и логическое хранение. Хранение бывает только одним — физическим. Есть логический уровень, который представляет хранимые данные в виде какой-то модели. Не могу придумать такой модели, в которой навигация была бы связана с чем-то, кроме банальных FK/PK.
S>>Ышшо рас: навигация суть частный случай ассоциативного поиска. С очень убогими ассоциациями
GZ>А ненужно больше. Еще раз повторю уже слева направо:
GZ>Несложное приложение можно разделить на два локальных сценария:
GZ>1. Мы показываем некоторый грид (и тут без ассоциативного поиска никуда не денешся).
GZ>2. Мы редактируем некоторый объект в форме. В данном случае у нас есть некоторая куча взаимосвязанных объектов, у которых можно выделить один объект как корень. Плюс к этому, при редактировании мы должны поднимать справочники значений. И вот здесь, навигационный способ значительно продуктивнее для программиста, чем долгое вбивание запросов.

Совершенно непонятно, почему ты связываешь ассоциативность непременно с долгим вбиванием запросов . Длина запросов зависит от синтаксиса языка. Если мы сделаем удобный синтаксис для прямой и обратной навигации, то все придет само.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: Настольная БД
От: Cyberax Марс  
Дата: 11.04.06 12:29
Оценка:
Sinclair wrote:
> Не могу придумать такой модели, в которой навигация была бы
> связана с чем-то, кроме банальных FK/PK.
Банально: OID является указателем на физическое расположение объекта
(позицию в файле). Тогда при навигационный доступ будет O(1), вместо
O(log N).

А если использовать при этом схемы с mmap'ом то вообще быстро получается.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[46]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 12:55
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Банально: OID является указателем на физическое расположение объекта
C>(позицию в файле). Тогда при навигационный доступ будет O(1), вместо
C>O(log N).
Зато апдейт будет O(N). Такая модель неприемлема для нестатических БД.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[47]: Настольная БД
От: GlebZ Россия  
Дата: 11.04.06 13:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Банально: OID является указателем на физическое расположение объекта

C>>(позицию в файле). Тогда при навигационный доступ будет O(1), вместо
C>>O(log N).
S>Зато апдейт будет O(N). Такая модель неприемлема для нестатических БД.
Вообще-то поиск для aпдейт легко можно уменьшить (с помощью bitmap индекса). Другой вопрос что O(1) сделать трудновато. Хотя бы потому что нужно адресоваться по индексу, и адресация для страниц — подразумевает O(log N).
Re[45]: Настольная БД
От: GlebZ Россия  
Дата: 11.04.06 13:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Нет, зачем? Для справки: исчисление функций, где есть функция 0, инкремент, и выбор n-ого аргумента, является turing-complete.

Все — начинаю все писать в SQL.
Смешно. Зачем цепляться за термины. Вполне понятно что для многих вещей он не применим без T-SQL. Он легко справляется с четко поставленной задачей, но не более того.

S>>>Нет, просто в навигационном доступе намертво вшиты некоторые запросы. В частности прямая навигация по FK и обратная навигация (типа Order.Items).

GZ>>Если мы не будем отрывать физического хранения от логического, то да. Если будем отрывать, то все может быть несколько сложней и интересней.
S>Я не очень понимаю, что такое физическое и логическое хранение. Хранение бывает только одним — физическим. Есть логический уровень, который представляет хранимые данные в виде какой-то модели.
Ессно, имелось именно это ввиду.
S>Не могу придумать такой модели, в которой навигация была бы связана с чем-то, кроме банальных FK/PK.
Во первых я говорил о самом строении объекта. Но в принципе можно поговорить и о банальных FK/PK. У меня примеров вагон и маленькая тележка. Ну например:
Есть юридические лица. Есть физические лица. У них есть общие аттрибуты, есть разные аттрибуты. А у документа — есть свойство подписант, в роли которого может выступать и юридическое лицо, и физическое.

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

Ну, с длиной запросов, если брать подобный SQL синтаксис(или функциональный типа LINQ) — хреноватенько по любому. Есть еще одно непотребное свойство. Код не должен повторяться. Из-за того что код будет достаточно часто повторяться, а программист с головой, он выделит его в функцию. Не легче ли сразу решить для него проблему?
Re[47]: Настольная БД
От: Cyberax Марс  
Дата: 11.04.06 13:17
Оценка:
Sinclair wrote:
> C>Банально: OID является указателем на физическое расположение объекта
> C>(позицию в файле). Тогда при навигационный доступ будет O(1), вместо
> C>O(log N).
> Зато апдейт будет O(N).
С чего бы?

Перезапись полей объекта — O(1), удаление объекта O(1) — просто помещаем
его в список свободных объектв. Вставка объектов — тоже O(1).

Единственное, при физическом перемещении объекта (в результате изменения
размера, например) придется обновлять ссылающиеся на него объекты. А
будет ли это частой операцией?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[48]: Настольная БД
От: Cyberax Марс  
Дата: 11.04.06 13:19
Оценка:
GlebZ wrote:
> S>Зато апдейт будет O(N). Такая модель неприемлема для нестатических БД.
> Вообще-то поиск для aпдейт легко можно уменьшить (с помощью bitmap
> индекса). Другой вопрос что O(1) сделать трудновато. Хотя бы потому что
> нужно адресоваться по индексу, и адресация для страниц — подразумевает
> O(log N).
Почему, просто записываем в OID физическую позицию в файле.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[48]: Настольная БД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.06 13:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Единственное, при физическом перемещении объекта (в результате изменения

C>размера, например) придется обновлять ссылающиеся на него объекты. А
C>будет ли это частой операцией?
Конечно же будет. А ты как хотел? Иначе наш файл окажется крайне дырявым. СУБД без физического перемещения в природе не бывает. Причем, что характерно, перемещается как правило не один объект, а сразу пачка.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: Настольная БД
От: kan_izh Великобритания  
Дата: 11.04.06 13:49
Оценка: 1 (1) +1
Sinclair wrote:

> S>>А в чем собственно затык? Язык SQL уже собственно turing-complete.

> GZ>В честь чего? Может ты имел ввиду T-SQL?
> Нет, зачем? Для справки: исчисление функций, где есть функция 0,
> инкремент, и выбор n-ого аргумента, является turing-complete.
Неверно. Оператор рекурсии забыл.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.