MS SQL - Oracle True, или изглед на програмист за две СУБД

Програмистите често се делят на два клана. Някои хора обичат C, други обичат Delphi и този аргумент като правило е безсмислен. Обикновено, който е свикнал с нещо, повече обича и хвали. Сред системите за управление на бази данни, двама конкуренти MS SQL и Oracle също се открояват ясно. И двете системи вършат отлична работа за съхранение и достъп до данни и по принцип един доста опитен програмист няма да има проблем да приеме някоя от тях, но. Но редица функции все още ни позволяват да направим предположението, че MS SQL е по-близо до хората, по-малко взискателен към опита от работата със системата, всичко лежи на повърхността.

За да не бъдем голословни, нека да разгледаме няколко примера. Едва ли ще намерите разлики в извадката. Единствената разлика ще бъде в допълнителните функции, специфични за системите:

Същото в MS SQL:

Като цяло в Orakle е възможно да не се използва декодиране на конкретна функция и да се използва същия CASE. И дори залепването на таблици не е необходимо да се прави (+), можете да използвате LEFTRIGHT OUTERINNER JOIN Вярно, последната функция се появи само в Oracle 9. Можем да предположим, че няма разлики в селекцията, но има една функция. Опитайте се да изберете стойност в променлива:

В Oracle такава конструкция е придружена от манипулатор на грешки, тъй като ако заявката не върне никакви записи, ще бъде хвърлено изключение и вашият код няма да бъде изпълнен. MS SQL ще го улесни, като възнагради променливата @nSum с NULL стойност. Според мен това е по-логично, отколкото всеки път да правите такива проверки, трупайки кода. Можете също да обиколите:

И въпреки това кодът на MS SQL ми изглежда по-сбит. Въпреки че, ако все още си спомняте, че можете да посочите списък с променливи в конструкцията INTO, тогава моите придирки могат да бъдат намаленидо не. Е, наистина всичко са малки неща. Въпрос на вкус.

А сега за сериозното. Знаете ли какво представляват временните маси и защо са необходими?

Временната таблица в MS SQL е фиктивна таблица (която не съществува физически), в която можете да разтоварите набор от данни, получен от SQL заявка, и да я използвате за следваща SQL заявка. Изобщо не е необходимо да описвате тази таблица, просто й дайте име, което започва със символ #, ако искате тази таблица да съществува по време на процедурата, или с ##, ако искате други процедури да имат достъп до нея. Такава маса ще бъде унищожена автоматично след приключване на сесията. Следователно трябва да напишете:

И имате таблица #my_table, която съдържа набора от записи, който сте избрали. Избрахте, поехте дъх и сега можете да го използвате за по-нататъшен избор:

Обърнете внимание, че MS SQL извърши селекция във временна таблица и той я знае и помни данните в нея. Какво ще ни предложи Oracle за това? Възможно е да поставите първата селекция на три места от втората селекция, като изхвърлите временната таблица. Получаваме тромава и нерационална селекция, която при изпълнение ще получи едни и същи данни три пъти. Можете да използвате курсора. И вместо проста селекция, напишете цяла програма, запомняйки дали, за, въвеждане на променливи и т.н.:

Но това не е всичко. Забелязахте ли къде са вмъкнати данните в предишния пример? Към някаква маса my_table. И какво представлява тя? Нищо освен физическа маса. Не го е взела сама. Все пак първо трябва да се създаде. Опишете колони, типове и т.н. Тук обаче си струва да споменем, че Oracle има и "временни" таблици, GLOBAL TEMPORARY TABLE. Но само по отношение на удобството на тяхното използване те не се различават от физическите таблици. Тя също трябва да бъде създадена. Икомандата CREATE TABLE не може да се изпълни директно в процедура. Вярно е, че е възможно да се използва динамичен SQL, но отново. Постоянно се натъкваме на рейк и се опитваме да ги заобиколим. Но не без драскотини. По-специално, след изпълнение на:

ще се появи имплицитно ангажиране и няма да можете да върнете промените назад. И все пак в този случай временните таблици на Oracle са по-скоро инструмент за администратор, отколкото за програмист и нямат абсолютно нищо общо с MS SQL временните таблици, освен името.

Имайте предвид, че ако искаме да получим набор от данни в резултат на процедурата, тогава трябва да подготвим таблица за него. И какво ни предлага MS SQL за това? И елементарно той предлага да напишете получената селекция в процедурата без ключовата дума into, тоест да не вмъквате този набор някъде в таблицата. Тогава резултатът от изпълнението на процедурата ще върне набор от тези данни. как? Да, така. Извикваш процедура

И получавате набор от данни от сървъра, сякаш сте извършили избор:

Не е ли страхотно? Ако не можете да изберете данни с едно избиране, просто напишете процедура, в която подреждате селекции от данни последователно във временни таблици и ги свързвате в набора от данни, който ви е необходим на изхода. И това е всичко, процедурата ще ви върне необходимите данни.

Но тук, разбира се, не всичко е вярно - в Oracle това също е осъществимо, само че решението не лежи на повърхността, а се крие в дивата природа на Oracle. Има такова понятие "курсорна променлива". Тоест можете да отворите курсор в процедурата и да върнете този набор от данни чрез изходния параметър:

Но когато вече сте разбрали как работи всичко и с пристрастие сте започнали да пишете процедурата, отново срещате проблем. Как да опишем изходния параметър като курсорна променлива, ако в началото е необходимо да опишете типа на курсорапроменлива?

Как да го опишем над заглавието на процедурата? Решението се крие във факта, че този тип може да бъде описан в спецификацията на пакета и след това да бъде препратен чрез деклариране на параметрите на процедурата

Е, като цяло успяха да постигнат целта, но колко време загубиха, докато обмислиха целия механизъм, или възприеха опита на по-старите си другари?

Може би затова рядко съм виждал подобен метод да се използва на практика. И в MS SQL това се предполага, дори не мога да си представя как да не го използвам. Но можете да направите още по-смело предположение защо този метод не е популярен в Oracle. Очевидно не всеки иска да се занимава с променливи на курсора и видимостта се губи. Когато отстранявате грешки в процедура, която подготвя набор от данни, обикновено няма да отваряте клиента всеки път и да виждате какво е върнато. По-ясно е да се види какво е вмъкнала процедурата в таблицата. Може би затова има по-малко проблеми при създаването му. В MS SQL, точно обратното, когато се въвеждат курсори в текста, не трябва да се преодоляват никакви психологически бариери. Просто пишем select и това е всичко. В допълнение, по време на отстраняване на грешки, можем бързо да видим какво сме подготвили в междинни временни таблици, като вмъкнем селекция от тази таблица навсякъде в процедурата.

Обобщавайки, можем да кажем, че MS SQL е по-проста и удобна СУБД и можете да я използвате, без да имате голям запас от знания. И не виждам нужда да използвате Oracle, ако не решавате някаква много специфична задача или например искате да инсталирате база данни на платформа, която не е Widows. Това е излишък и не винаги е полезно в крайна сметка. Остава само да пожелаем на онези малко програмисти, които имат късмета да бъдат в основата на нов проект, да бъдат разумни при избора на сървър. Работите с него иработа.

Можете да обсъдите статията тук.

Ще се радваме да Ви видим сред нашите клиенти!