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

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

E>>Нет, не удачный пример.
S>Вполне удачный.

Спасибо за разъяснения. Я предполагал что-то подобное, но, имхо, это очень сложная задача. Если ты за нее взялся, то желаю успехов вдвойне! Надеюсь, что это приведет к получению достойного результата.

<...>

E>>

---

E>>Sinclair, а у тебя, случайно нет ODMG-3 стандарта в электронном виде?
S>Неа. Уж очень он дорогой.

Вот и у меня такая же история.

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


VD>Кстати, в R# очень хорошо для поиска по объектному графу подошел XPath. Похожий на твой запрос будет выклюеть так:
VD>

VD>IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]");
VD>

VD>Или есби без излишеств:
VD>

VD>foreach (Employee employee in Employees.Select("//Employee[Salary < 500]"))
VD>{
VD>    ...
VD>}
VD>

VD>Технология надо сказать уже работает и может быть спокойно перенесена на произвольный граф объектов. Если еще и компилируемый XPath сбацаем, то вообще лафа будет.
Во блин. Почему мне больше нравится OQL чем XPath. Не тем что он похож на SQL. Мне на это полностью начхать. XPath все-таки подразумевает дерево(для того и делался), а не произвольный граф.
Например, напиши такой запрос:
select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20
где никакие связи между a, b, и с нигде не отражены.

С уважением, Gleb.

VladD2 пишет:
> А это XPath. Его система типов пока что не совместима с Шарповсокй. Но
> над этим уже работают. По слухам в следующей версии языка будт встроена
> работа с ХМЛ и БД.

Кстати, не просветишь о "политике партии" на этот счет? А то я встречал
в Инете упоминания, что XPath не будет, а будет что-то другое, но
подробно не разбирался. Отложилось в голове, что что-то меняется, но вот
что и зачем?

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

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

VD>А в качестве импереативного языка обработки данных использую XPath.
Может, всетаки, декларативного?

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

GZ>select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20
Ну, если с синтаксисом не напутал:

//a[ @f1 = (//b[ @f1 = (//c[ @f2=20]/@f1) ]/@f1 ) ]

А вот тоже пример:

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

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

C>Если они, не дай бог, это сделают, то получится НЕЧТО еще хуже С++

Незнаю. Скорее всего все будет ОК. Они слишком заботятся о сохранении простоты...

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

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

GZ>>select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20
V>Ну, если с синтаксисом не напутал:
V>

//a[ @f1 = (//b[ @f1 = (//c[ @f2=20]/@f1) ]/@f1 ) ]

V>А вот тоже пример:
V>

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

Потрясающая читабельность у обоих вариантов

VladD2 пишет:

> C>Если они, не дай бог, это сделают, то получится НЕЧТО еще хуже С++
> Незнаю. Скорее всего все будет ОК. Они слишком заботятся о сохранении
> простоты...

Не знаю как вам, но для меня SQL в языке — бред. Так как это скорее
всего будет сделано в виде железной привязки к MSSQL (знаем мы этих
МСников...).

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

V>>А вот тоже пример:
V>>

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

E>Потрясающая читабельность у обоих вариантов
А приведи SQL вариант второго примера

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

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

V>>>А вот тоже пример:
V>>>

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

E>>Потрясающая читабельность у обоих вариантов
V>А приведи SQL вариант второго примера

А что он вообще делает? Я ведь XPath не знаю

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

GZ>XPath все-таки подразумевает дерево(для того и делался), а не произвольный граф.
Это почему еще?
ИМХО, применение XPath для графа будет отличаться от дерева только тем, что некоторые оси навигации, подразумевающие дерево, потеряют смысл.

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


V>>>>А вот тоже пример:
V>>>>

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

E>>>Потрясающая читабельность у обоих вариантов
V>>А приведи SQL вариант второго примера

E>А что он вообще делает? Я ведь XPath не знаю

Ну, допустим у нас есть XML дерево:

<a f="10" >
    <b f="15" />
    <b f="20" >
        <c f="25" />
        <c f="30" >
            <d f="40"> <!-- значение атрибута f этого узла и надо получить -->
        </c>
    </b>
</a>

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

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


V>>>>>А вот тоже пример:
V>>>>>

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

E>>>>Потрясающая читабельность у обоих вариантов
V>>>А приведи SQL вариант второго примера

E>>А что он вообще делает? Я ведь XPath не знаю

V>Ну, допустим у нас есть XML дерево:
V>

V><a f="10" >
V>    <b f="15" />
V>    <b f="20" >
V>        <c f="25" />
V>        <c f="30" >
V>            <d f="40"> <!-- значение атрибута f этого узла и надо получить -->
V>        </c>
V>    </b>
V></a>
V>

Задача понятна. Но как ее решить на SQL/OQL лично я не знаю.

Здравствуйте, Cyberax, Вы писали:
C>Не знаю как вам, но для меня SQL в языке — бред. Так как это скорее
C>всего будет сделано в виде железной привязки к MSSQL (знаем мы этих
C>МСников...).
Неа. Там все будет еще интереснее. Никакой привязки не произойдет — это все фичи языка, а не сервера. Прежде чем клеймить, почитай на микрософт ресерче про си-омегу.

Sinclair пишет:

> C>Не знаю как вам, но для меня SQL в языке — бред. Так как это скорее
> C>всего будет сделано в виде железной привязки к MSSQL (знаем мы этих
> C>МСников...).
> Неа. Там все будет еще интереснее. Никакой привязки не произойдет —
> это все фичи языка, а не сервера. Прежде чем клеймить, почитай на
> микрософт ресерче про си-омегу <http://research.microsoft.com/comega/&gt;.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

V>>>А вот тоже пример:
V>>>

/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

E>>Потрясающая читабельность у обоих вариантов
V>А приведи SQL вариант второго примера
Во первых- не OQL а SQL. Во вторых — запрос не правомерен, поскольку для OQL нет активной ноды, а все является графом. Поэтому даю два варианта;
Для

//a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f

select a.b.c.d.f where a.f=10 and a.b.f=20 and a.b.c.f=30

Несколько более читабельней будет.
Второй вариант — это если нам известен объект от которого мы скачем. Тут зависит от реализации OQL (коих немало), напишу примерно такой:

select m.a.b.c.d.f where m.a.f=10 and m.a.b.f=20 and m.a.b.c.f=30 and m.oid=@oid

С уважением, Gleb.

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

S>На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.

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

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

S> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
S> Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной.
S> У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию.
S> Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. Вбольшинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано.
S> Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции.
S> При фиксации транзакции страницы записываются и страницы становяися актуальными.
S> Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы.
S> При таком подходе проще вести лог, изменение индексов, архивировании БД итд.
S> А по скорости она будет мало уступать безтранзационной.

Как я понял, смысл в том, что содержимое БД перезаписывается. Но, если при работе пишущей транзакции есть еще и читающие транзакции (которые начались раньше), то уже стартовавшие транзакции читают старое содержимое БД, в то время, пока пишущая транзакция записывает новое содержимое. Так?

Пара замечаний.

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

Еще один подводный камень. Допустим, в БД есть страницы, которые принадлежат транзакциям с ID=4 и ID=5. Нет читающих транзакций. Начинается пишущая транзакция с ID=6. Постепенно она занимает все страницы с ID=4 и принимается за страницы с ID=5. И тут сбой. Страницам с ID=6 верить нельзя. Но кому тогда верить?

Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов?

А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц.

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

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

S>> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
S>> Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной.
S>> У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию.
S>> Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. Вбольшинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано.
S>> Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции.
S>> При фиксации транзакции страницы записываются и страницы становяися актуальными.
S>> Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы.
S>> При таком подходе проще вести лог, изменение индексов, архивировании БД итд.
S>> А по скорости она будет мало уступать безтранзационной.

E>Как я понял, смысл в том, что содержимое БД перезаписывается. Но, если при работе пишущей транзакции есть еще и читающие транзакции (которые начались раньше), то уже стартовавшие транзакции читают старое содержимое БД, в то время, пока пишущая транзакция записывает новое содержимое. Так?
Да.
E>Пара замечаний.

E>В таком подходе нужно будет выставлять какой-то маркер того, что транзакция зафиксирована полностью. Ведь если произойдет сбой при фиксации транзакции, то нужно будет как-то определить, что страницы с максимальным ID транзакции нужно проигнорировать. Но, если такой маркет будет, то при открытии БД нужно будет пройти по всей БД, и поднять все страницы, чтобы найти максимальный корректный ID транзакции.


E>Еще один подводный камень. Допустим, в БД есть страницы, которые принадлежат транзакциям с ID=4 и ID=5. Нет читающих транзакций. Начинается пишущая транзакция с ID=6. Постепенно она занимает все страницы с ID=4 и принимается за страницы с ID=5. И тут сбой. Страницам с ID=6 верить нельзя. Но кому тогда верить?

Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций.
При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)
E>Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов?
Если применть тотже механизм, что и в Re[11]: Объектно-ориентированные БД: основные принципы, орга

Автор: Serginio1
Дата: 04.03.05

, но с кэшированием страниц то и по сути с отложенной записью страниц (на странице будет не одна измененная запись) то гдето будет близко к тому варианту.
E>А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц.
У меня за цепочки отвечает отдельная таблица, но согласен это основное тонкое место.

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

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

E>>Еще один подводный камень. Допустим, в БД есть страницы, которые принадлежат транзакциям с ID=4 и ID=5. Нет читающих транзакций. Начинается пишущая транзакция с ID=6. Постепенно она занимает все страницы с ID=4 и принимается за страницы с ID=5. И тут сбой. Страницам с ID=6 верить нельзя. Но кому тогда верить?

S> Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций.
S> При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)

Так а зачем тогда лог? Обломилась транзакция, игнорируем ее страницы.
Проще где-то хранить ID последней успешно зафиксированной транзакции. И просто переиспользовать ID, которые больше этого значения.

E>>Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов?
S> Если применть тотже механизм, что и в Re[11]: Объектно-ориентированные БД: основные принципы, орга

Автор: Serginio1
Дата: 04.03.05

, но с кэшированием страниц то и по сути с отложенной записью страниц (на странице будет не одна измененная запись) то гдето будет близко к тому варианту.

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

E>>А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц.
S> У меня за цепочки отвечает отдельная таблица, но согласен это основное тонкое место.

Да, и ее придется защищать как-то по другому.