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

Pzz>>Вплоть до использования своей собственной партиции, на которой нет никакой файловой системы.
IB>Это официально не рекомендуемая экзотика, так что ""взрослые" SQL-сервера" как раз стараются работать поверх FS.

Если не ошибаюсь, именно Оракл протолкал поддержку "сырых" дисков в linux 2.6 (в 2.4 их не было). Вероятно, ребята из Оракла забыли почитать официальные рекомендации

Pzz>>Это как раз пример, опровергающий вашу точку зрения.
IB>Именно что подтверждающий. Уровень абстракции сиквела гораздо выше абстракции файловой системы, при этом сиквел сработал поверх той же файловой системы эффективнее. Что, собственно, и требовалось доказать.

А вы посмотрите на это не с точки зрения пользователя SQL-сервера, а с точки зрения его разработчика.

Казалось бы, ну зачем возиться со всем этим низкоуровневым доступом к диску, когда есть файловая система, которая все замечательно оптимизирует, да еще и автоматически. Ан нет, возятся. Наверное потому, что RSDN не читают

Pzz>>Т.е., SQL-сервер работает с диском быстрее именно благодаря тому, что он работает с ним на более низком уровне.
IB>Так что мешает самому работать на этом уровне? API-то файловой системы открытое, бери да пиши. Зачем привлекать немерянную абстракцию в виде сиквела, когда FS под рукой и ты точно знаешь, лучше всякого сиквела, что именно тебе нужно?

SQL ващето это не только драйвер диска, но еще и реляционная алгебра.

Pzz>> Такая конструкция значительно проще и прозрачнее, и если в ней что-то сломается, проще починить,
IB>Чем проще? Бакапов нет, поддержки согласованности нет, транзакций нет. Поэтому, во-первых, выше вероятносто того, что что-то сломается, а во-вторых, меньше шансов все корректно восстановить. В БД хотя бы средства автоматизированные есть.

Проще тем, что вот они письма, лежат на диске, каждое письмо в своем файле.