Попытка Oracle поглотить MySQL провалилась?

>Ты же, кажется, Ораклом рулишь? Часто тебе в этой работе приходится >иметь дело с файлами в качестве "инструмента доступа к хранению и/или >_документом_"? Файл/каталог - вообще лишняя сущность. Нужны данные, а >файловая система только способ представления данных в иерархическом >виде. Что такое документ - вообще не понятно. Данные - это любое поле в >таблице, документ (набор данных с структурой) можно представлять как >одним полем так и несколькими. Любая программа обрабатывает данные, >файл в котором данные хранятся - только вспомогательное средство.

Фсё смешалось: кони, люди :)) Как часто Oracle DBA имеет дело с файлами? - Почти всегда :)) Как часто пользователь БД общается с файловой системой сервера? - Почти никогда :))

PS Кстати, идея о ненужности и избыточности файловой системы потихонику овладевает массами, так сказать, явочным порядком. Хранить конфиги в текстовых файлах уже становится немодно. Все норовят конфиги или в мускуль или, в крайнем случае, в LDAP запихнуть. Наш пионерский ПРЕВЕД! M$ registry.

Нах тебе файло нужно? Чтобы данные скинуть в свой Орал или вытащить их оттуда. Исключительно как промежуточный носитель.

Почему-то здесь забыли упомянуть о том, что Oracle может прекрасно обходиться вообще без файловой системы... Это я о raw-разделах...

> Нах тебе файло нужно? Чтобы данные скинуть в свой Орал или вытащить их > оттуда. Исключительно как промежуточный носитель.

Вот блин любители сравнить палец с жопой :))) А на флэшке ты что таскаешь или там по почте отсылаешь? В конце концов передать дамп того-же Оракла куда-то? :)))

Кесарево - кесарю, богово - Богу. Оракл не раз делал замахи на ФС, но как-то "угнаться" за всем семейством ОС, на чем он работает, он не в состоянии!!! Конечно взаимное прониконвение идей ФС<->СУБД происходит постоянно, но думать, что скоро СУБД "поглотят" ФС (или наоборот) - смешно!

>>но думать, что скоро СУБД "поглотят" ФС (или наоборот) - смешно!
Походи по ссылкам в этом треде и посмейся.

И не только Оракл. Мускуль тоже на raw-partition ставится. О чём уже были жирные намёки.

> Походи по ссылкам в этом треде и посмейся. А готовые решения есть? А не ссылки на рассуждения "Как скоро всё будет хорошо"... Тут вспомнили про RAW, да, есть такаая штука. Но Вы хоть почитайте её минусы. Самый большой минус - гораздо труднее адимнистрировать их, чем например, обычные ФС. В класическом Юнихе что такое RAW? ах, опять таки файлики (правда псевдо), но всё-равно файлы со своими атрибутами, которые крепко сидят в ФС!

Да, если уже заикнулись о полной замене, само ПО СУБД тоже будет устанавливаться на RAW или на какую-то Мета ОС СУБД? :)))

>>>В класическом Юнихе что такое RAW? ах, опять таки файлики (правда псевдо), но всё-равно файлы со своими атрибутами

И чё? Если Линукс, вслед за Юниксами, настаивает на том что всё есть файло, приходится делать вид, что /dev/hda2 - это файл. Причём, сама идея (всё есть файл) каждый раз нуждается в уточнениях - блочный это файл, последовательный, исполняемый, неисполняемый. Т.е. оперируя только в рамках модели файла, нам приходится каждый раз подгонять модель под текущую ситуацию, что не есть хорошо.

>>>Да, если уже заикнулись о полной замене, само ПО СУБД тоже будет устанавливаться на RAW или на какую-то Мета ОС СУБД? :)))

Файловые системы встроены в ядро. Почему бы не встроить в ядро реляционную базу данных? Поддержка elf(a.out) формата тоже встроена в ядро. Почему бы ядру заодно не поддерживать формат stored procedure?

>>> Файловые системы встроены в ядро. Почему бы не встроить в ядро реляционную базу данных? Поддержка elf(a.out) формата тоже встроена в ядро. Почему бы ядру заодно не поддерживать формат stored procedure? Угу, а также встроить туда X сервер, половину системных демонов... Вот объясни зачем например Терминалу или мобильнику БД в ядре?