Merle,

> ПК> Я говорил немного о других проблемах, когда нарушается целостность файлов с данными: вирусы/антивирусы, аппаратные и программные сбои и т.п. Последнее на практике имеет заметно большее значение.

> Ну, вот как раз практика борьбы с такими проблемами, в БД вырабатывалась годами... Online бакапы <...>

Backups и журналирование в данной задаче можно не рассматривать: очевидно, что простой пользователь почтовой программы не будет ее администрировать с тем же тщанием, что администратор БД.

> ПК> Это легко диагностируемые и поправимые нарушения, в отличие от "битых" файлов баз данных.

> Хм. Как раз битый файл в БД и диагностируется и восстанавливается <...>

И тем не менее, периодически базы "умирают насмерть", и тогда приходится восстанавливать их из backup.

> битый файл просто в ФС скорее всего окажется утерянным навсегда. Другое дело, если по условиям задачи его не жалко

Его меньше жалко, чем всю базу.

> если надежность все же необходима, то БД тут заведомо надежнее.

Один контрпример: антивирус, удаляющий файл с вирусом. В случае БД он "снесет" всю базу.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Backups и журналирование в данной задаче можно не рассматривать: очевидно, что простой пользователь почтовой программы не будет ее администрировать с тем же тщанием, что администратор БД.
Ну вот тут как раз неясность в задаче, так и не понятно что же Зверек пишет, то ли клиента то ли сервер..
В случае клиента и файл потерять не жалко и навороты БД не нужны, а в случае сервера, как раз наоборот.

ПК>И тем не менее, периодически базы "умирают насмерть", и тогда приходится восстанавливать их из backup.
Но в случае БД есть готовый механизм который этим занимается и стандартные процедуры... А вслучае файла — он оказывается безвовратно утерян.

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

ПК>Один контрпример: антивирус, удаляющий файл с вирусом. В случае БД он "снесет" всю базу.
В случае БД он просто доступа к базе не получит. А если получит и снесет, то базу можно восстановить.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Торчат из "реляционки", а проявляется это в модели данных WinFS, а именно ScalarType, NestedType, Relationship. Думаю всё это до боли знакомо людям использовавшим ORM.
Да вот как-то не очень это похоже на реляционку. Для реляционки достаточно потребовать реализации определенного интерфейса, сериализации, атрибута или, в крайнем случае, наследования от какого-нибудь базового объекта, что и наблюдается в большинстве существующих ORM.
А тут какие-то нарошные контейнеры...
Впрочем, они одно время пытались ObjectSpaces вкрячить, но потом вроде передумали, так что в каком виде это сейчас — можно только гадать.

ANS>Тьфу.
А как бы это сделал ты? Подвох в том, что для широого класса задач ни одна из существующих ООБД как-то не катит. А тут класс задач сверхширокий, ФС при работе должна нагибаться по всякому, желательно одинаково эффективно, ну покрайней мере с разбросом в разумных пределах, а вот у ООБД с этим бедулька.

ANS>Ну, всё же не дерево, а граф с циклами.
Это уже нюансы, в крайнем случае ничто не мешает требовать сериализации при сохранении.

ANS>Второй момент — в "объектах" значениями м.б. не только строки.
И что? Тоже не бином ньютона.

ANS>Если представить, что значениями м.б. не только строки, но еще и числа, это уже потребует либо усложнения схемы хранения, либо доработок движка.
Какого усложнения? Там все просто как рельс, и на тип хранимых данных не завязано вообще.

ANS>Во-первых, тут уже приводились аргументы за то, что у МС не хватает ресурсов на исполнение всех данных обещаний.
Они ничего не обещали, они делали. По слухам, около восьми лет, но это по слухам, так что могу и наврать... И по честному искали разные способы.

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

ANS> а вот прозрачно и с минимальным оверхедом интегрировать его...
Они там много чего совсем не реляционного довольно прозрачно интегрировали, включая поддержку .Net. К тому же еще раз повторюсь, собственно самой подсистеме хранения практически все равно что хранить. Аналогичная подсистема хранения используется в NTFS, Lotus и еще куче других конструкций, в том числе и объектных, и особых проблем не испытывает...

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

VD>Дык зависит от задачи. И терминалогии. Напиример, исходники в БД хранить явно неразумно. Тут лучше подойдут файлы и сорс-контрол.

При этом существует не так уж и много сурс-контролов которые действительно хранят данные в файловой системе. И все в основном из серии CVS/SVN. Так что сдается мне что по большому счету совершенно фиолетово где исходники хранить, если работа с ними идет не напрямую, а посредством некоторого "тула".

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Один файл на каждое собщение вовсе не означает, что все файлы будут "свалены" в одном каталоге. Скажем, та же Опера хранит сообщения в следующей иерархии: account/year/month/day/messageid.mbs Раньше было так: account/year-month.mbs

Тоже вариант.

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

IT>>По-моему, сщепление на порядок уже
M>В смысле дефрагментация? Ну она зато существенно реже и не так актуально делать ее прям щас.

Нет. Расщепление страниц по сравнению с удалением записи и последующей балансировкой страниц — это детский сад.

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

M>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Торчат из "реляционки", а проявляется это в модели данных WinFS, а именно ScalarType, NestedType, Relationship. Думаю всё это до боли знакомо людям использовавшим ORM.
M>Да вот как-то не очень это похоже на реляционку. Для реляционки достаточно потребовать реализации определенного интерфейса, сериализации, атрибута или, в крайнем случае, наследования от какого-нибудь базового объекта, что и наблюдается в большинстве существующих ORM.

Как по мне, то всё это вытекает из особенностей РСУБД.

ANS>>Тьфу.
M>А как бы это сделал ты?

Как минимум убрал бы явную(!) работу с ключом. Там есть и еще один интересный момент:

hhmd.Name = p1.DisplayName;
hhmd.Target_Key = p1.ItemID_Key;

Первое, что произойдёт при изменении p1.DisplayName? Второе, если даже оно там само будет обновлятся, всё равно ad-hoc поиск идёт лесом.

ANS>>Ну, всё же не дерево, а граф с циклами.
M>Это уже нюансы, в крайнем случае ничто не мешает требовать сериализации при сохранении.

Пример можно? С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.

ANS>>Второй момент — в "объектах" значениями м.б. не только строки.
M>И что? Тоже не бином ньютона.

Пример можно? С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.

ANS>>Если представить, что значениями м.б. не только строки, но еще и числа, это уже потребует либо усложнения схемы хранения, либо доработок движка.
M>Какого усложнения? Там все просто как рельс, и на тип хранимых данных не завязано вообще.

Не буду повторятся. См.выше

ANS>>Во-первых, тут уже приводились аргументы за то, что у МС не хватает ресурсов на исполнение всех данных обещаний.
M>Они ничего не обещали, они делали. По слухам, около восьми лет, но это по слухам, так что могу и наврать... И по честному искали разные способы.

Хмм. В куче статей люди пишут, что некую ООФС анонсировали еще для NT. Но даже если это не считать за обещание, то на в msdn куча дописок:

UPDATE: In spite of what may be stated in this content, "WinFS" is not a feature that will come with the Longhorn Operating System. However, "WinFS" will be available on the Windows platform at some future date, which is why this article continues to be provided for your information.

Таки что-то кому-то обещали.

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

Ай. Да, кому нужна эта эффективность? Павлу Дворкину? Совместимость!

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

IT>Нет. Расщепление страниц по сравнению с удалением записи и последующей балансировкой страниц — это детский сад.
Да не, после удаления никто ничего не балансирует, зачем? Да и не удаляет толком ничего, на самом деле, просто помечается место как свободное и все. Для подчищения свободного места зпускается специальная процедура дефрагментации, если надо.
Более того, если в транзакции произошла вставка приведшая к расщеплению страниц, но транзакция до коммита не дожила и была отменена, то страница так и останется расщепленой после rollback-а, никто это дело в исходное состояние приводить не будет.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Как по мне, то всё это вытекает из особенностей РСУБД.
А вот по мне так не очень, особенно с оглядкой на существующие ORM.

ANS>Как минимум убрал бы явную(!) работу с ключом.
А как ты еще объект идентифицировать будешь? Я так понимаю что это не сколько ключ, сколько ID объекта, самый что ни на есть объектный подход.

ANS> Второе, если даже оно там само будет обновлятся, всё равно ad-hoc поиск идёт лесом.
Почему? И зачем там чему-то самому обновляться?

ANS>Пример можно?
Пример чего? Сериализации? А как по твоему хранятся .Net типы в SQL? И ищутся, кстати, тоже.

ANS> С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.
И какая проблема с поиском? И заодно покажи мне существующую объектную систему, которая умеет делать то что ты хочешь.

ANS>Пример можно?
Пример чего?

ANS> С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.
Почитай описание алгоритма, я уже писал, он не зависит от типа хранимых данных, вообще. Ну нету там этой зависимости.

ANS>Не буду повторятся. См.выше
Сам смотри..

ANS>Хмм. В куче статей люди пишут, что некую ООФС анонсировали еще для NT.
...
ANS>Таки что-то кому-то обещали.
Я не про ООФС, я про движек хранения XML, там никому ничего не обещали, просто делали.

ANS>Ай. Да, кому нужна эта эффективность?
Ага, сломался.

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

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

Т.е. дерево не сбалансированное?

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

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

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

IT>Т.е. дерево не сбалансированное?
Обычно под балансировкой понимается разность в высоте веток дерева. В этом смысле B+ сбалансировано всегда, так как оно растет вверх и разности в высоте веток просто не возникает. И наличие пустого места на страницах или даже пустых страниц на балансировку не влияет, при поиске любой конкретной записи, будет поднято всегда одинаковое количество страниц равное высоте дерева (здесь я не рассматриваю случай Range Scan).
А вот "в ширь", на одном уровне, оно может быть фрагментированным, то есть иметь не до конца заполненные страницы или вообще пустые.
При этом есть ситуации, когда дефрагментация здорово повышает производительность, но они очень редки и поэтому непосредственно во время модификации данных об этом, как правило, не заботятся, а просто дают возможность провизвести эту процедуру по запросу или по расписанию.
При этом, как правило, фрагментация критичнее всего на листьевом уровне, и вот его дефрагментация как раз обходится довольно дешево. Помнится еще Тенгиз рассказывал, что когда они запускали дефрагментацию во время выполнения tpc-c теста, то она отожрала всего 5% производительности.

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

ANS>>Как по мне, то всё это вытекает из особенностей РСУБД.
M>А вот по мне так не очень, особенно с оглядкой на существующие ORM.

Ээ. ScalarType — тип поддерживаемый нижележащей СУБД. NestedType — один-ко-многим. Relations — таблица требуемая для многих-ко-многим. Поддержка наследование (атрибутов) есть, но примеров использования полиморфных значений я не видел. (Вообще, инфы, кроме "очередная революционная технология почти нет").

ANS>>Пример можно?
M>Пример чего? Сериализации? А как по твоему хранятся .Net типы в SQL? И ищутся, кстати, тоже.

Пойдём по шагам. Начнём с простейшего: пример хранения графа с циклами при помощи ordpath.

M>Я не про ООФС, я про движек хранения XML, там никому ничего не обещали, просто делали.

Попробовали б они не сделать, когда маркетологи говорят "надо".

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

M>При этом, как правило, фрагментация критичнее всего на листьевом уровне,

А данные хранятся только на листьевом уровне?

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

M>>При этом, как правило, фрагментация критичнее всего на листьевом уровне,

IT>А данные хранятся только на листьевом уровне?

В B+ деревьях только на листьевом уровне.
Причем применительно к БД на листьевом уровне размещают не сами данные, а указатели на расположение данных (т.е. листья хранят пары <ключ, указатель>).

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

_>Насколько я понимаю VSS для 2005 студии хранит исходники как раз в SQL Server

Нет. VSS остался тем же самым. Появилась Team System, но это килобаксы.

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

ВВ>При этом существует не так уж и много сурс-контролов которые действительно хранят данные в файловой системе. И все в основном из серии CVS/SVN. Так что сдается мне что по большому счету совершенно фиолетово где исходники хранить, если работа с ними идет не напрямую, а посредством некоторого "тула".

Как раз наоборот. Хотя тут можно пофилосовствовать, что сорсконтролы создают свою БД (т.е. велосипедствуют).

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

IT>А данные хранятся только на листьевом уровне?
Да. Данные или ссылки на данные хранятся только на листьевом уровне.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ээ. ScalarType — тип поддерживаемый нижележащей СУБД. NestedType — один-ко-многим. Relations — таблица требуемая для многих-ко-многим.
Это только напоминает реляционку. Как видно на примере ORM для реляционки таких приседаний не надо.
А вот если бы пришлось придумывать систему умеющую хранить произвольные наборы объектов, то боюсь получилось бы нечто похожее.
Вообще, главное чтобы был SQL-ный доступ ко всему этому хозяйству, а уж правильную работу с этим как с объектами, под конкретную задачу можно и самому написать.

ANS>Пойдём по шагам. Начнём с простейшего: пример хранения графа с циклами при помощи ordpath.
Потребую от графа умения сериализоваться и десериализоваться в xml, сведя тем самым задачу к известной.

ANS>Попробовали б они не сделать, когда маркетологи говорят "надо".
Уж посылать в лес маркетологов они умеют изумительно.

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

IT>>А данные хранятся только на листьевом уровне?
M>Да. Данные или ссылки на данные хранятся только на листьевом уровне.

А каков глубокий смысл?