Разширени познания за бази данни

1.1 Принцип на изграждане на лекциите

Вие и аз започнахме нашето запознанство с базите данни отдолу . Това е особеност на личния ми подход към обучението на хората. Когато говоря за нови теми, винаги първо ви казвам How да използвате определени инструменти на практика. И вече когато знам, че човек знае How да ги използва, започвам да разказвам How работи всичко.

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

Този подход е малко по-различен от този, с който сме свикнали, който се използва в учorщата и университетите. Но всичко е ясно: когато учите в учorще or университет, имате правилните приоритети: ученето е най-важното нещо в живота в този момент.

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

Всичко опира до приоритети. Има дори такава концепция в света на стартиращите фирми - Fail Fast, fail as possible . Звучи странно, но всъщност има много смисъл: задачата на стартъпа е бързо да провери дали хипотезата му е вярна. И ако не е вярно, тогава не е нужно да отделяте години от живота си за това, по-добре е да разберете възможно най-рано, че няма търсене за определена услуга or продукт.

Когато преподавам Java и SQL, използвам същия подход: давам ви възможност да разберете възможно най-рано дали бързате от програмирането or не . Ако харесвате програмирането и вие сами сте успели да разберете How да работите с цикли и масиви, тогава с помощта на ментори и добре разработена програма имате всички шансове да завършите обучението си и да си намерите работа.

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

Само 40% от завършorте работят по специалността, която са получor в университета. Замислете се, хората са учor по 5-6 години, а 60% са решor да не работят по специалността. Да, част от придобитите знания все още се използват, но около половината не.

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

1.2 SQL и всички, всички, всички

Приключихме с философското въведение, нека се върнем към изучаването на SQL.

SQL езикът и СУБД са малко различни неща. Самият SQL език е един вид стандарт, който описва Howво може да бъде написано в SQL заявки към базата данни. СУБД вече са имплементации на този стандарт. Някои СУБД изпълняват някои функции на стандарта, вторите - други и т.н.

Колкото по-скъпа е СУБД, толкова повече характеристики на стандарта изпълнява. Освен това много СУБД често прилагат свои собствени уникални функции извън SQL стандартите. Понякога това води до проблеми с преносимостта: SQL заявките, написани за една СУБД, може да не работят добре за друга.

Java също има подобна ситуация. Ако Java програма е написана под Windows, тогава тя няма да работи нормално на Linux. За да разреши този проблем, Java въвежда специални класове, които имат различни реализации за различните операционни системи. Пример: клас Path, който има реализации на WindowsPath, LinuxPath и др.

Втората част от проблема се решава с помощта на versionта. Всички успешни иновации от различни езици or СУБД се добавят към новия JDK or SQL стандарт. Вече знаете, че има различни версии на JDK и колкото по-нова е versionта, толкова повече функции има. Същото е и със SQL.

В езика SQL има няколко версии на неговия стандарт, които са наименувани по години:

• SQL:1999
• SQL:2003
• SQL:2006
• SQL:2011
• SQL:2016
• SQL:2019

Добра новина : няма да изучаваме тези стандарти. Първо, ще са необходими години, за да се изучи и усвои всичко това. И второ, тези стандарти са като версии на Android: само 5-10 години след пускането стандартът става масово разпространен.

В бази данни с големи количества данни хората се нуждаят от надеждност и стабилност. „Работи, не го пипайте“ е мотото на всеки, който работи с бази данни. И преминаването към нова version на бази данни се извършва на всеки 5 години, когато всички предимства на такова решение вече са очевидни.

1.3 Отвъд скобите

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

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

1 proceduresен език (PL)

RDBMS поддържат способността да пишат proceduresи и функции, които се изпълняват на SQL Server и могат да правят много неща с данни по време на заявки. Например, веднъж написах PL SQL заявки към сървъра на Oracle, който в отговор на заявката генерира ... HTML page с данни. Да, можеш.

2 събития (тригери)

Всички съвременни СУБД поддържат механизма на събитията, които на езика SQL се наричат ​​тригери. Тригер възниква като отговор на няHowво действие. Например, можете да прихванете всички опити за запис в базата данни и да добавите точното време на промяната им към нови редове.

3 Сеч

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

В някои отношения това е подобно на поведението на Garbage Collector в Java: той също първо просто маркира обектите като изтрити и извършва почистване и оптимизиране на паметта по време на неактивност.

4 добавки

Към СУБД, Howто и към много програми, можете да пишете свои собствени добавки. Такива добавки ви позволяват да добавяте уникални типове данни, функции за работа с тях or да променяте стандартното поведение на СУБД. Това е особено полезно, когато работите с база данни с отворен code и има някои грешки.

5 Разпределена работа (клъстери)

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

6 Шардинг

Когато има много данни, те започват да се разделят в различни бази данни. До факта, че една table може да се съхранява на части в различни бази данни.

Шардингът може да бъде вертикален и хоризонтален. Вертикалното шардинг означава, че масата е, така да се каже, нарязана от вертикални линии, докато хоризонталното шардинг се нарязва на хоризонтални.

Например, решихме да разделим всички данни в tableта по години: за 2019 г. - една table, за данните от 2020 г. - втора и т.н. Това ще бъде хоризонтално шардинг.

7 бутам не-бутам

На определен етап от развитието на базите данни към тях започна да се добавя все повече бизнес логика. Всичко започна с proceduresи, функции, генериране на уеб страници от сървъри и завърши с добавянето на поддръжка за почти всички популярни езици към СУБД: Python, JavaScript и дори Java и C ++.

Звучи страхотно, докато не започнете да навлизате в подробностите: наистина ли искате да напишете бизнес логиката на вашето уеб приложение в Java, която ще се изпълнява в SQL сървър, където няма JDK, java библиотеки, рамки, малко памет и много други ограничения?