Сравняване на SQL, конструктори на заявки и ORM

Въведение

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

Въпреки това, работата директно с бази данни от вашето приложение не винаги е лесна. Разликите в начина на представяне на структурите от данни често водят до предизвикателства. Трудността при изразяването на тънкостите относно взаимоотношенията между различни субекти също може да предизвика проблеми. За да се справим с това, са създадени много различни инструменти, които помагат да действат като интерфейс между основното приложение и слоя данни.

В това ръководство ще разгледаме някои от разликите, които възникват между три често срещани подхода:необработен SQL, конструктори на заявки и ORM (обектно-релационни карти). Ще сравним някои от предимствата и недостатъците на всеки подход и след това ще завършим с речник на често използвани термини, за да ви помогнем да се запознаете с някои ключови концепции.

Като опростено обобщение, ето общ поглед върху силните и слабите страни на всеки подход:

Управление на данни с необработен SQL или друг роден език за заявки за база данни

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

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

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

Предимства на естествените заявки

Използването на SQL или друг роден език на база данни има някои ясни предимства.

Едно предимство е, че разработчиците пишат и управляват заявките към базата данни и обработват резултатите изрично. Въпреки че това може да бъде много допълнителна работа, това означава, че има няколко изненади по отношение на това какво съхранява базата данни, как тя представя вашите данни и как ще предостави тези данни, когато бъдат извлечени по-късно. Липсата на абстракция означава, че има по-малко „движещи се части“, които могат да доведат до несигурност.

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

Друга причина да използвате заявки, базирани на база данни, е гъвкавостта. Вероятно никоя абстракция няма да може да бъде толкова гъвкава, колкото естествения език за заявки за база данни. По-високите нива на абстракция се опитват да преодолеят пропастта между две различни парадигми, което може да ограничи видовете операции, които могат да изразят. Когато пишете в необработен SQL, обаче, можете да се възползвате от всички функции на вашата база данни и да изразявате по-сложни заявки.

Недостатъци на естествените заявки

Въпреки че местните заявки имат някои силни страни, то не е без проблеми.

Когато взаимодействате с база данни от приложение, използващо обикновен SQL, трябва да разберете основната структура на данните, за да съставите валидни заявки. Вие носите пълна отговорност за превода между типовете данни и структурите, които използва вашето приложение, и конструкциите, налични в системата на базата данни.

Друго нещо, което трябва да имате предвид, когато работите с необработен SQL, е, че изцяло от вас зависи да управлявате безопасността на вашия вход. Това е особено вярно, ако съхранявате данни, предоставени от външни потребители, където специално изработеният вход може да накара базата ви да разкрие информация, която не сте възнамерявали да разрешите.

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

Работата с родни езици за заявки почти винаги означава съставяне на заявки с редовни низове. Това може да бъде болезнен процес в случаите, когато трябва да избягвате въвеждането и да свързвате низове заедно, за да създадете валидна заявка. Операциите на вашата база данни могат да бъдат обвити в много слоеве манипулиране на низове, което има голям потенциал за случайно повреждане на данните.

Обобщение на собствените заявки

Въпреки че говорихме предимно за SQL в този раздел, повечето от информацията тук се прилага еднакво добре за всеки роден език за заявки за база данни. За да обобщим, необработеният SQL или директното използване на който и да е еквивалентен език за заявки ви доближава най-близо до абстракциите, използвани от базата данни за съхраняване и управление на данните, но ви принуждава да вършите цялата тежка работа по ръчното управление на вашите данни.

Управление на данни със създатели на заявки

Алтернативен подход за използване на езици за заявки, базирани на база данни, като SQL, е да използвате инструмент или библиотека, наречени конструктор на заявки, за да разговаряте с вашата база данни.

Какво представляват съставителите на SQL заявки?

Създателят на SQL заявки добавя слой от абстракция над необработените езици за заявки, базирани на база данни. Те правят това чрез формализиране на модели на заявки и предоставяне на методи или функции, които добавят хигиенизиране на входа и автоматично избягват елементи за по-лесно интегриране в приложения.

Структурите и действията, поддържани от слоя на базата данни, все още са доста разпознаваеми, когато се използват създатели на SQL заявки. Това ви позволява да работите с данни програмно, като същевременно оставате относително близо до данните.

Обикновено конструкторите на заявки предоставят интерфейс, който използва методи или функции за добавяне на условие към заявка. Чрез свързване на методите заедно, разработчиците могат да съставят пълни заявки за база данни от тези отделни „клаузи“.

Предимства на създателите на SQL заявки

Тъй като създателите на заявки използват същите конструкции (методи или функции) като останалата част от вашето приложение, разработчиците често ги намират за по-лесни за управление в дългосрочен план, отколкото необработените заявки за база данни, написани като низове. Лесно е да се направи разликата между оператори и данни и е лесно да се декомпозират заявки на логически парчета, които обработват конкретни части от заявка.

За някои разработчици друго предимство на използването на SQL конструктор на заявки е, че той не винаги скрива основния език за заявки. Въпреки че операциите могат да използват методи вместо низове, те могат да бъдат доста прозрачни, което улеснява запознатите с базата данни да разберат какво ще направи дадена операция. Това не винаги е така, когато използвате по-високи нива на абстракция.

Създателите на SQL заявки често също поддържат множество сървъри на данни, като например абстрахират някои от фините разлики в различни релационни бази данни. Това ви позволява да използвате едни и същи инструменти за проекти, които използват различни бази данни. Може дори да направи мигрирането към нова база данни малко по-лесно.

Недостатъци на създателите на SQL заявки

Създателите на SQL заявки страдат от някои от същите недостатъци като родните езици за заявки.

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

Освен това конструкторите на SQL заявки все още изискват от вас да дефинирате как данните, които извличате, се отнасят към данните от приложението ви. Няма автоматична синхронизация между вашите обекти в паметта и тези в базата данни.

Докато конструкторите на заявки често емулират езика за заявки, с който са предназначени да работят, допълнителният слой на абстракция може да означава, че понякога определени операции не са възможни с помощта на предоставените методи. Обикновено има "суров" режим за изпращане на заявки директно към бекенда, заобикаляйки типичния интерфейс на конструктора на заявки, но това заобикаля проблема, вместо да го решава.

Резюме на създателите на SQL заявки

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

Управление на данни с ORMs

Стъпка по-нагоре в йерархията на абстракцията са ORM. ORM обикновено се стремят към по-пълна абстракция с надеждата да се интегрират с данните от приложението по-плавно.

Какво представляват ORM?

Обектно-релационните карти, или ORM, са части от софтуер, предназначени за преобразуване между представянето на данни в релационни бази данни и представянето в паметта, използвано с обектно-ориентирано програмиране (OOP). ORM предоставя обектно-ориентиран интерфейс към данните в базата данни, като се опитва да използва познати концепции за програмиране и да намали количеството стандартен код, необходим за ускоряване на разработката.

Като цяло ORM служат като абстракционен слой, предназначен да помогне на разработчиците да работят с бази данни, без драстично да променят обектно-ориентираната парадигма. Това може да бъде полезно чрез намаляване на умственото натоварване от адаптиране към спецификата на формата за съхранение на база данни.

По-специално, обектите в обектно-ориентираното програмиране са склонни да кодират много състояния в тях и могат да имат сложни връзки с други обекти чрез наследяване и други ООП концепции. Съпоставянето на тази информация надеждно в ориентирана към таблицата релационна парадигма често не е лесно и може да изисква добро разбиране на двете системи. ORM се опитват да облекчат това бреме, като автоматизират част от това картографиране и като предоставят изразителни интерфейси към данните в системата.

Предизвикателствата на ORM специфични за обектно-ориентираното програмиране ли са и релационни бази данни?

По дефиниция, ORM са специално проектирани за взаимодействие между обектно-ориентирани езици на приложения и релационни бази данни. Въпреки това, опитът за картографиране и превод между абстракциите на структурата на данни, използвани в езиците за програмиране, и тези, използвани от хранилищата на бази данни, е по-общ проблем, който може да съществува винаги, когато абстракциите не се подравняват ясно.

В зависимост от парадигмата на програмиране (обектно ориентирана, функционална, процедурна и т.н.) и типа на базата данни (релационна, документна, ключ-стойност и т.н.), различни количества абстракция могат да бъдат полезни. Често пъти сложността на структурите от данни в приложението диктува колко лесно е да се взаимодейства с хранилището на данни.

Обектно-ориентираното програмиране има тенденция да произвежда много структури със значимо състояние и връзки, които трябва да бъдат отчетени. Някои други парадигми за програмиране са по-ясни за това къде се съхранява състоянието и как се управлява. Например, чисто функционалните езици не позволяват променливо състояние, така че състоянието често е вход за функции или обекти, които извеждат ново състояние. Това чисто разделяне на данни от действия, както и яснотата на жизнените цикли на състоянието могат да помогнат за опростяване на взаимодействието с базата данни.

Така или иначе, често е налична опцията за взаимодействие с база данни чрез софтуер, който картографира между две различни представяния. Така че, докато ORMs описват специфично подмножество от тях с уникални предизвикателства, картографирането между паметта на приложението и постоянното съхранение често изисква обмисляне, независимо от подробностите.

ORMs на активен запис срещу картографиране на данни

Различните ORM използват различни стратегии за картографиране между структурите на приложението и базата данни. Двете основни категории са моделът на активен запис и образецът за картографиране на данни .

Активният модел на запис се опитва да капсулира данните на базата данни в структурата на обектите във вашия код. Обектите съдържат методи за запазване, актуализиране или изтриване от базата данни и промените във вашите обекти са предназначени да бъдат лесно отразени в базата данни. Като цяло, активен обект на запис във вашето приложение представлява запис в база данни.

Активните реализации на записи ви позволяват да управлявате вашата база данни чрез създаване и свързване на класове и екземпляри във вашия код. Тъй като тези обикновено картографират екземпляри на клас директно в записи на база данни, лесно е да се концептуализира какво има във вашата база данни, ако разбирате какви обекти се използват във вашия код.

За съжаление, това може да дойде и с някои големи недостатъци. Приложенията обикновено са много тясно свързани с базата данни, което може да причини проблеми при опит за мигриране към нова база данни или дори при тестване на вашия код. Вашият код има тенденция да разчита на базата данни за запълване на празнини, които са били разтоварени от вашите обекти. „Вълшебният“ превод между тези два домейна може също да доведе до проблеми с производителността, тъй като системата се опитва да картографира безпроблемно сложни обекти към основната структура от данни.

Моделът за картографиране на данни е другият често срещан модел на ORM. Подобно на модела на активен запис, картографът на данни се опитва да действа като независим слой между вашия код и вашата база данни, който посредничи между двете. Въпреки това, вместо да се опитва безпроблемно да интегрира обекти и записи в базата данни, той се фокусира върху опитите за разделяне и превод между тях, като същевременно оставя всеки да съществува независимо. Това може да ви помогне да отделите вашата бизнес логика от подробности, свързани с база данни, които се занимават с съпоставяне, представяне, сериализация и т.н.

Така че вместо да позволи на ORM системата да разбере как да картографира между обектите и таблиците на базата данни, разработчикът е отговорен за изричното картографиране между двете. Това може да помогне за избягване на тясно свързване и задкулисни операции за сметка на значително повече работа при намирането на подходящи съпоставяния.

Предимства на ORM

ORM са популярни по много причини.

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

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

Недостатъци на ORMs

ORM не са лишени от своите недостатъци. В много случаи те произтичат от същите решения, които правят ORM полезни.

Един от основните проблеми с ORM е опитът за скриване на детайлите на бекенда на базата данни. Това обфускация прави работата с ORM по-лесна в прости случаи или в малки времеви мащаби, но често води до проблеми в бъдеще с нарастването на сложността.

Абстракцията никога не е 100% завършена и опитът за използване на ORM без разбиране на основния език за заявки или структура на базата данни често води до проблематични предположения. Това може да направи отстраняването на грешки и настройката на производителността трудно или невъзможно.

Може би най-известният проблем при работата с ORM е несъответствието на импеданса на обектно-релационния импеданс, термин, използван за описване на трудността при превода между обектно-ориентирано програмиране и релационната парадигма, използвана от релационни бази данни. Несъвместимостта между моделите на данни, използвани от тези две категории технологии, означава, че е необходима допълнителна, несъвършена абстракция с всяко увеличаване на сложността. Несъответствието на импеданса на обектно-релационния импеданс е наречено Виетнам на компютърните науки (по отношение на войната във Виетнам) поради тенденцията му да увеличава сложността с времето и да води до ситуации, при които пътищата към успех или промяна на курса са трудни или невъзможни.

Като цяло ORM са по-бавни от алтернативите, особено при сложни заявки. ORM често генерират сложни заявки за сравнително прости операции с база данни, тъй като използват общи модели, които трябва да бъдат достатъчно гъвкави, за да се справят с други случаи. Разчитането на ORM да направи правилното нещо при всякакви обстоятелства може да доведе до скъпо струващи грешки, които може да бъдат трудни за наваксване.

Резюме на ORMs

ORM могат да бъдат полезни абстракции, които правят работата с бази данни много по-лесна. Те могат да ви помогнат да проектирате и повторите бързо и да преодолеете концептуалните различия между логиката на приложението и структурите на базата данни. Въпреки това, много от тези предимства действат като нож с две остриета. Те могат да ви попречат да разберете вашите бази данни и да направят предизвикателство за отстраняване на грешки, промяна на парадигмите или повишаване на производителността.

Речник

Когато работите с технологии, които взаимодействат между бази данни и приложения, може да срещнете терминология, с която не сте запознати. В този раздел ще разгледаме накратко някои от най-често срещаните термини, които може да срещнете, някои от които бяха разгледани по-рано в тази статия, а други не.

• Картографиране на данни: Картографът на данни е модел на проектиране или част от софтуер, който картографира структурите на програмиране от данни към тези, съхранявани в база данни. Картографите на данни се опитват да синхронизират промените между двата източника, като същевременно ги поддържат независими един от друг. Самият картограф е отговорен за поддържането на работещ превод, като освобождава разработчиците да повтарят структурите от данни на приложението, без да се грижат за представянето на базата данни.
• Драйвер за база данни: Драйверът за база данни е част от софтуер, предназначен да капсулира и позволява връзки между приложение и база данни. Драйверите за бази данни абстрахират детайлите от ниско ниво за това как да се правят и управляват връзки и осигуряват унифициран програмен интерфейс към системата на базата данни. Обикновено драйверите за бази данни са най-ниското ниво на абстракция, което разработчиците използват за взаимодействие с бази данни, като инструментите на по-високо ниво се основават на възможностите, предоставени от драйвера.
• Атака чрез инжектиране: Атаката с инжектиране е атака, при която злонамерен потребител се опитва да изпълни нежелани операции с база данни, използвайки специално изработен вход в полета на приложението, насочени към потребителя. Често това се използва за извличане на данни, които не трябва да са достъпни, или за изтриване или манипулиране на информация в базата данни.
• ОРМ: ORM или обектно-релационни картографи са слоеве на абстракция, които превеждат между представянията на данни, използвани в релационни бази данни, и представянето в паметта, използвано при обектно-ориентирано програмиране. ORM предоставя обектно-ориентиран интерфейс към данните в базата данни, като се опитва да намали количеството код и да използва познати архетипи за ускоряване на разработката.
• Несъответствие на импеданса на обектната връзка: Несъответствието на обектно-релационния импеданс се отнася до трудността на превода между обектно-ориентирано приложение и релационна база данни. Тъй като структурите от данни се различават значително, може да бъде трудно вярно и ефективно да се мутират и транскрибират програмните структури от данни във формата, използван от бекенда за съхранение.
• Рамка за постоянство: Рамката за постоянство е слой за абстракция на междинен софтуер, разработен за преодоляване на пропастта между програмните данни и базите данни. Рамките за постоянство могат също да бъдат ORM, ако абстракцията, която използват, картографира обекти към релационни обекти.
• Конструктор на заявки: Създателят на заявки е абстракционен слой, който помага на разработчиците да осъществяват достъп до бази данни и да ги контролират, като предоставя контролиран интерфейс, който добавя функции за използваемост, безопасност или гъвкавост. Обикновено конструкторите на заявки са сравнително леки, фокусират се върху улесняването на достъпа до данни и представянето на данни и не се опитват да преведат данните в конкретна парадигма за програмиране.
• SQL: SQL или езикът за структурирани заявки е специфичен за домейна език, разработен за управление на системи за управление на релационни бази данни. Може да се използва за запитване, дефиниране и манипулиране на данни в база данни, както и техните организационни структури. SQL е повсеместен сред релационните бази данни.

Заключение

В тази статия разгледахме няколко различни опции за взаимодействие с вашата база данни от вашето приложение. Разгледахме различните нива на абстракция и гъвкавостта, предлагана чрез използване на езици за заявки, базирани на база данни, като SQL, използване на конструктор на заявки за безопасно създаване на заявки и ORM за осигуряване на по-пълно ниво на абстракция.

Всеки от тези подходи има своите приложения и някои може да са подходящи за определени видове приложения, отколкото други. Важно е да разберете изискванията на вашето приложение, познанията за базата данни на вашата организация и разходите за абстракциите (или липсата на такива), които решите да приложите. Като цяло разбирането на всеки подход ще ви даде най-добрия шанс да изберете опцията, която ще бъде подходяща за вашите проекти.