Направете екскурзия в Access чрез SQL Server

Непрекъснатост на бизнес процесите

Относно вашето решение за Access, искате да го пуснете и да работи с минимални прекъсвания, но вашите опции за сървърната база данни на Access са ограничени. Архивирането на вашата база данни на Access е от съществено значение за защитата на данните ви, но това изисква вашите потребители да бъдат офлайн. Освен това има непланирани престои, причинени от надстройки при поддръжката на хардуера/софтуера, отпадане на електрозахранването или на мрежата, хардуерни повреди, пробиви в сигурността или дори кибератаки. За да намалите престоите и отражението им върху вашата дейност, можете да архивирате база данни на SQL Server, докато тя се използва. Освен това, SQL Server предлага и стратегии за висока степен на достъпност (HA) и за възстановяване след аварии (DR). Комбинацията от тези две технологии се нарича HADR. За повече информация вж. Непрекъснатост на бизнес процесите и възстановяване на бази данни и Постигане на непрекъснатост на бизнес процесите с помощта на SQL Server (електронна книга).

Архивиране по време на работа

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

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

HADR

Двете най-често срещани техники за постигане на висока степен на достъпност и непрекъснатост на бизнес процесите са създаване на огледален образ и групиране в клъстери. SQL Server обединява технологията на създаване на огледален образ и групиране в клъстери с "Винаги включени екземпляри на отказоустойчивия клъстер" и "Винаги включени групи за достъпност".

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

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

За повече информация вж. Винаги включени екземпляри на отказоустойчивия клъстeр и Винаги включени групи за достъпност: едно решение за висока степен на достъпност и за възстановяване след авария.

Най-горе на страницата

Защита на SQL Server

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

Удостоверяване на база данни

Има четири метода за удостоверяване на база данни в SQL Server, всеки от които можете да зададете в низ за връзка с ODBC. За повече информация вж. Връзка към или импортиране на данни от база данни на Azure SQL Server. Всеки метод има собствени предимства.

С вградено удостоверяване за Windows    Използване на идентификационни данни за Windows за валидиране на потребители, роли на защита и ограничаване на функции и данни за потребителя. Можете да се възползвате от идентификационните данни за домейна и лесно да управлявате потребителските права във вашето приложение. Ако желаете, въведете основно име за услугата (SPN). За повече информация вж. Избор на режим на удостоверяване.

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

С интегрирано удостоверяване за Azure Active Directory    Свързване към базата данни на Azure SQL Server с помощта на Azure Active Directory. След като сте конфигурирали удостоверяване на Azure Active Directory, не се изискват допълнителни данни за влизане и парола. За повече информация вижте Свързване към SQL база данни с помощта на удостоверяване на Azure Active Directory.

С удостоверяване чрез парола за Active Directory    Свързване с идентификационни данни, които са били зададени в Azure Active Directory чрез въвеждане на ИД за влизане и парола. За повече информация вижте Свързване към SQL база данни с помощта на удостоверяване на Azure Active Directory.

Съвет    Използвайте функцията за откриване на заплахи, за да получавате предупреждения за неправилна дейност в база данни, показваща потенциални заплахи за защитата към база данни на Azure SQL Server. За повече информация вж. Откриване на заплахи за SQL база данни

Защита на приложения

SQL Server разполага с две функции за защита на ниво приложение, от които можете да се възползвате от Access.

Динамично маскиране на данни    Прикрийте чувствителната информация, като я маскирате от непривилегировани потребители. Можете например да прикриете номера на социалната осигуровка – частично или напълно.

Частично маскиране на данни

Пълно маскиране на данни

Има няколко начина, по които можете да дефинирате маска за данни, и можете да ги приложите към различни типове данни. Маскирането на данни е базирано на правила на ниво таблица и колона за зададен набор от потребители и се прилага към заявката в реално време. За повече информация вж. Динамично маскиране на данни.

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

Има два типа предикати за защита:

• Филтърният предикат филтрира редовете от заявка. Филтърът е прозрачен, а крайният потребител не знае, че се прилага филтриране.

• Блокиращият предикат забранява неупълномощени действия и предизвиква изключение, ако действието не може да бъде изпълнено.

За повече информация вж. Защита на ниво ред.

Защита на данните чрез шифроване

Защитава данните в покой, при пренос и докато се използват, без това да се отразява на работата на базата данни. За повече информация вж. Шифроване на SQL Server.

Шифроване в покой    За да защитите личните си данни от офлайн мултимедийни атаки в слоя за физическо място за съхранение, използвайте шифроване в покой, наречено още прозрачно шифроване на данни (TDE – Transparent Data Encryption). Това означава, че вашите данни остават защитени дори ако физическите носители бъдат откраднати или неправилно извадени от употреба. TDE извършва шифроване и дешифриране на бази данни в реално време, архивиране и записване на регистрационни файлове на транзакции, без да се изискват промени във вашите приложения.

Шифроване при пренос    За защита срещу подслушване и атаки от тип "човек помежду" можете да шифровате данните, които се пренасят през мрежата. SQL Server поддържа протокола за защита на транспортния слой TLS 1.2 (Transport Layer Security) за силно защитени комуникации. За защита на комуникациите по ненадеждни мрежи се използва и протоколът за пренос на таблични данни (TDS).

Шифроване, използвано в клиента    За защита на личните данни по време на тяхното използване функцията, която ви е нужна е "Винаги шифровани". Личните данни се шифроват и дешифрират от драйвер на клиентския компютър, без да се разкриват ключовете за шифроване на системата за управление на базата данни. В резултат на това шифрованите данни са видими само за хората, които отговарят за управлението на тези данни, а не за другите силно привилегировани потребители, които не трябва да имат достъп. В зависимост от типа на избраното шифроване, Always Encrypted може да ограничи някои възможности на базата данни – например търсене, групиране и индексиране на шифровани колони.

Най-горе на страницата

Решаване на проблемите с поверителността

Загрижеността за поверителността е толкова често срещана, че Европейският съюз е определил законови изисквания чрез Общия регламент относно защитата на данните (ОРЗД). За щастие, SQL Server е много подходящ като отговор на тези изисквания. Мислете за прилагането на ОРЗД в рамка от три стъпки.

Стъпка 1: Оценка и управление на риска за несъответствие с нормативните разпоредби

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

Един нов инструмент, SQL откриване и класифициране на данни, вграден в SQL Server Management Studio ви помага да откривате, класифицирате, етикетирате и съобщавате за чувствителни данни, като приложите към колоните два атрибута метаданни:

• Етикети    За да дефинирате чувствителната информация.

• Типове информация    За да предоставите допълнителна детайлизация за типовете данни, съхранени в дадена колона.

Друг механизъм за разкриване, който можете да използвате, е "търсене в целия текст", който включва използването на предикатите CONTAINS и FREETEXT и функции върху набори редове – например CONTAINSTABLE и FREETEXTTABLE при работа с командата SELECT. С помощта на търсене в целия текст може да търсите в таблици, за да откривате думи, комбинации от думи или вариации на дума – например синоними или флективни формуляри. За повече информация вж. Търсене в пълен текст.

Стъпка 2: Защита на личните данни

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

• Удостоверяване на SQL Server за управление на самоличността на потребителите и за предотвратяване на неупълномощен достъп.

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

• Динамично маскиране на данни, за да ограничите излагането на показ на лични данни, като ги маскирате за непривилегировани потребители.

• Шифроване, за да се гарантира, че личните данни са защитени по време на пренос и съхранение и са защитени срещу компрометиране, включително от страната на сървъра.

За повече информация вж. Защита на SQL Server.

Стъпка 3: Отговаряйте ефективно на заявките

ОРЗД изисква от вас да поддържате записи за обработката на лични данни и да направите тези записи достъпни за надзорните органи при поискване. Ако възникнат проблеми, включително случайно оповестяване на данни, контролите за защита ви позволяват бързо да реагирате. Данните трябва да бъдат бързо достъпни, когато се налага да съобщите за тях. Например ОРЗД изисква за пробив в личните данни да бъде съобщено на надзорния орган "не по-късно от 72 часа, след като стане известно за такъв".

SQL Server 2017 ви помага при задачите за съобщаване по няколко начина:

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

• Времевите таблици за SQL Server представляват потребителски таблици с поддържани от системата версии, предназначени да пазят пълната хронология на промените в данните. Можете да ги използвате за лесно отчитане и анализ на моментите от времевата скала.

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

За повече информация вж. Създаване на платформа на доверие (електронна книга) и Запознаване със съответствието според ОРЗД.

Най-горе на страницата

Създаване на снимки на база данни

Една снимка на база данни е "само за четене" – статичен поглед върху базата данни на SQL Server в даден момент от времето. Въпреки че можете да копирате файл на база данни на Access, за да създадете по същество снимка на базата данни, Access няма вградена методология за това като SQL Server. Можете да използвате снимка на базата данни при писане на отчети въз основа на данните по време на създаването на тази снимка на базата данни. Можете да използвате снимка на база данни и за да поддържате хронологични данни – например по една за всяко финансово тримесечие, която да използвате при съставянето на отчети в края на съответния период. Препоръчваме следните най-добри практики:

• Дайте име на снимката    Всяка снимка на базата данни изисква уникално име на базата данни (в съответния момент). За по-лесна идентификация добавете към името целта и времевата рамка. Например за да направите снимки на базата данни AdventureWorks три пъти дневно на 6-часови интервали между 06:00 и 18:00 ч. като използвате 24-часов часовник, им дайте имена AdventureWorks_snapshot_0600, AdventureWorks_snapshot_1200 и AdventureWorks_snapshot_1800.

• Ограничете броя на снимките    Всяка снимка на базата данни се пази, докато изрично не се откажете от нея. Тъй като всяка снимка ще продължи да расте, може да се наложи, за да спестите място на диска, да изтриете по-стара снимка, след като създадете нова снимка. Ако например правите ежедневни отчети, пазете снимката на базата данни за 24 часа, а след това се откажете от нея и я заменете с нова.

• Свържете се с правилната снимка    За да използва снимка на база данни, клиентът на Access трябва да знае точното й местоположение. Когато заместите съществуваща снимка с нова, трябва да пренасочите Access към новата снимка. Трябва да добавите процедура към клиента на Access, за да сте сигурни, че ще се свържете към правилната снимка на базата данни.

Ето как можете да създадете снимка на базата данни:

CREATE DATABASE AdventureWorks_dbss1800 ON  
( NAME = AdventureWorks_Data, FILENAME =   
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\AdventureWorks_snapshot_0600' )  
AS SNAPSHOT OF AdventureWorks;  

За повече информация вж. Снимки на бази данни (SQL Server).

Най-горе на страницата

Контрола за взаимна съвместимост

Когато много хора се опитват да променят данните в една база данни по едно и също време, е необходима система от контроли, така че промените, направени от едно лице, да не навредят на тези, направени от друг човек. Това се нарича управление на паралелно протичащи процеси, като съществуват две основни стратегии за заключване – песимистична и оптимистична. Заключването може да попречи на потребителите да променят данните по начин, който засяга други потребители. Заключването помага и за това, да се гарантира целостта на базите данни, особено при заявки, които иначе биха довели до неочаквани резултати. Има важни разлики в начините, по които Access и SQL Server реализират тези стратегии за управление на паралелно протичащи процеси.

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

Може да използвате и свойството RecordLocks, за да промените стратегията за управление на паралелно протичащи процеси. Това свойство засяга формуляри, отчети и заявки и има три настройки:

• Без заключване    В даден формуляр потребителите могат да се опитат да редактират един и същи запис едновременно, но може да се появи диалоговият прозорец Конфликт при запис. В един отчет записите не се заключват, докато отчетът се преглежда или отпечатва. В дадена заявка записите не се заключват, докато заявката се изпълнява. Това е начинът, по който Access осъществява оптимистично заключване.

• Всички записи    Всички записи в базовата таблица или заявката се заключват, докато формулярът е отворен в изглед "Формуляр" или изглед "Лист с данни", докато се отчетът се визуализира или се отпечатва, както и докато заявката се изпълнява. Потребителите могат да четат записите, когато те са заключени.

• Редактиран запис    При формуляри и заявки дадена страница със записи се заключва веднага щом някой потребител започне да редактира поле от записа, като остава заключена, докато потребителят не премине към друг запис. Следователно даден запис може да бъде редактиран само от един потребител в даден момент. Това е начинът, по който Access осъществява песимистично заключване.

За повече информация вж. Диалогов прозорец "Конфликт при запис" и Свойство RecordLocks.

В SQL Server управлението на паралелно протичащи процеси работи по следния начин:

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

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

Можете да укажете типа управление на паралелно протичащите процеси, като изберете няколко нива на изолиране на транзакция, които определят нивото на защита за транзакцията от промените, извършвани от други транзакции, с помощта на командата SET TRANSACTION:

 SET TRANSACTION ISOLATION LEVEL
 { READ UNCOMMITTED
    | READ COMMITTED
    | REPEATABLE READ  
    | SNAPSHOT
    | SERIALIZABLE
 }

За повече информация вж. Ръководство за заключване на транзакциите и за създаване на версии на редове.

Най-горе на страницата

Подобряване на ефективността на заявка

След като се изпълнява транзитна заявка на Access, възползвайте се от предимствата на сложните начини, по които SQL Server може да я накара да се изпълнява по-ефективно.

За разлика от базата данни на Access, SQL Server предоставя паралелни заявки за оптимизиране на изпълнението на заявки и операции с индекси за компютри, които имат повече от един микропроцесор (ЦП). Тъй като SQL Server може да изпълнява заявка или операция с индекс паралелно, използвайки няколко системни работни нишки, операцията може да бъде изпълнена бързо и ефективно.

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

За повече информация вж. По-бързи заявки с SQL Server (електронна книга).

Оптимизиране на заявките

Няколко инструмента работят заедно, за да ви помогнат да анализирате ефективността на заявката и да я усъвършенстват: Оптимизатор на заявките, планове за изпълнение и магазин за заявки.

Оптимизатор на заявките

Оптимизаторът на заявките е един от най-важните компоненти на SQL Server. Използвайте оптимизатора на заявките, за да анализирате заявката и да определите най-ефективния начин за достъп до исканите данни. Входната информация за оптимизатора на заявките се състои от заявката, схемата на базата данни (дефиниции на таблици и индекси) и статистическите данни за базата данни. Резултатът от работата на оптимизатора на заявките е план за изпълнение.

За повече информация вж. Оптимизатор на заявките за SQL Server.

План за изпълнение

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

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

След това трябва да се състави нов план за следващата връзка, която изпълнява заявката. Условията, които обезсилват един план, са:

• Промените, направени в таблица или изглед, споменати в заявката (ALTER TABLE и ALTER VIEW).

• Промени в индекси, използвани от плана за изпълнение.

• Актуализации за статистическите данни, използвани от плана за изпълнение, генерирани или изрично от команда – например UPDATE STATISTICS – или автоматично.

За повече информация вж. Планове за изпълнение.

Магазин за заявки

Магазинът за заявки предоставя аналитични данни за избора на план за изпълнение и за неговата ефективност. Това опростява отстраняването на проблеми с ефективността, като ви помага бързо да намирате разликите в ефективността, предизвикани от промени в плана за изпълнение. Магазинът за заявки събира данни от телеметрията, като например хронология на заявките, планове, статистика за времето на работа и статистически данни за времената на изчакване. Използвайте командата ALTER DATABASE, за да реализирате магазина за заявки:

ALTER DATABASE AdventureWorks2012 SET QUERY_STORE = ON;

За повече информация вж. "Наблюдаване на производителността с помощта на Магазина за заявки".

ALTER DATABASE [YourDatabaseName] SET COMPATIBILITY_LEVEL = 140;

Начини за заявки

В SQL Server има няколко начина за заявка и всеки от тях има своите предимства. Трябва да знаете какви са те, така че да можете да направите правилния избор за вашето решение за Access. Най-добрият начин да създадете вашите заявки за TSQL е да ги редактирате интерактивно и да ги тествате с помощта на Transact-SQL редактора от SQL Server Management Studio (SSMS), който има IntelliSense, за да ви помогне да избирате правилните ключови думи и да правите проверка за синтактични грешки.

Изгледи

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

CREATE VIEW HumanResources.EmployeeHireDate AS  
SELECT p.FirstName, p.LastName, e.HireDate  
FROM HumanResources.Employee AS e JOIN Person.Person AS p  
ON e.BusinessEntityID = p.BusinessEntityID;

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

CREATE VIEW Sales.vOrders  
WITH SCHEMABINDING  
AS  
    SELECT SUM(UnitPrice*OrderQty*(1.00-UnitPriceDiscount)) AS Revenue,  
        OrderDate, ProductID, COUNT_BIG(*) AS COUNT  
    FROM Sales.SalesOrderDetail AS od, Sales.SalesOrderHeader AS o  
    WHERE od.SalesOrderID = o.SalesOrderID  
    GROUP BY OrderDate, ProductID;  

CREATE UNIQUE CLUSTERED INDEX IDX_V1   
    ON Sales.vOrders (OrderDate, ProductID);  

Има обаче ограничения. Не можете да актуализирате данните, ако е засегната повече от една базова таблица, или изгледът съдържа агрегатни функции или клауза DISTINCT. Ако SQL Server връща съобщение за грешка, гласящо, че не знае кой запис да бъде изтрит, може да се наложи да добавите превключвател за изтриване в изгледа. И накрая, не можете да използвате клаузата ORDER BY, както можете да направите със заявка на Access.

За повече информация вж. Изгледи и Създаване на индексирани изгледи.

Съхранени процедури

Съхранена процедура е група от един или повече TSQL оператори, които получават входни параметри, връщат изходни параметри и посочват успех или неуспех със стойност за състояние. Тя действа като междинен слой между клиента на Access и сървъра SQL Server. Съхранените процедури могат да бъдат прости – например единствен оператор SELECT, или сложни – например колкото коя да е програма. Ето един пример:

CREATE PROCEDURE HumanResources.uspGetEmployees   
    @LastName nvarchar(50),   
    @FirstName nvarchar(50)   
AS   
    SET NOCOUNT ON;  
    SELECT FirstName, LastName, Department  
    FROM HumanResources.vEmployeeDepartmentHistory  
    WHERE FirstName = @FirstName AND LastName = @LastName  
    AND EndDate IS NULL;  

Когато използвате съхранена процедура в Access, тя обикновено връща резултат, който се отразява във формуляр или отчет. Тя обаче може да изпълнява други действия, които не връщат резултати – например оператори на DDL или DML. Когато използвате транзитна заявка, се уверете, че сте задали свойството Връща записи по подходящ начин.

За повече информация вж. Съхранени процедури.

Общи таблични изрази

Общите таблични изрази (CTE – Common Table Expressions) са като временни таблици, които генерират наименувани набори от резултати. Те съществуват само за изпълнението на единична заявка или оператор на DML. Един CTE е вграден в същия ред от кода, в който се намира операторът SELECT или операторът на DML, които го използват, докато създаването и използването на временни таблици или изгледи обикновено е процедура от две стъпки. Ето един пример:

-- Define the CTE expression name and column list.  
WITH Sales_CTE (SalesPersonID, SalesOrderID, SalesYear)  
AS  
-- Define the CTE query.  
(  
    SELECT SalesPersonID, SalesOrderID, YEAR(OrderDate) AS SalesYear  
    FROM Sales.SalesOrderHeader  
    WHERE SalesPersonID IS NOT NULL  
)  
-- Define the outer query referencing the CTE name.  
SELECT SalesPersonID, COUNT(SalesOrderID) AS TotalSales, SalesYear  
FROM Sales_CTE  
GROUP BY SalesYear, SalesPersonID  
ORDER BY SalesPersonID, SalesYear;

CTE има няколко предимства, сред които следните:

• Тъй като CTE са преходни, не е необходимо да ги създавате като постоянни обекти в базата данни, както напр. изгледите.

• Можете да се обръщате към едни и същи CTE повече от веднъж в дадена заявка или в оператор на DML, което прави вашия код по-удобен за работа.

• Може да използвате заявки, които се обръщат към CTE, за да дефинирате курсор.

За повече информация вж. WITH общ_табличен_израз.

Функции, дефинирани от потребителя

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

CREATE FUNCTION dbo.ISOweek (@DATE datetime)  
RETURNS int WITH SCHEMABINDING -- Helps improve performance
WITH EXECUTE AS CALLER  
AS  
BEGIN  
     DECLARE @ISOweek int;  
     SET @ISOweek= DATEPART(wk,@DATE)+1  
          -DATEPART(wk,CAST(DATEPART(yy,@DATE) as CHAR(4))+'0104');  
-- Special cases: Jan 1-3 may belong to the previous year  
     IF (@ISOweek=0)   
          SET @ISOweek=dbo.ISOweek(CAST(DATEPART(yy,@DATE)-1   
               AS CHAR(4))+'12'+ CAST(24+DATEPART(DAY,@DATE) AS CHAR(2)))+1;  
-- Special case: Dec 29-31 may belong to the next year  
     IF ((DATEPART(mm,@DATE)=12) AND   
          ((DATEPART(dd,@DATE)-DATEPART(dw,@DATE))>= 28))  
          SET @ISOweek=1;  
     RETURN(@ISOweek);  
END;  
GO  
SET DATEFIRST 1;  
SELECT dbo.ISOweek(CONVERT(DATETIME,'12/26/2004',101)) AS 'ISO Week';  

UDF функцията има някои ограничения. Тя например не може да използва някои недетерминистични системни функции, да изпълнява оператори на DML или DDL или да изпълнява динамични SQL заявки.

За повече информация вж. Функции, дефинирани от потребителя.

Най-горе на страницата

Добавяне на ключове и индекси

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

Ключове

В SQL Server трябва да се постараете да създадете първични ключове за всяка таблица и външни ключове за всяка свързана таблица. Еквивалентна характеристика в SQL Server на типа данни "Автономериране" на Access е свойството IDENTITY, което може да се използва за създаване на стойности на ключове. Щом приложите това свойство към някоя числова колона, тя се превръща в такава само за четене и се поддържа от системата за управление на базата данни. Когато вмъквате запис в таблица, която съдържа колона IDENTITY, системата автоматично увеличава стойността за колоната IDENTITY с 1, като започне от 1, но можете да контролирате тези стойности чрез аргументи.

За повече информация вж. CREATE TABLE, IDENTITY (Свойство).

Индекси

Както винаги, изборът на индекси е действие за балансиране между скорост на заявката и цена на актуализирането. В Access имате един тип индекс, но в SQL Server имате дванадесет. За щастие, можете да използвате оптимизатора на заявки, за да ви помогне сигурно да изберете най-ефективния индекс. А в Azure SQL можете да използвате автоматично управление на индекса – функция за автоматична настройка, която ви препоръчва добавянето или премахването на индекси. За разлика от Access, в SQL Server трябва да създадете собствени индекси за външни ключове. Можете да създавате индекси и в индексиран изглед, за да подобрите ефективността на заявките. Недостатъкът на един индексиран изглед са увеличените допълнителни разходи, когато променяте данните в базовите таблици на изгледа, защото изгледът също трябва да бъде актуализиран. За повече информация вж. Ръководство за архитектура и проектиране на индекси в SQL Server и Индекси.

Най-горе на страницата

Изпълнение на транзакции

Изпълнението на процедура за онлайн транзакция (OLTP) е трудно в Access, но е сравнително лесно с SQL Server. Транзакцията е неделима единица работа, която извършва всички промени в данните, когато е успешна, но възстановява състоянието преди своето начало, когато не е успешна. Транзакцията трябва да има четири свойства, често пъти означавани с "ACID" – от първите букви на английските названия на тези свойства:

• Атомарност (Atomicity)    Транзакцията трябва да бъде неделима (атомарна) единица работа – или се извършват всички предвидени промени в данните, или не се извършва нито една от тях.

• Съгласуваност (Consistency)    След приключването на транзакцията всички данни трябва да бъдат оставени в съгласувано състояние. Това означава, че са в сила всички правила за цялост на данните.

• Изолиране (Isolation)    Промените, направени от едновременно протичащи транзакции, са изолирани от текущата транзакция.

• Трайност (Durability)    След като транзакцията приключи, промените остават дори в случай на срив на системата.

Може да използвате транзакция, за да гарантирате непротиворечивостта на данните – например при теглене на пари в брой или автоматично депозиране на чек. Транзакциите могат да бъдат експлицитни, имплицитни или пакетни. Ето два примера с TSQL:

-- Using an explicit transaction

BEGIN TRANSACTION;  
DELETE FROM HumanResources.JobCandidate  
    WHERE JobCandidateID = 13;  
COMMIT;  

-- the ROLLBACK statement rolls back the INSERT statement, but the created table still exists.

CREATE TABLE ValueTable (id int);  
BEGIN TRANSACTION;  
       INSERT INTO ValueTable VALUES(1);  
       INSERT INTO ValueTable VALUES(2);  
ROLLBACK;

За повече информация вж. Транзакции.

Най-горе на страницата

Използване на ограничения и превключватели

Всички бази данни имат начини за поддържане на непротиворечивостта на данните.

Ограничения

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

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

Превключватели

Access няма превключватели за базата данни. В SQL Server може да използвате превключватели, за да налагате сложни правила за непротиворечивост на данните и да изпълнявате тази бизнес логика на сървъра. Един превключвател в база данни е съхранена процедура, която се изпълнява, когато в базата данни възникват определени действия. Превключвателят е събитие – например добавяне или изтриване на записи в таблица, което активира и след това изпълнява съхранената процедура. Въпреки че една база данни на Access може да осигури непротиворечивост на данните, когато потребител се опита да актуализира или изтрие данни, SQL Server има сложен набор от превключватели. Можете например да програмирате превключвател да изтрива записи в пакет и така да гарантира непротиворечивост на данните. Можете дори да добавяте превключватели към таблици и изгледи.

За повече информация вж. Превключватели – DML, Превключватели – DDL и Проектиране на T-SQL превключвател.

Най-горе на страницата

Използване на изчисляеми колони

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

Extended Price: [Quantity] * [Unit Price]

В SQL Server еквивалентната функция се нарича изчисляема колона – виртуална колона, която не се съхранява физически в таблицата, освен ако колоната не бъде маркирана като PERSISTED. Подобно на изчисляема колона, изчислената колона използва данни от други колони в израз. За да създадете изчислена колона, я добавете към таблица. Например:

CREATE TABLE dbo.Products   
(  
    ProductID int IDENTITY (1,1) NOT NULL  
  , QtyAvailable smallint  
  , UnitPrice money  
  , InventoryValue AS QtyAvailable * UnitPrice  
);  

За повече . Задаване на изчисляеми колони в таблица

Най-горе на страницата

Времево клеймо на вашите данни

Понякога може да добавите поле на таблица, в което да бъде записано времево клеймо, когато даден запис се създава, така че да можете да регистрирате момента на записване на тези данни. В Access можете просто да създадете колона с дати със стойността по подразбиране на =Now(). За да запишете дата или час в SQL Server, използвайте типа данни datetime2 със стойността по подразбиране на SYSDATETIME().

Забележка    Не бъркайте rowversion с добавянето на времево клеймо към вашите данни. Ключовата дума timestamp в SQL Server е синоним на rowversion, но трябва да използвате ключовата дума rowversion. В SQL Server rowversion е тип данни, който разкрива автоматично генерирани, уникални двоични числа в базата данни и обикновено се използва като механизъм за подпечатване на редовете на таблицата с номер на версията. Обаче типът данни rowversion е просто поредно число, увеличено с единица, което не отразява датата или часа и не може да бъде използвано като времево клеймо на ред.

За повече информация вж. rowversion. За повече информация относно използването на rowversion с цел да бъдат намалени конфликтите при запис, вж. Мигриране на база данни на Access към SQL Server.

Най-горе на страницата

Управление на големи обекти

В Access можете да управлявате неструктурирани данни, като файлове, снимки и изображения, с помощта на типа данни Прикачен файл. В терминологията на SQL Server неструктурираните данни се наричат BLOB (от Binary Large Object – голям двоичен обект) и има няколко начина за работа с тях:

FILESTREAM    Използва типа данни varbinary (max), за да бъдат съхранени неструктурираните данни във файловата система, а не в базата данни. За повече информация вж. Достъп до данни от тип FILESTREAM чрез Transact-SQL.

FileTable    Съхранява обектите BLOB в специални таблици, наречени FileTables и осигурява съвместимост с приложенията на Windows все едно, че са съхранени във файловата система, без да е необходимо да се правят промени във вашите клиентски приложения. FileTable изисква да се използва FILESTREAM. За повече информация вж. FileTables.

Отдалечено хранилище за BLOB (RBS)    Съхранява големи двоични обекти (BLOB) в решения за разпределени файлови системи, а не директно на сървъра. Това спестява място и намалява необходимите хардуерни ресурси. За повече информация вж. Данни от вида големи двоични обекти (BLOB).

Най-горе на страницата

Работа с йерархически данни

Въпреки че релационните бази данни – например Access, са много гъвкави, работата с йерархически релации е изключение и често изисква сложни SQL оператори или програмен код. Сред примерите за йерархични данни са: организационна структура, файлова система, таксономия на езикови изрази и граф на връзките между уеб страници. SQL Server разполага с вграден тип данни hierarchyid и набор от йерархични функции за лесно съхраняване, съставяне на заявки и управление на йерархични данни.

За повече информация вж. Йерархични данни и Самоучител: Използване на типа данни hierarchyid.

Най-горе на страницата

Работа с JSON текст

Обектовата нотация на JavaScript (JSON – JavaScript Object Notation) е уеб услуга, която използва четим от хора текст за пренасяне на данни от вида "двойка атрибут – стойност" при асинхронна комуникация браузър – сървър. Например:

{
"firstName": "Mary",
"lastName": "Contrary",
"spouse": null,
"age": 27
}

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

Забележка    JSON не се поддържа във VBA. Като алтернатива можете да използвате XML във VBA с помощта на библиотеката MSXML.

За повече информация вж. JSON данни в SQL Server.

Най-горе на страницата

Ресурси

Сега е моментът да научите повече за SQL Server и Transact SQL (TSQL). Както видяхте, има много функции, подобни на тези на Access, но също така и възможности, които Access просто няма. За да завършите запознанството си със следващото ниво, ето някои ресурси за обучение:

Най-горе на страницата