C, PHP, VB, .NET

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

.

Задачата беше дадена в два варианта, като те се различават съвсем малко в едно условие. По-долу е отбелязано като "вариант 1" или съответно "вариант 2". Ето задачите и решението им (което нарочно ще го разгледам много подробно, дори с риск да бъде прекалено): Прочети още...

.

Досега знаем как да изваждаме информация от повече от една таблица (многотаблични заявки), като се налагаше да използваме връзките между таблиците (join). Извършването на "self join" означава "да свържем една таблица със самата себе си". Или казано по друг начин - да направим многотаблична заявка, използвайки една-единствена таблица. Нека демонстрираме с няколко елементарни примера. Прочети още...

.

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

.

Нека разгледаме следните примерни две таблици: Прочети още...

.

Въпросът поставен в заглавието на статията е много често разискван и около него се водят спорове. По принцип има една тенденция програмистите категорично да избягват вложените select заявки, защото още от миналото има един мит, че те винаги се изпълняват по-бавно. Този мит се дължи главно на грешки в СУБД, които не са използвали правилно индексите при вложените заявки. Днес това отдавна вече (почти) не се среща, т.е. можем да очакваме вложените заявки да вървят достатъчно добре. Така въпросът "join или вложен select" отново стои на дневен ред.

Ще демонстрираме с един пример. Нека имаме следната база от данни: Прочети още...

.

В предишна статия свързана с ограниченията CHECK писахме за нещо изключително неприятно - не се поддържат от MySQL. Същевременно именно CHECK понякога е доста важно за интегритета на данните, когато пишем в "несигурна среда", т.е. работим с програми, на които не можем да вярваме. Прочети още...

.

Още в началото, когато се разглеждаха заявки за еднотабличен оператор SELECT, набързо се разгледа оператор LIMIT. Да припомним - той приемаше за параметър целочислено число X, чрез което от резултатната таблица се връщат само първите X реда, а останалите "се отрязват". Това естествено има редица приложения - разглеждане на най-новите записи от статистики, разглеждане на "най-добрите" резултати от състезание, извеждане на последните записи в таблица и т.н. Почти винаги, за такива случаи, оператор LIMIT е предхождан от ORDER BY. Прочети още...

.

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

.

В досега разглежданите примери при CREATE TABLE на няколко пъти показвахме параметър "UNIQUE", който се добавяше след дадена променлива. Например:

CREATE TABLE university(
   `id` INT UNSIGNED AUTO_INCREMENT,
   `name` VARCHAR(255) NOT NULL UNIQUE,
   PRIMARY KEY(id)
)ENGINE=INNODB;

Казахме, че PRIMARY KEY винаги е едновременно NOT NULL и UNIQUE по подразбиране, както и че е възможно да направим комбинация от две или дори повече колони заедно PRIMARY KEY. Прочети още...

.