Далее по пути одной CMS

[Алексей Евдокимов]

После недельного перерыва я продолжаю публикацию черновиков глав "Пути CMS -- от рождения до тупика".

Все ссылки из предыдущей ветки форума залинкованы на бета-версию первой части книги.

[hr]

Драфты глав второй части:

Релиз 2.9 -- последняя engine, которая ещё small, или Сказка о том, какими бывают дипломные работы.

swift.engine 3.0.0, или Немного об архитектуре "host/plug-ins"

Вторая сказка о юзабилити, или Знакомый GUI лучше

Прыжки в ширину

Ссылки на последующие главы буду размещать здесь же.

[hr]

Любые замечания по теме -- сугубо приветствуются!

[Алексей Мокрушин]

Мгм тема нереляционности MySql не раскрыта...ждем...особенно пассаж про файлы понравился...

[Алексей Евдокимов]

Мгм тема нереляционности MySql не раскрыта...ждем...особенно пассаж про файлы понравился...

Не забывай, пока что на дворе 2002 год, мускуль ещё до стабильной четвёрки не добрался... Какая там нафиг реляционность, MyFile -- одно слово...

[Алексей Мокрушин]

Меня смутила вообще то привязанность слова "реляционность" к организации БД... пальцем в небо как то...я думал реляционность и система организации БД внутри ФС разные вещи...

[Алексей Евдокимов]

Меня смутила вообще то привязанность слова "реляционность" к организации БД... пальцем в небо как то...я думал реляционность и система организации БД внутри ФС разные вещи...

Ну, само слово "реляционная" может соответствовать только такой модели организации БД, когда пространство значений какого-то поля из одной таблицы является пространством возможных значений связанного поля из другой таблицы, и ограничение это строгое. То бишь, если между хранимыми данными присутствует ссылочная целостность, поддерживаемая самой базой.

Какими именно средствами Системы Управления БД такое поведение поддерживается -- это уже другой вопрос, тут много вариантов...

Иначе "реляционной" базу называть нельзя... Так что MySQL на описываемый момент ни реляционной, ни какой другой СУБД не являлся... А являлся простым хранилищем типизированных записей с интерфейсом SQL. Сейчас эту нишу занимает SQLite, между прочим.

[Алексей Мокрушин]

Так вообще то ссылочная целостность данных поддерживалась всегда...видимо Вы, Алеске, знаете лишь одну модель ссылочной целостности - транзакционную... Видимо вы не читали хорошо вводную часть по MySql...там все это описано было и давно - я начал знакомство с 3.23.хх И она соответсвует Вашему описанию реляционности. А уж реверансы на тему хранилища с интерфейсом SQL...тоже никак не выдерживают критики...

[Алексей Евдокимов]

Так вообще то ссылочная целостность данных поддерживалась всегда...видимо Вы, Алеске, знаете лишь одну модель ссылочной целостности - транзакционную... Видимо вы не читали хорошо вводную часть по MySql...

Алексей, Вы меня неправильно поняли. Я немного о другом говорю, вообще-то. Точнее, совсем о другом. Читайте внимательнее.

И про транзакции я тоже весьма ясно высказался в первой части -- причём, прошу обратить внимание, в контексте отсутствия триггеров и ХП, а не самих транзакций как таковых (которые не спасают при ошибках во внешнем -- относительно БД -- коде)... Опять же -- читайте внимательнее, а не по диагонали.

Чем друг от друга отличаются модели БД, и что означают понятия типа "ссылочной целостности" -- я прекрасно знаю. Но речь идёт о несколько более комплексных вещах, и не надо цепляться за какое-то одно истолкованное с другой стороны понятие, коряво написанную фразу, и строить неправильный вывод, что автор -- некомпетентен.

Если Вы хотите иметь чёткое математически выверенное описание того, что из себя должна представлять база данных CMS -- так напишите его! Все только спасибо скажут. ;D

[Алексей Евдокимов]

Вообще, если уж пошла такая пьянка, то в MySQL 3.23 дефолтной storage engine была MyISAM, которая ни foreign keys с constraint'ами не умела, ни транзакции по-человечески не поддерживала. (Что в офицальном мануале 2002 года издания прямо указано. Могу процитировать, он у меня нашёлся, мануал этот...)

InnoDB стала доступна только в 4.0, после чего была обратно портирована на ветку 3.23 -- но уже сильно позже.

Так что, попрошу впредь замечания делать по теме...

[Алексей Евдокимов]

Сегодня получилась настолько коротенькая главка, что я выложу её текст полностью:

[hr]

WRONG DESIGN DECISIONS,
ИЛИ ПЕРЕКУР НА ПЕРЕПУТЬЕ

Процесс разработки любого ПО цикличен. Типичный (классический для большинства систем) жизненный цикл включает в себя множество этапов, которые повторяются для каждой новой версии: постановка задачи ? эскизное проектирование ? начальное кодирование ? рефакторинг кода ? окончательное кодирование ? отладка ? опытная эксплуатация ? исправление ошибок и выпуск промежуточных версий ? эксплуатация в production environment ? сбор пользовательского feedbak?а ? уточнение задачи для новой версии? И так далее, по кругу, до тех пор, пока программный продукт интересен пользователям, и приносит доход разработчику.

При разработке s.e второй ветки этот цикл прошёл несколько итераций, и накопилось большое количество feedbak?а с обеих сторон: пользователям нужен был ещё более простой и понятный интерфейс, а разработчику требовалось повысить эффективность кодирования. То есть, в полный рост встала задача разработки некоего универсального фреймворка, включающего в себя качественный пользовательский GUI и не менее качественный API.

Летом 2003 года было принято решение такой фреймворк написать. Причём имелось два возможных пути: а) выделить в кодовой базе 2.0 некое ядро и отшлифовать его, и б) разработать новое ядро с нуля.
В первом случае хорошо использовался унаследованный код (которого накопилось на тот момент уже порядочно) и была возможность оставить совместимость с существующим форматом БД ? для уменьшения затрат времени на перенос проектов на новую версию. Во втором случае у разработчика оказывались развязанными руки для масштабного экспериментирования.
К тому же, не будем забывать эмпирическое правило, описанное в главе о релизе 1.1 ? никакая сложная система с мощной теоретической проработкой не бывает реализована в коде в полном объёме сразу.

В итоге было решено стартовать третью ветку CMS (и только CMS) с имеющейся кодововой базы и параллельно начать эксперимент по реализации более универсального фреймворка для произвольных информационных web-based систем, и реализации имевшихся наработок (то есть, CMS) в его рамках заново.
Первый проект остался всё тем же small.engine CMS, но ветки 3.0, второй проект после долгих раздумий обрёл имя swift.engine.
На протяжении второй половины 2003 года оба проекта существовали и развивались параллельно, и в итоге всё-таки слились в один. Поэтому первая версия swift.engine числится, как ни странно, за номером 3.0.
При этом на основе фреймворка swift.engine в недрах Мультимедиа центра выросла ещё одна система ? Каталог интеллектуальных продуктов вуза (КИПр ВУЗ), предназначенная для нужд научной библиотеки УдГУ. Ею занимался второй программист.

Если с первым проектом сложностей не возникло ? в small.engine ветки 3.0 попросту обкатывались новые модули CMS, то при постановке задачи создании фреймворка swift.engine решались проблемы помасштабнее.

Во-первых, на какой платформе он должен был работать?
Весной 2003 вышел стабильный релиз MySQL 4.0, и уже можно было, не опасаясь несовместимостей, использовать transaction-safe SQL в условиях хорошей нагрузки на сервер. Примерно в то же время PHP четвёртой версии уже совершенно заматерел, был хорошо оптимизирован, и с поддержкой объектно-ориентированного кода в нём было уже всё в порядке. То есть, можно было попытаться реализовать объектно-ориентированную серверную часть с транзакционной, следящей за целостностью данных, ?умной? базой. Сделать нормальную трёхзвенку.
А можно было попробовать забыть о LAMP и перейти на .NET, например.

Во-вторых, фреймворк обязан был поддерживать несколько информационных систем с одной установленной копии ? для создания мультисайтов, например.
Эта задача решается достаточно тривиально ? в зависимости от стартового URL приложение использует тот или иной набор таблиц в базе данных, или вовсе переключается на другую базу данных, однако, и здесь свои подводные камни имеются.

В-третьих, предыдущий список требований никто не отменял ? фреймворк просто обязан быть очень быстрым и очень надёжным. И работать он должен был на любом железе с операционной системой исключительно стандартной конфигурации ? то есть, быть переносимым, а ещё лучше ? кроссплатформенным.

Вот это ?в-третьих? как раз и оказалось тем камнем преткновения, который перевесил чашу весов серверной части фреймворка на всё тот же, устаревший на тот момент, но актуальный и по сей день, диалект LAMP ? MySQL 3.23, PHP4 без ООП. А клиентская часть могла быть ориентирована только на пользовавшийся в тот момент исключительным положением (более 95% пользователей выбрали именно его) Internet Explorer 6.0.

Это тот самый тупиковый путь, который вынесен в заглавие всей книги, однако, стена в конце туннеля стала видна только через два года?

А сейчас пора крутить стрелку часов назад, в август 2003 года, когда вышла версия small/swift.engine 3.0.0?

[hr]

Мораль: думать надо всё-таки на перспективу.

[Алексей Мокрушин]

Вообще, если уж пошла такая пьянка, то в MySQL 3.23 дефолтной storage engine была MyISAM, которая ни foreign keys с constraint'ами не умела, ни транзакции по-человечески не поддерживала. (Что в офицальном мануале 2002 года издания прямо указано. Могу процитировать, он у меня нашёлся, мануал этот...)

InnoDB стала доступна только в 4.0, после чего была обратно портирована на ветку 3.23 -- но уже сильно позже.

Так что, попрошу впредь замечания делать по теме...

Алеске, Вы меня не поняли, я не настаивал ни в коем разе на неограниченной функциональности 3.23.хх версий - right там был уже MyISAM что много лучше простого ISAM... на счет внешних ключей и констрейнов...это уж зависит от схемы БД...иногда оно и не нужно и может быть реализовано сторонне. Это все не умоляет недостатки того MySql просто мне сразу захотелось ясности определений - спасибо, я ее получил ;-)