Доста често може да се изкушавате сами да написвате целия код за сортиране, проследяване и съхранение на информацията на вашите програми. Обикновено завършвате с желание да имате лесен начин за удовлетворяване на растящите нужди от записи, сортирания и т.н. Решението е в това да прехвърлите по-голямата част от обработката на данните в база данни.
Изборът на база данни е само 1/3 от необходимото проучване, за имплементиране на приложение с бази данни в Web. Все още съществува необходимостта от избор на другите два компонента - Web сървър и Сървъра за приложения (Web Application Server).Те ще бъдат разгледани в следващите глави на настоящата дипломна работа. Обект на тази са базите от данни.
И понеже започваме от самото начало, трябва да стартираме с дефинирането на база данни. Една добра работна дефиниция е:
"База данни е един вид колекция от организирани факти" (Ashenfelter, 1999)
Тази дефиниция покрива много голяма площ от реалния свят - от кутията за обувки със счетоводни документи, през счетоводна книга до сложните компютъризирани системи за разплащане. Всеки от предходните носители за съхранение представлява база данни. Проблемът е, че първите два типа бази данни не предоставят никакви вградени средства за автоматично сортиране, отпечатване или управление на данните. За да стане възможно това е необходима система за управление на бази данни.
Системата за управление на бази данни представлява набор от инструменти за управление на данни в определен формат. Бихте могли да създадете свой-собствен набор от инструменти или да закупите съществуващ такъв. Има едно нещо, което всички системи за управление на бази данни включват — машината за бази данни. Машината за бази данни (database engine) е приложението, като например Microsoft Access или Oracle, което обработва данните в базата данни. Тя е сърцето на вашата система за управление на бази данни. Обикновено тази система е или обектно-ориентирана, или релационна. Обектно-ориентирана система, която добива популярност все още не е налична за повечето настолни PC.
Базите данни осигуряват невидимата, но основна, същинска функционалност на съхраняването на данни и тяхната манипулация. По-голямата част са релационни, много използват SQL като основен език, и при повечето достъпът се осъществява чрез ODBC. Какво всъщност се има предвид под тези странни думи и съкращения?
Релационната база данни е съставена от таблици. Всяка таблица съдържа редове с информация за всеки съхранен в нея обект. Редът съдържа данни за един отделен обект и е съставен от колони с информация, която описва един този обект. Всеки файл на базата данни може да съдържа множество таблици и всяка таблица може да съдържа множество колони.
Една или множество таблици могат да бъдат достъпени и чрез изглед (view). Изгледът е логическо подмножество на таблица или комбинация от таблици. Той дефинира различен начин за достъпване, или разглеждане, на данните от таблицата, но самият той не съдържа данни. Позволява да създавате по-нататъшни логически връзки между таблиците, без да създавате второ копие на данните.
След като релационните бази от данни станаха популярни, възникна нуждата от стандартен език за операции с данни. Отговорът бе SQL (Structured Query Language, Език за структурирани заявки). Постепенно SQL прерасна в многофункционален език за работа с бази данни с управляващи конструкции за: създаване, промяна и изтриване на данни; дефиниране на данни (таблици, колони); защита на достъпа до елементи от бази данни чрез работа с групи и индивидуални потребители; операции за управление на данните като създаване на архивни копия, блоково копиране и актуализация; и, най-важното, обработка на транзакции.
Общата форма на SQL се нарича ANSI-SQL, но всеки производител на СУБД има собствена реализация на SQL. B SQL сървъра на Microsoft, който е една от клиентско/сървърните релационни СУБД, е реализиран диалект на SQL с име Transact/SQL, докато SQL на Oracle се нарича PL/SQL. Но фактически всички комерсиални (релационни) продукти за бази данни разбират SQL, въпреки че повечето също имат и собствени специални диалекти. Това означава, че за по-голямата част заявките за базата данни, разработени за използване с точно определена база данни, са преносими от един продукт или инструмент до друг. SQL кодът, написан от програмист използващ настолни (desktop) бази данни, като Microsoft Access, могат да бъдат използвани на система, с инсталирана корпоративна (enterprise) база данни, като Oracle, без съществени промени. Освен това SQL се използва не по-малко от езици като Java, C++ и други поради възможностите, които предоставя в областта на работата с данни и управлението на бази данни.
Един от най-често използваните диалекти на SQL е PL/SQL. Той се използва в управлението и работата на/с бази данни от Oracle корпорацията и е процедурен език, с разширения към SQL. Основната му цел е да комбинира език за бази данни с процедурен програмен език. Основната част в PL/SQL се нарича блок, който от своя страна се дели на три части: декларативна, изпълнима и за построяване на изключения.
Понеже PL/SQL позволява смесването на SQL декларации с процедурни конструкции, е възможно PL/SQL блоковете и подпрограмите да се групират със SQL частите, преди изпращането им до Oracle сървъра за изпълнението им. Без PL/SQL, Oracle трябва да създава процес за всяка SQL декларация поотеделно, в мрежова среда, като това може да повлияе на потока на трафика и да забави неимоверно времето за отговор. PL/SQL блоковете позволяват единствена компилация и съхраняване във форма за изпълнение за подобряване времето на отговор PL/SQL програма, която е запазена в базата данни във форма за компилация, и чието извикване става чрез името й, се нарича запазена процедура (stored procedure). PL/SQL запазена процедура, която се стартира безусловно, в резултат от изпълнението на INSERT, UPDATE или DELETE част, се нарича тригер (trigger)
Transact-SQL е процедурен език, използван и при Microsoft SQL Server и при Sybase SQL Server системите. Това е програмен език, снабден с всички способности, който драматично разширява силата на SQL. Този език осигурява на програмистите широк спектър от възможности, включително:
Системните запазени процедури (stored procedures), които намаляват сложността на много операции, се справят с добавяне на потребители или автоматично генериране на HTML Web страници.
Докато SQL осигурява общ синтаксис за разработване на заявки, все още съществува необходимостта от протокол, който може да приема този стандартен синтаксис, да го превежда на естествен за процедурни извиквания език и в действителност да извършва заявката. Open Database Connectivity (ODBC) стандартно осигурява абстрактен слой между приложния интерфейс и базата данни, който ефективно скрива разликите и странностите на всяка специфична база данни. ODBC и SQL имат поддръжката на всяка основна софтуерна компания в света, включително Microsoft, Sun и IBM.
ODBC, съкращение от Open DataBase Connectivity (конективност между отворени бази данни) (може да мислите за това като за универсален конектор) е един от най-популярните интерфейси за бази данни на РС-съвместимите компютри и бавно завоюва позиции и на другите платформи. Ако искаме да дефинираме с едно изречение какво представлява ODBC, то ще е (Roberts, Helar, Earnest, 2000): “ODBC предоставя функции за операции над бази данни от език за програмиране включително добавяне, модифициране и изтриване на данни, намиране на различни параметри на базите данни, таблиците, виртуалните таблици и индексите.”
Всяко приложение, поддържащо ODBC, се състои от пет логически слоя:
Слоят "приложение" осъществява потребителския интерфейс и изчислителната част на програмата и е написан на език като Java, Visual Basic или C++. Приложението използва функциите за работа с ODBC от интерфейса за ODBC. Диспечерът на драйверите е част от ODBC на Microsoft. Той управлява наличните драйвери зарежда необходимия драйвер, насочва извикванията към него, предоставя информация за драйвера на приложението. Тъй като една програма може да взаимодейства с база данни, диспечерът на драйверите се грижи всяка СУБД да получава съответстващите й извиквания и данните от базите да бъдат безпроблемно предавани на приложенията Драйверът е компонент, който съответства на конкретната база данни, например драйвер за Access, за SQL Server или Oracle. В интерфейса към ODBC има набор от функции като SQL заявки, управление на свързването, запитвания за информация относно бази данни и др. Изпълнението им се осъществява именно от драйвера. За някои бази данни той трябва да симулира изпълнението на функции, които не се поддържат пряко от съответната СУБД. Всъщност работата на драйвера се състои в изпращането на заявки към базата. получаването на данни и препращането им към приложението. За бази данни в локални мрежи или Internet драйверът също така управлява мрежовия обмен. В контекста на ODBC източникът на данни може да бъде СУБД или просто набор от файлове върху твърд диск.
Основната част от ODBC система е драйверът, за който стана дума по-горе, и който всъщност осъществява обмена с базата от данни. ODBC не изисква драйверът да поддържа всички функции на интерфейса. Вместо това са дефинирани нива на съвместимост с ODBC по отношение на програмния интерфейс и синтаксиса на SQL заявките. Единственото изискване е, когато драйверът отговаря на някакво ниво на съвместимост, да поддържа всички функции от това ниво независимо от това дали те са включени в СУБД. Таблицата от Приложение А обобщава нивата на съвместимост за програмния интерфейс и SQL.
Драйверът трябва да емулира ODBC функциите, които не се поддържат от използваната СУБД по такъв начин, че за интерфейса към ODBC реализацията на СУБД да няма значение. Приложенията използват функции от програмния интерфейс като SQLGetFunctions и SQLGetInfo за получаване на информация за поддържаните от драйвера функции.
Tова може да разберете в подробност от (Perl, CGI & JavaScript - SYBEX), затова тук ще се спрем само на част от написаното в тази книга: “Модулът Win32::ODBC стана стандарт за свързване на Win32 приложения към различни програми за бази данни. Той, както и другите ODBC приложения се свързват към вашата база данни (примерно Access) чрез DSN име (Data Source Name - име на източник на данни). Това е стандартен начин за комуникиране с всички бази данни, който се изисква от ODBC, за да може да се работи с много и различни машини за бази данни.”
DSN съдържа общ набор от информация, която всички бази данни трябва да предоставят, затова е необходимо създаването на DSN име, преди свързването на дадена програма към база данни. Ето каква информация се извлича от DSN името:
Има два основни типа DSN имена:
Можете да създавате DSN имена през Control Panel на Windows или като използвате в програмите си модула Win32::ODBC.
За да създадете DSN име чрез програма, първо е необходимо да знаете какви драйвери има на компютъра ви. Програмата на Perl по-долу използва модула Win32::ODBC, за да събере списък от всички ODBC драйвери и да ги отпечата на монитора
use Win32::ODBC;
#получава наличните драйвери
%drivers = Win32::ODBC::Drivers( );
#при отпечатването на атрибутите на драйверите те са разделени със запетая
local $” = “, “;
foreach $driver (sort keys %drivers){
@attributes = split (/;/,$drivers{ $driver} );
print “Driver = $driver\n“;
print “@attributes\n\n”;
}
В Приложение Б е разгледана програма на Perl, която показва как се създава DSN за Access база данни, в която искаме да пазим информация за email адрес и името на лицето за контакт.
По начина, описан по-горе, използвайки методите Win32::ODBC, може да се осъществи връзка към база данни, да се създадат таблици, да се извличат или вмъкват данни. За повече информация по темата можете да посестите www.roth.net. Там може да се намери модула Win32::ODBC както и още документация по темата.
Стандартният достъп до релационни бази от данни е важен и за програмите на Java, тъй като те по природа не са монолитни, съдържащи всичките си данни приложения. Те са модулни и се нуждаят от външни бази от данни, от които четат, обработват и записват обратно данни, които после да бъдат използвани от други аплети. Монолитните приложения могат да си позволят собствени схеми за съхраняване на данните, но пресичащите границите между операционни системи и платформи аплети трябва да използват отворени стандартни схеми за достъп. JDBC (Java Database Connectivity, Връзка на Java с бази данни) на Java Enterprise е първият междуплатформен и поддържащ много СУБД програмен интерфейс за използване на бази от данни от програми на Java. От гледна точка на разработчика JDBC е първият стандартизиран метод за интегриране на Java с базите от данни.
Други приложни програмни интерфейси на Enterprise са RMI, средствата за сериализация, Java IDL (Interface Definition Language, Език за дефиниране на интерфейси) за комуникация с CORBA и др. В проектирането на JDBC са използвани основни абстракции и методи от ODBC. Идеята за базиране на JDBC върху ODBC идва от това, че ODBC е популярен сред независимите разпространители на софтуер, както и сред потребителите и реализирането и използването на JDBC ще бъде по-лесно за хора, работили с ODBC. Освен това Sun и Intersolv разработват програми за връзка JDBC-ODBC, за да се използват многобройните съществуващи ODBC драйвери. С JDBC и тези програми ще можете да се работи с фактически всяка бази данни от средата на програми и аплети на Java.
JDBC е набор класове и методи за взаимодействие на програми на Java с източници на данни. Той е базиран на X/Open SQL Call Level Interface (CLI), както и ODBC, за да се приеме лесно от разработчици и потребители. ОDBC е интерфейс на С към СУБД, поради което не е толкова лесно да бъде прехвърлен на Java, затова JDBC следва концепциите, заложени в ODBC, но едновременно с това е програмен интерфейс, напълно съвместим и еднотипен с останалите програмни интерфейси за Java и на места предлага по-прости за използване решения от ODBC. Най-общо архитектурата на едно приложение, използващо JDBC може да бъде видяно на фигурата, по-долу:
В JDBC е дефиниран набор класове и методи за взаимодействие със СУБД. В програмата на Java се отваря връзка към базата данни, създава се обект-заявка, SQL заявката се препраща към СУБД чрез този обект, и се получава резултата, както и допълнителна информация. Обикновено класовете от JDBC и приложението на Java се намират на клиентския компютър. Те също така могат да бъдат заредени от мрежата. За да се намали загубата на време, по-добре е класовете на JDBC да са инсталирани при клиентската част. СУБД и източникът на данни обикновено се намират на отдалечен сървър. Приложението и JDBC осъществяват взаимодействие на клиентската машина, а драйверът се грижи за обмена с базата от данни по мрежата.
Класовете от JDBC са в пакета Java.sql и се използват от всички програми на Java за четене и запис в източници на данни. Програма, използваща JDBC, се нуждае от драйвер за съответната СУБД. Допустимо е приложение да работи с няколко разнородни източника на данни. Затова в JDBC е вграден диспечер на драйверите, чието предназначение е да управлява драйверите и да предоставя списък на наличните драйвери на приложенията.
Като част от JDBC е включен драйвер за достъп до източници на данни, поддържащи ODBC. Драйверът е разработен съвместно от JavaSoft и Intersolv и се нарича JDBC-ODBC bridge. Реализиран е като файл JdbcOdbc.class и като машинно зависима библиотека за достъп до ODBC драйвера. За Windows машинно зависимата библиотека е файл JDBCODBC.DLL. Тъй като JDBC и ODBC са доста близки, драйверът за връзка между тях не е много сложен. Той всъщност преобразува извикванията на методи от JDBC в извиквания на функции от ODBC и по този начин може да взаимодейства с всеки ODBC драйвер. Като резултат JDBC може да осигурява достъп до почти всички бази данни поради широкото разпространение на ODBC.
Програмата на Java, взаимодействаща с база от данни, обикновено работи по следния примерен план. Първо се извиква методът getConnection за получаване на обект от тип Connection. След това се създава обект от тип Statement и се подготвя SQL заявка.
SQL заявките могат да бъдат изпълнявани директно (обект от тип Statement) или да бъдат компилирани (обект от тип PreparedStatement). SQL заявките могат да бъдат и извиквания на съхранени процедури (stored procedures) (обект от тип CallableStatement). При изпълняване на метода executeQuery( ), резултатът е обект от тип ResultSet. SQL заявки като UPDATE и DELETE не връщат резултат, затова за тях се използва методът executeUpdate( ). Той връща резултат от тип int, съдържащ броя променени записи. Обектът от тип ResultSet съдържа записи с данни, които могат да бъдат обходени с метода next( ). В случая на приложение, работещо с транзакции, могат да се използват методите rollback( ) и commit( ) за потвърждаване или отменяне на промените, предизвикани от SQL заявката.
Според някои автори (Marty Hall, 1999), “JDBC предоставя стандартна библиотека за достъп до релационни бази данни. Използвайки JDBC API интерфейса, можете да осъществявате достъп до множество различни SQL бази данни чрез един и същ Java синтаксис. Важно е да се отбележи, че въпреки че JDBC стандартизира механизма за свързване с бази от данни, синтаксисът за изпращане на заявки и за изпълнение на транзакции, както и структурата на данните, представляващи резултатите, JDBC не се опитва да стандартизира SQL синтаксиса. Така че можете да използвате произволни SQL разширения. Но тъй като повечето заявки следват стандартния SQL синтаксис, употребата на JDBC позволява да промените хостове на бази от данни, портове и дори производителя с минимални промени във вашия код”.
За повече подробности относно:
Вашите данни могат да съставляват съдържанието на страницата или да определят как ще изглежда тя, но каквато и да е дейността им, те са основната част от нея. Ако изграждате Web страница около хранилище на данни (data store), то за да промените страницата си, ще трябва сами да промените данните.
Идеята на ADO (Active Data Objects) — да предоставят общ набор програмни интерфейси на хранилищата на данни, защото трябва да има само един начин за достъп до данните. Идеята не е нова, тя взема най-доброто от съществуващите технологии за достъп до бази данни и ги обединява в една технология, която да отговаря на съвременните и бъдещи изисквания. Възможността да се справи с бъдещите изисквания е особено важна. Много други технологии, като DAO и ODBC, са съвсем подходящи за използване от много приложения, но развитието на Интернет поставя проблеми пред тях.
ADO са компоненти, които позволяват да се работи с базите данни. Може да се използват както за да си направи Web страница, базирана на някакви данни, така и за да се изгради изцяло интерактивен сайт за електронна търговия, например.
Ще отговорим на този въпрос като направим сравнение с някои съществуващи технологии за достъп до данни.
Както обяснихме по-горе, ODBC е Application Programming Interface (API - приложен програмен интерфейс), който позволява достъп до релационни бази данни, като Access и SQL. Тъй като ODBC e API, за много npoграмисти особено за тези на Visual Basic, тя изглежда трудна за употреба. Remote Data Objects (RDO - отдалечени обекти с данни) са ActiveX обекти, които стоят в ODBC и предоставят всички възможности, осигурявани от ODBC, но в лесна за използване форма.
OLE DB е базовата технология, която служи за интерфейс между нашите програми и източника на данни. Системата е доста заплетена и се използва само от програмистите на С и C++. ADO, както предполага името, представляват съвкупност от ActiveX обекти, които предоставят лесен достъп до OLE DB. Следователно можем да приравним OLE DB c ODBC и ADO c RDO.
Въпреки че Microsoft създават нова технология за достъп до данни, те не отписват автоматично старите. Идеята на OLE DB е не да премахне съществуващите технологии, а да ги доразвие.
След като дадохме кратко обяснение на това какво представляват OLE DB и ADO, трябва да видим и къде е мястото им в цялостната картина. Диаграмата показва мястото на двете технологии по отношение на приложенията и хранилищата на данни:
В началото имаме приложение. Под него са ADO и/или OLE DB, които осигуряват достъп до данните. Причина за наличието и на ADO, и на OLE DB е, че OLE DB е базовата технология. OLE DB обаче не е проектирана да се използва от всички езици; така че ADO стои върху OLE DB и осигурява интерфейс за тези езици, като Visual Basic и скриптовете, които нямат директен достъп до OLE DB. Освен това ADO осигурява по-лесен програмен интерфейс от OLE DB, така че дори и езиците, които могат да използват OLE DB директно, като C++ и Java, могат да използват ADО, за да опростят достъпа до данни.
Тъй като ADО е СОМ компонент, може да се използва и от всеки съответстващ на COМ език като Delphi, или скриптовите езици, поддържащи Active Scripting интерфейс. Така че, въпреки че ADO, бидейки разработка на Microsoft, все още не е платформено независим, той е езиково независим.
OLE DB и ADO осигуряват достъп до данни, но какво им е лошото на старите методи?
OLE DB и ADO ca проектирани да осигуряват достьп до хранилище на данни, а не до бази от данни. Въпреки че базите данни все още са най-разпространената форма на съхранение на данни, не е задължително те да съдържат всичките ви данни. Системите за обмен на съобщения се използват широко за съхранение на данни; започват да се появяват и Directory Services (директорийни услуги), които съдържат данни за потребителите, машините и т.н. Web сървърите съхраняват огромни обеми информация. Списъкът може да бъде продължен, така че се появява необходимостта от съществуването на начин за достъп до всички тези различни типове данни.
Другата причина за предпочитането на OLE DB и ADO е развитието на Интернет приложенията и динамичната структура на мрежата. Старите методи за достъп до данни не са проектирани да обработват данни, когато не са постоянно свързани с източника им. OLE DB и ADO са създадени да превъзмогнат това - те осигуряват несвързани набори от записи.
На диаграмата на ADO архитектурата се вижда, че ADO се намират между приложението и хранилището на данни. Какво значат термините консуматори (Consumers) и доставчици (Providers)?
“Доставчикът предоставя данните, а консуматорът ги използва (консумира).
Хранилището на данни доставя данните, с които работят приложенията, използващи базите данни, като OLE DB може да общува с различни хранилища на данни, а всяко хранилище е свързано с OLE DB доставчик (Provider).” (Homer, Sussman, Francis, …, 1999 - Profesional ASP 3.0)
Идеята за несвързани доставчици не е нова, но прави програмирането по-лесно. Програмата се пише така, че да може да взаимодейства с ADO или OLE DB, a OLE DB взаимодейства с доставчика. По този начин е достатъчно да научаването само на един набор от правила за достъп до данни, независимо къде се съхраняват те.
Доставчици на OLE DB можете да намерите от Microsoft, от други производители за други хранилища на данни, а можете и да напишете свой доставчик.
OLE DB достъп до съществуващите ODBC източници на данни се осигурява чрез включването на OLE DB доставчик за данни. Ползата от него се дължи на факта, че ODBC е по-широко разпространена от OLE DB и съществуват повече ODBC драйвери, отколкото OLE DB доставчици.
Диаграмата показва разликата между доставчиците от драйверите:
Доставчиците са на нивото OLE DB, а драйверите - на нивото ODBC.
Тъй като по-голямата част от базите данни имат почти едни и същи характеристики – релационни са, достъпът до тях се осигурява чрез ODBC (или чрез някои от разновидностите му – JDBC и OLE DB, в зависимост от приложението), езикът за заявки е SQL (или негов диалект). Затова от гледна точка на изграждането на Web база от данни, има някои различия между възможните избори на бази от данни, които не се отнасят до платформа, цена и представителни характеристики.
Като цяло базите данни могат да бъдат разделени на две категории: настолни (desktop), за малко потребители и корпоративни (enterprise), за много потребители.
Настолните бази данни (desktop databases) обхващат тези, които могат да работят на едни от най-известните операционни системи: Dos, Windows или Macintosh. По принцип те не се справят добре при почече от пет или десет потребителя едновременнo, но не са скъпи и са значително по-опростени в сравнение с инструментите от корпоративно (enterprise) ниво. Тази фамилия от инструменти е най-подходяща за малки Интранет приложения в работна група или на ниво-отдел, с нисък трафик на интернет сайтове, и като разработване на платформи за по-сложни приложения. Таблицата по-долу разглежда някои от най-популярните настолни бази данни (desktop databases), включително и дали те използват SQL и дали съществува ODBC драйвер.
| Платформа | SQL | ODBC | Опции | |
| Access (Microsoft) | Win | Да | Да | MS SQL Server |
| FoxPro (Microsoft) | Win, Mac, DOS | Да | Да | Unix ODBC drivers |
| FileMakerPro (FileMaker) | Win, Mac | Не* | Не* | FileMaker Server |
| Excel (Micorosoft) | Win, Mac | Не | Да | Конвертира до Access |
| ASCII/Text file | Win, Mac, DOS | Не | Да | Вмъкване в базата данни |
| * FileMaker Pro може да импортва в други бази данни, използвайки SQL заявки чрез ODBC, но не използва SQL за изграждане на заявките си и не използва ODBC драйвери | ||||
Microsoft Excel и ASCII файловете не са бази данни сами по себе си, но често се използват като такива, особено от начинаещите потребители и малкия бизнес. Текстовите файлове (наричани още "плоски файлове" - flat files) често се използват като източник на информация, или са въведени в "истинския" продукт с база данни. За оставащите три бази данни е важно да отбележим, че всички са релационни бази данни с възможност за използването им и за изграждане на приложения, и за развитието им. Те са и не мнго скъпи, цените им варират между $200 и $250 в зависимост от функциите им.
Корпоративните бази данни (enterprise databases), са значително по-мощни, сложни и обикновено скъпи. Те могат да поддържат хиляди, дори стотици хиляди потребителя едновременно. Голяма част от тях имат сложни собствени разширения към SQL, за да представят съхраняване и разработване на огромен брой приложения. Те са основно релационни бази данни. Таблица 4 разглежда главните "играчи" на арената на корпоративните Web бази данни.
| Платформа | Бележки | |
| SQL Server (Microsoft) | Win (NT) | |
| Butler SQL | Macintosh | |
| Oracle (Oracle) | Unix, Windows NT | Обектно-релационна |
| Sybase (Sybase) | Unix (Linux) | Обектно-релационна |
| Informix(Informix) | Unix | Обектно-релационна |
| DB2(IBM) | Unix (AIX, Linux) | Обектно-релационна |
| MSQL(Huges) | Unix (vsichki) | Безплатна |
| MySQL | Unix (vsichki) | Безплатна |
Всеки от тези комерсиални продукти е базa данни, но в действителност е група от бази данни и инструменти за разработване на приложения, повечето включващи сървъри за приложения в Web (Web application server), за постигане на пълни решения за разработване на приложения с бази данни в Web. Изключенията от случая са двете безплатно разпространявани, опростени, но мощни текст-базирани бази данни за Unix, които поддържат SQL стандарта. Те не са от класата на другите приложения, ако разглеждаме гъвкавостта и силата им, но са често употребявани, защото струват хиляди долари по-малко от комерсиалните продукти.
Днес бизнес информацията се съхранява чрез някоя от водещите системи за бази данни на компании като IBM, Oracle, Informix или Sybase. Всъщност всички те са про релационни бази данни от корпоративно ниво, както вече стана ясно по-горе. Ще концентрираме вниманието си само върху основните производители.
В началото, когато Microsoft реши да навлезе в пазара на бази данни, тяхната разработка в тази област - SQL Server се насочи към към малките общности от потребители - работните групи (workgroups), с малки или средни нужди от съхранение на данни. SQL Server беше използван като средство за стимулиране на продажбите на новата операционна система на Microsoft - ОS/2-необходима беше база данни, за да се открие пътя и за следващата операционна система - Windows NT. Оттогава SQL Server се счита за база данни за работни групи (дори и след насочването му към Windows NT), и едва сега потребителите започват да го възприемат като продукт за бази данни от корпоративно ниво. Благодарение на мултипроцесорната поддръжка и по-доброто мащабиране на SQL Server, Microsoft навлезе на пазара на корпоративните бази данни.
Въпреки това SQl Server е проектиран така, че да се възползва от сигурността, анализа на представянето и начините за включване на Windows NT и Windows 2000. И по този начин да се позволи на разработчика да фокусира вниманието си над функционалността на приложението вместо да програмира пътища за комуникация между операционната система, Web сървъра и базата данни.
След появата на SQL Server 7.0 на Microsoft, Oracle представи своето предизвикателство - Oracle 8. За да се обърне гръб на използвания досега COM/DCOM и всичко, свързано с него Oracle се съсредоточи върху Java и CORBA и това стана тяхната основна стратегия при разпределените и Web архитектурите.
Въпреки това, Oracle не пренебрегват Microsoft - те поддържат DNA, COM/DCOM, OLE DB, ADO и, разбира се, ASP. От своя страна Microsoft предоставят OLE DB доставчик за Oracle, който е много стабилен и позволява същото ниво на функционалност както и SQL Server 7.0. Oracle разработиха и Oracle Objects for ОLE (OO4O), които осигуряват ActiveX функционалност. ОО4О могат да бъдат използвани от всички програмни и скриптови езици, включително и от ASP.
Сравнително лесно е да се свържете към Oracle база данни, като използвате OLE DB доставчика на Microsoft. Но освен него се използват много често и OLE DB ODBC доставчик и ODBC драйвер, които поддържат тази конкретна по-стара версия на машината на Oracle.
Oracle обаче предлага най-голямо разнообразие от поддържани платформи, но всяка от тях има различни особености. Най-лесният метод за достъп е OLE DB шлюзът, но той може да представи и някои нежелани ограничения.
IBM имат пет различни кодови бази за техните продукти от серията DB2, защото се разработват едновременно различни версии на различни места в компанията, базирани на различни операционни системи и платформи. По този начин IBM се опитва да излезе с обща масова база за своите релационни бази данни от серията DB2. Това ще гарантира съгласуваност на функционалността между различните продуктови линии, като по този начин ще се постигне единство на функционалността на цялата продуктова линия DB2.
IBM предимно набляга на разработването на Java стратегия, както и на XML интеграция на своите продукти за база данни. Поддръжката на СОМ, OLE DB и ASP става възможна чрез сътрудничество с други компании, които пренесоха тези технологии на платформите на IBM.
SNA OLE DB доставчикът, предоставен с Microsoft SNA Server, осигурява шлюз към тази богата на данни среда извън средата DB2.
Ключът към интегрирането на IBM DB2 данните се намира в сериозната поддръжка на стандарта SQL/CLI от страна на IBM.
Стратегията на Informix е да поддържат всички главни обектни технологии: COM/DCOM, CORBA и Java. Освен това полагат огромни усилия да интегрират XML във всички области, над които работят. Те са единствената компания, която работи по всички стандарти.
Informix поддържа собствен OLE DB доставчик.
Informix също така имплементира някои от по-сложните възможности като стандарт SQL-99. Компанията полага много усилия при разработването на областта на Data Warehousing. Informix закупиха и Cloudscape — стопроцентова Java SQL база данни. Тя представлява настолен продукт за бази данни, която лесно може да бъде вграждан. Cloudscape базата данни ще поддържа всички интерфейси, поддържани от останалите продукти на компанията, CORBA, СОМ и Java.
Продуктите на Informix за бази данни притежават голям потенциал и намират приложение в най-големите индустриални бази данни. Базите данни на Informix се предлагат както за UNIX, така и за Windows NT среда.
Продукта на Sybase е сходен с SQL Server на Microsoft. Но Sybase са изцяло отдадени на интегрирането на Java в техните разработки. Те са едни от първите участници в работата по изготвянето на SQLJ стандартите. Освен това основните усилия на компанията са насочени към интеграция на базите данни с Web.
Sybase поддръжа ODBC и OLE DB доставчик. Това подсказва, че компанията вижда бъдещето си обвързано по един или друг начин с ASP.
MySQL е open source релационна, управляваща бази от данни система (RDBMS), която използва SQL, най-популярния език за въвеждане, достъп и извършване на други процеси с данни в база данни. Понеже това е оpen soursе, всеки може да изтегли mySQL и да добавя към нея, в зависимост от общите публични правила. MySQL е известен основно заради скоростта си, сигурността и гъвкавостта си. Общоизвестно е обаче, че тя работи най-добре когато управлява съдържание и не извършва транзакции.
Системата за релационни бази данни mySQL осигурява приложен програмен интерфейс (API) за C, C++, Java, Perl, PHP, Python, и Tcl, допуска много типове на колоните и предлага пълна поддръжка на операциите и функциите в SELECT и WHERE частите на заявките.
Екипът, работещ по следващите версии на mySQL планира на представи mySQL 4.0 към средата на 2001. Във възможностите й ще се включват и нов файлов формат за дефиниране на таблица, подобряване на отговорите, и много функции за търсене на цял текст. Планира се mySQL постепенно да стане напълно ANSI 92/ANSI 99 поддържаща.
Понастоящем MySQL работи върху Linux, UNIX и Windows платформи. Голям е интереса към mySQL като алтернатива за подходящи системи бази данни от Oracle, IBM, и Informix.
За повече информация за MySQL, както и за изтегляне на самата система, посетете: http://www.mysql.com
Това е машина за бази данни (database engine), което не изисква голяма мощност от компютъра, и поддържа подмножество на ANSI SQL. То осигурява бърз достъп до съхранените данни с ниско потребление на памет, и работи върху голямо разнообразие на Unix системите: mSQL е разработен върху Sun OS 4.1.1, но е тестван под Solaris 2.x (версии 2.3, 2.4 и 2.5), Ultrix 4.3, Linux, and OSF/1. Едно от основните предимства е възможността да се използва безплатно с некомерсиална цел. МSQL поддържа само подмножество на SQL от гледна точка на интерфейса му за заявки, но всичко, което прави е с оглед на ANSI SQL спецификацията. Разпространението на mSQL включва mSQL сървър, програми за клиента, програмен интерфейс на С за софтуера на клиента, и няколко инструмента. Включения потребителски програмен интерфейс е достъпен, включително за интерфейси към mSQL от Perl, Tcl, REXX, Java и Python, www интерфейси и много други.
В заключение ще отбележа, че всички основни производители на бази данни поддържат стандарта SQL/CLI и спецификацията ODBC и освен това осигуряват ODBC и OLE DB доставчици — директно или индиректно, чрез продукти на други производители. Много от тях предлагат и собствени OLE DB доставчици, които са толкова богати на възможности, колкото Microsoft OLE DB доставчика за SQL Server 7.0
За да продължим разясненията за осъществяването на интерфейса между Web приложенията и базите данни е необходимо да обясним работата на другата част, изпълняваща важна роля в разработването им – Web сървърът. Както вече споменахме, освен че осигуряват взаимодействието между браузърите – подаващи заявката и изпълняващи я, той предоставя и шлюзове за тези браузъри, чрез които да се осъществи достъп до Web приложения като програми за търсене в бази данни. Но какво точно включва и представлява Web сървърът?