|
Бази данни, AXMLS Схема, библиотеки ... => 1.7 Интересен въпрос е миграцията базата на Moodle към Oracle. Още в началото бих искал да уточня няколко неща. Oracle е платен сървър и аз лично не одобрявам тази идея но това си е мое мнение и никого не ангажирам с него. Като ПЛАТЕН такъв не мога да отрека, че е много добър. Все пак Moodle е отворен код. Мартин е дал възможност на много хора да работят по проекта ползвайки предимно бази данни на MySQL отново свободна платформа. Мартин Догиамас е (няма да крия) мой идол, от тази гледна точка считам за неуместно намесата на компании като Oracle. Второто нещо което бих искал да уточня е, че въпроса не е толкова в това какъв е сървъра за базите данни, а каква е тяхната организация. Много често оптимизацията, разработката, синхронизацията, проектирането и там всичкко останало се нарича backend developmend. 
На фигурата са показани ключовите таблици от базата на Moodle, user и course, както и на някой други по-важни релации. В действителност картинката е с много по-големи размери (1584 на 1753) и итеглянето и е възможно. DBDesigner_ERDiagram
На фигурата са показани ключовите таблици от базата на Moodle, user и course, както и на някой други по-важни релации. В действителност картинката е с много по-големи размери (1000 на 1000) и итеглянето и е възможно. За тази визуализация е използван графичния инструмент Schemaball
На фигурата са показани ключовите таблици от базата на Moodle, user и course, както и на някой други по-важни релации. В действителност картинката е с много по-големи размери (1000 на 1000) и итеглянето и е възможно. За тази визуализация е използван графичния инструмент Schemaball
Аt- Аналогия
Та мисълта ми беше по въпроса с организацията на релационния модел на базите данни в Moodle. Тук Петър Атанасов е абсолютно прав като казва, че въпроса с релациите, ограниченията, минимизацията, синхронизацията ... е МНОГО ВАЖЕН!!! Така естествено като една от първите задачи преди да се мисли за това къв да е сървъра за базата данни е по смисленно да се оптимизира вече съществуващата организация на таблиците и връзките между тях. Второ, в момента в рамките на 1.7 се разработва вариант при който ще се използва схема за базите данни която няма да зависи от това какъв е точно сървъра за базите данни. Преди доста време бях писал тук в някой от форумите за XML-лизацията на базата данни. Основна роля в процеса на неутралната база данни играят AXMLS Схемата и ADOdb. Третото нещо което ме вълнува и много бих искал да споделя е скоростта на търсене в такава база данни, както и миграбията на огромното количество модули разработени вече за MySQL. Едно от предстоящите нови неща които ще се случат в областта на бекенд дивелъпмънта (разработката на структурата и оптимизацията на базата данни в този слой на приложението) е новата функционалност даваща възможнос на Moodle да работи с много повече сървъри за бази данни от поддържаните в момента.
Стекът Изискванията които първоначално е необходимо да се изпълнят преди да бъде реализирана същинската цей, а именно Moodle да работи с много системи за управление на релационни бази данни RDBMS са: един слой за създаване и обновяване на базите данни (DDL или както му казват Data Definition Language) Уточнение: DDL е език за дефиниране на данни. Един пример за чист DDL това е XML Схемата. Подмножество на SQL инструкциите от друг DDL. Използвайки този нов слой в Moodle разработчиците ще могат да изграждат структурите си в едина неутрална форма независеща от точната имплементация за конкретната системе за управление на релационни бази данни. Другото предварително изискване е един слой за транспортиране и управление на базите данни даващ възможност на разработчиците да правят заявки и да съхраняват информация в една неутрална, независеща от конкретната имплементация за RDBS. За целта се използва Data Manipulation Language (DML), всъщност DML си е набор от езици за обработка на данните в релационни бази данни. Една друга форма на DML е IMS/DL1. Организацията на функционалните възможости на езиците за манипулиране на данни се базира на първата дума в израза, което при SQL почти винаги си е глагол. Друго не-функционално предварително изискване е ясното обявяване на един опростен път за лесна миграция от предишните версии. До момента надграждането на Moodle усложняваше работата на разработчиците дори ако става дума на писане на инсталационни скриптове за добавяне на модул или плъг-ин (малки софтуерни добавки) . Новия подход е един файл за инсталиране и един файл за обновяване на модулите, блоковете, плъг-ините, филтлите и т.н. В новата версия 1.7 е залегнало вече изискването да се намали условното използване на код. Това означава местата във файловете на библиотеките с php класовете за базите данни където до момента е можело да участва потребителски код ще се намалят. Не на последно място разбира се от голямо значение е подробното документиране на дефинираните функции кактои на DDL и DML слоевете, та последото ще помогне на разработчиците правилно да се ориентират в задачите.Стекът на кода на Moodle 1.7 показва как последният ще си взаимодейства с основните RDBMS За взаимодействието си с базите данни се предвижда Moodle да използва два езика. За променяне и изтриване в базата данни ще се използва XMLDB, т.е. неутрални описателни файлове за данни. По-горе вече споменах за DDL. Неутралните SQL изрази за операциите с информацията в базата данни. По-горе вече говорих за DML. Използваните ключови думи подсказват, че двата езика, ще бъдат 100% еднакви, независимо от използваните RDBMS. Това е от части вярно и за XMLDB. Всеки от посочените езици ще използва свои собствени библиотеки. Библиотеката Moodle DDL Library (т.е. файла DDLlib.php) съдържа вички обекти на базата данни и осигурява на разработчиците една голяма степен на абстракция. Като вход ще приема дефинирани обекти и ще изпълнява командите за конкретно използваната RDBMS. Библиотеката Moodle DML Library (т.е. файла datalib.php) съдържа функциите за управлението на съдържанието на базата данни и е променена така, че да осигурява на разработчиците висока степен на абстракция. Като вход приема параметри и изпълнява изразите за конкретно използваната RDBMS. И двете посочени библиотеки за работата си използват библиотеката абстрактни класове ADOdb Database Abstraction Library за PHP. Последната ще получава всички заявки от тях, ще омуниира с база данни на някакъв сървър за бази данни (MySQL, PostgreSQL, Oracle или SQL*Server), ще получава резултатите от обработката и ще ги връща обратно към изпратилата ги библиотека. Разширяванито възможностите на Moodle за поддръжка на повече сървъри за бази данни и самия процес на миграция се свежда до фази и
1. Разделяне на файла datalib.php на три части. Този файл съдържа фунциите за SQL DDL (table_column()...), SQL DML (select, insert...) . Първата част DDLlib.php ще се изполва само в началото за целите на миграцията, втората си запазва името и поддърржа и управлява DML-ла, и третата част състояща се от няколко файла съдържащи функции НЕ свързани с ADOdb ще се разпредели между няколко файла които ще се намират в course/lib.php, user/lib.php.. 2. Промени в DML функциите: В основни линии това включва промяна в support LIMIT клаузите които са емулирани под Oracle, транспортиране и управление на CLOB/BLOB (large text/binary objects...) 3. Необходима е сложна XML структура за дефиниране на всяка база данни, и цялата информация необхдима за преобразуването в използваеми DDL изрази за всяка RDBMS. 4. Следващата задача е създаването на нови DDL функции необходими за инсталирането на произволен компонент за БД на Moodle, нови функции за създаване на таблици, индексиране.. Всичко това ще се намира във файла DDLlib.php. 5. Необходима е промяна в процеса на инсталиране. За целта ще бъде въведен един нов XML файл който ще замени сега съществуващите *.sql файлове , сега съществуващите *php файлове ще бъдат заменени от един файл upgrade.php 6. Последната задача е докуменнтирането на всичко описано по-горе. Описания по горе процес неминуемо ще е свързан с доста проблеми и подводни камъни. Създаването на функцията SelectLimit() осигуряваща универсална съвместимост с различни типове бази данни е един от проблемите. Извикването на последната функция при Oracle ще отвори работа защото се емулира от ADOdb , поради забавянето в резултат на клаузата LIMIT. За да може ADOdb да извлече желания прозорец му се налага да итерира през голям брой записи. Още в началото на този материал (погледнете в началото) споменах нещо за търсене в много на брой и дълги записи. Друг проблем е несъответствието на сега съществуващата конвенция за имена на обектите в базата данни с тази която ще е в ADOdb мплементацията. Какво да правим с тези обекти? За Oracle например при необходими id ще са необходими допълнителни механизми в insert_record() нещо като get sequence nextval, insert record... Относно Oracle (дано не бъда обвинен в субективизъм) сериозни проблеми съществуват при вмъкването на CLOB/BLOB данни. Имам предвид двете стъпки INSERT empty_b/clob() и UPDATE Донякъде решението е описано http://phplens.com/ADOdb/reference.functions.updateblob.html и тук http://phplens.com/ADOdb/reference.functions.updateclob.html
Uses of the LIMIT offset have to be changed. num clause to use the cross-db compatible SelectLimit() function must be modified.
1. Splitting datalib.php
Currently there are 94 functions defined in lib/datalib.php where most of them (50) are not directly related with DML or DDL statements at all but with some commonly used DB transactions (let's call them functional functions. The rest (44) are core functions (from the perspective of being general, used by any script, to access to any table info), used to access to DB (with 42 functions used to handle data - DML - and 2 functions used to handle objects - DDL). The two approaches: 1. Create two new libraries (DDLlib.php and DMLlib.php) and leave datalib.php for functional functions.
For Oracle: http://www.cs.umbc.edu/help/Oracle8/server.815/a68003/01_04blt.htm
Regular expressions (Problems with Oracle (not available until 10g), Oracle 10g implements them using directly and one package existed since ages (Oracle 8i?) to handle them). SQL Limit performance ( SelectLimit() calls under Oracle because it's emulated by ADOdb on those DBs, because their lack of support for the LIMIT clause). Naming conventions (if previously created DB objects (indexes, unique indexes, sequences) naming schema doesn't fit with the implemented by ADOdb???
|