Опять повторюсь — это концепт. Сырая реализация есть, но она сырая. А пример реализации я планировал в более масштабном примере выложить. Так что в скором времени ждите, а вообще данной статьей я планировал привлечь критические коментарии косательно самой архитектуры, а не холивар по поводу того что битрикс новое ядро уже несколько лет разрабатывает…
Для разработчиков, я думаю нет смысла писать на хабру какие то послания создателям.
Это концепт. Рекомендация того как распределить данные между структурными частями системы. Конкретный код, возможно, будет в другой статье.
Я в данный момент работаю с битриксом, и очень часто встречаю таких персонажей, так что это не ярлыки, а грустная правда;
Модули из коробки — не совсем бизнес логика. Точнее не все модели из коробки, это true MVC. Если вы писали сами, то вы как угодно могли писать компоненты и модули, а моя статья направлена на то, что есть изначально. Я считаю что размещение логики в компонентах — это в порядке вещей, собственно данному мнению посвящен пункт "Битрикс. HMVC"
Статья в первую очередь направлена для битриксоидов. А магазин можно поставить на чем угодно если есть готовый инструмент, а вот на счет проще с нуля поспорил бы. При работе с битриксом, есть много чего интересного и полезного, тут не поспоришь, чаще всего запросы заказчика покрываются стандартной сборкой битрикса и достаточно только настроить компоненты и сверстать шаблон. А вот когда задачи отходят от возможностей функционала стандартных компонентов, тогда возникают сложности.
А для этой же таблицы CREATE TABLE ex25(a,b,c,d,e), что тогда будет лежать на листьях table b- tree?
И у меня у самого возник вопрос, а как тогда спустившись по дереву получить физическую страницу?
А я-то думал, что там 64 бита данных, соответствующих ROWID записи…
Прочитайте внимательней раздел Representation. Для дерева index b — tree ключом является PRIMARY KEY!
Э… а остальные-то данные где хранятся, коли мы уже выяснили, что данных в index B–tree нет?
В дереве index b — tree на листьях хранятся ссылки страницы данных, а в table b — tree сами страницы данных. То есть не нужно путать запись страницы дерева, и страницы данных в базе.
P.S. на оф. сайте при использовании данных терминов ссылаются на книгу Кнута: The Art Of Computer Programming, Volume 3 «Sorting and Searching», pages 471-479
Да вы батенька эгоист! Среди такого населения как программисты, есть довольно таки большая прослойка как «начинающие», которые только знакомятся с той или иной технологией, ЯП, СУБД или еще чем либо. И раз такой знаток английского языка (что является сомнительным фактом), как ты может сидеть и спокойно читать документацию на англ, не многие начинающие готовы убивать время на перевод литературы, а если готовы, то это занимает время!
P.S. хабру читают только кодеры, которые способны свободно читать не отечественную документацию!? Ой, простите, видимо я не на тот ресурс забрел!
Это концепт. Рекомендация того как распределить данные между структурными частями системы. Конкретный код, возможно, будет в другой статье.
И у меня у самого возник вопрос, а как тогда спустившись по дереву получить физическую страницу?
А в куда в конец? На листе то что в итоге хранится?
P.S. уж извиняйте, мои познания английского не столь глубокие как ваши, так что помогите пожалуйста разобраться и соответственно исправить пост!
Прочитайте внимательней раздел Representation. Для дерева index b — tree ключом является PRIMARY KEY!
В дереве index b — tree на листьях хранятся ссылки страницы данных, а в table b — tree сами страницы данных. То есть не нужно путать запись страницы дерева, и страницы данных в базе.
P.S. на оф. сайте при использовании данных терминов ссылаются на книгу Кнута: The Art Of Computer Programming, Volume 3 «Sorting and Searching», pages 471-479
P.S. хабру читают только кодеры, которые способны свободно читать не отечественную документацию!? Ой, простите, видимо я не на тот ресурс забрел!