Ищу описание низкоуровневой системы хранения данных оракл

Попробуй посмотреть книгу Томас Коннолли, Каролин Бегг «Базы данных, проектирование, реализация и сопровождение» - там такие вопросы достаточно подробно рассмотрены. Насколько много там конкретно про Oracle не помню

Всё никак не оставите идею написать свою СУБД с Ш и Б/Ж?

не только не оставлю но и работаю над этим.

более того, щас чутка кое-что напишу и начну опять спамить на ЛОРе, предлагать соучастие.

> не только не оставлю но и работаю над этим.

Тогда зачем тебе оракловое хранилище? Postgres тоже версионник.

подозреваю что в оракле оно «более правильное» и кроме того у оракла всегда была на два порядка лучшая документация чем у постгреса.

> подозреваю что в оракле оно «более правильное»

Думаю, принципы работы СХД версионников давно отработаны :)

и кроме того у оракла всегда была на два порядка лучшая документация чем у постгреса.

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

Создай раздел с описанием сетевого стека, с описанием всей архитектуры.

я дико извиняюсь, но очень интересно
а зачем?

под супер мега нагрузки?
чтоб бесплатно?
чтоб именно _свое_?
еще что-то?

разве оракл не мега-энтерпрайзен?

Oracle для профессионалов. Том Кайт

или Oracle Database Administrator's Guide :)

я уже писал.
(говорю как человек который МНОГО писал под оракл и не только под оракл)

список проблем оракла (читай и остальных БД)

1. практически любой, каким бы он сложным ни был, запрос всегда исполняется не более чем на одном ядре.

2. репликация реализованна через одно место. (предрекая споры о том что есть средства) это как сравнивать систему со встроенным garbage collector с C/C++ костылями mystring->add_ref(); ... mystring->del_ref();

далее идёт уже не проблемы а то что бы хотелось

1. ещё главный разработчик postgres, основатель vertica, писал что неправильно когда есть несколько языков отвечающих за работу системы. то есть писать часть на sql часть на perl это неправильно. хотя бы по причине временных потерь при передаче данных. ну а если более серьёзно браться то бизнес-логика на определённом этапе становится очень сложной и итоге во многих java-проектах где я участвовал принималось волевое решение делать select * from table а потом уже делать where внутри java (что пиздец), ибо «то что может отфильтровать» считалось бизнес-логикой и хранилось в яве.

2. в оракле есть apex. кривой и недоделанный (по политическим причинам). хочется нормальный и законченный.
apex - это возможность создать веб-сайт только средствами оракла. со всякими табличками, ajax'ами, формочками и тд. то есть готовый скелет для построения (в том числе) ERP.

3. (подсказываю) oracle может исполнить запрос любой вложенности и сложности и выдать на выходе XML-дерево также любой сложности. также в оракле есть XSLT. один запрос и страница сайта целиком сгенерена (я так делал на достаточно больших кстати сайтах).


Но оракл идёт своей дорогой (у них опеределённые цели, в частности, например, чтобы никто не мог удовлетвориться покупкой только одного продукта из их линейки в 50 продуктов и чтобы необходимо было купить 5-10 продуктов). Кроме того, оракл слишком дорог.

Ну это если вкратце. Опять же, с лицензированием ещё не решил - может и GPL будет.

я опять же много пишу последнее время всяких ERP-систем и тд.
где хочется сделать репликацию и прочие вещи.

вобщем всё это идёт из опыта.

ну будет приятно если «выходе с лора» такое осилит :)
только вот, мне видится, работы тут видимо невидимо.

ну у меня опыта достаточно. хотя конечно хочется найти ещё 1-2 человек.

Видно, что ты на этом «собаку съел» и достаточно хорошо представляешь себе «что и как» нужно сделать. Но сдается мне, что бы осилить такое в обозримые сроки нужно 20-30 соучастников. )))

я в опыте и не сомневался. адекватность давно видна.
я про время и человеко-часы.
ты же не можешь 12ч в день кодить только это год-два ?

1. практически любой, каким бы он сложным ни был, запрос всегда исполняется не более чем на одном ядре.

Глянь на это.

Oracle Parallel Query (formerly Oracle Parallel Query Option or PQO) allows one to break-up a given SQL statement so that its parts can run simultaneously on different processors in a multi-processor machine. Typical operations that can run in parallel are: full table scans, sorts, sub-queries, data loading etc.

Кстати, APEX очень активно развивается в последние год-два.

Все на эрланге будешь делать?

+ под такой серьезный проект нужно тщательно продумать бизнес-модель и оплату труда соучастников. я думаю это как минимум не менее важно чем сам кодинг.

ну у меня времени свободного достаточно много (я на поддержке своих уже готовых проектов сижу в основном). да и если писать, например, не на C/C++ а на erlang то время подсократится. но да, работы там дохрена.

но впринципе, если правильно организовать хранилище (как я хочу его организовать) и не делать (по первой) оптимизации sql-запросов, то есть чтобы они исполнялись «влоб» исходя из подсказок (как в оракле можно же указать намертво «вот здесь использовать вот этот индекс») то субд начальную можно написать за месяц-два. с транзакциями, репликацией и прочей петрушкой. то есть она будет конечно тупая и убогая но работать будет вполне нормально.

про существование oracle parallel query я, конечно же, знаю. )
потому и написал «почти всегда».

думаю все внутренности системы на эрланге. а внутренний язык будет аналогом plsql. хотя есть ещё вопросы. уж очень хочется временами сделать OO-таблицы с наследованием. но в этот момент мой моск закипает.

хотя конечно хочется найти ещё 1-2 человек.

Лучше деньги найди и люди потянутся

мнезию смотрел?

смотрел. как правильно написано на wikipedia - мнезия не предназначается как замена sql-базам данных и desktop-базам данных. мнезия это скорее berkley db.

> Лучше деньги найди и люди потянутся
Ищу. только сложновато немного найти $20k-$30k запросто так. один кирилл требует 4/месяц. и тогда эта база уже врядли будет GPL. бесплатной - весьма возможно, но врядли с открытыми исходниками.

> Тогда зачем тебе оракловое хранилище? Postgres тоже версионник.

Насколько я понимаю, postgres версионник (держит несколько версий данных в самой базе), а Оракл создает rollback журналы.

кстати да, в оракле rowid не изменяется при update, а в postgresql - изменяется.

В качестве флуда. Никогда не понимал, зачем нужен SQL. Когда в первый раз читал про него, вроде было написано - чтобы секретарши (суровые секретарши из 80-х) могли исполнять любые запросы, а не ограничиваться тремя галочками. Сегодня это не аргумент. SQL как интерфейс к базе данных из ЯП использовать очень неудобно. Ладно, если запросы однотипные, там костыли научились делать (parameters) и даже оптимизировали их, так что костыли теперь считаются хорошей практикой. Но если надо сгенерировать динамически запрос - это, мягко говоря, неудобно. Появляются такие вещи, как, например, Hibernate Criteria API. Это пример относительно человеческого интерфейса к БД, где запрос синтаксически пишется на используемом ЯП, и позволяет, хотя бы, гарантировать, что если программа скомпилировалась, то в ней не будет синтаксически некорректных запросов. Но если вдуматься, под капотом ведь такой бред происходит. Мы используем Criteria API, оно генерирует SQL запрос, он парсится движком БД. Ещё прикольные вещи - оптимизация SQL-запросов. Это когда мы меняем сравнения местами (!) и запрос волшебным образом начинает выполняться быстрее. Порой это всё кажется чёрной магией. Реально конечно просто достаточно понимать, как работает оптимизатор. Но нафига это? Почему просто прямо не сказать оптимизатору, как оптимизировать? Я про свою БД и про то, как она будет расти, знаю больше чем оптимизатор.